All Answers

I mean, how to disable similar qooxdoo warnings, some way or config to disable or comment console.warn related with “qooxdoo missing appearances”
Thanks in advance

Interesting enough, setting the error in the data table works flawlessly.

BeginUpdate, EndUpdate do the trick, thanks Luca

There is an issue that will be fixed in the upcoming release that seems similar to this. If you hit refresh does it show the error icon?

If yes, use this as a workaround until the fix is available:

 dataGridView1.BeginUpdate();
 dataGridView1[1, 1].ErrorText = "Error";
 dataGridView1[2, 3].ErrorText = "Error";
 dataGridView1.EndUpdate();

Just checked in Winforms and I can’t see any way to format a NumericUpDown. In Winforms you can also type a decimal value when the Decimals property is set to zero, the result will be a number without decimals, which is correct. Wisej does exactly the same. NumericUpDown cannot be formatted using custom strings in Winforms and in Wisej – the text has to be parsed into a valid number on the client.

You can format a data bound TextBox control (like in Winforms) and use “p” for percentages or “+#0.00;-#0.00” to show +/-.

With Wisej you can also attach a javascript event to stop “.” or “,” from being typed and force only numeric characters.  And you can show a custom +/- button inside the field. You need to create a custom control.

I attached some sample code you can use and adapt to your requirements.

Hi Ben, a session timeout of 3600 is 1 hour. There is no way to detect when the browser is closed, there isn’t such an event in javascript. Closing the browser is identical to hitting refresh. Are you using a custom countdown in Application.SessionTimeout? The built-in one counts down the session-timeout seconds and then terminates the session on the client which causes the server to dispose the session immediately.

I’d reduce the session timeout to 1 minute or 3 minutes. The session will never timeout until there is user activity anyway. Or you can override ApplicationSessionTimeout and decide when to terminate. To force the disposal of a session use Application.Exit().

Only 1 is an issue. The second point is handled correct by WiseJ.

For 1: User is able to change the text of disabled controls –> unwanted behaviour. Not checked by wisej.

For 2: User is not able to click on disabled controls –> expected behaviour and also correctly enforced on serverside by wisej

2. was only an example that you are already checking for enabled on Buttons but not on TextBoxes

Hi Bernhard,

As I understand it, there are two points

1. Unwanted change of disabled or read only TextBox
2. Unwanted clicks on disabled Buttons or other clickable elements (Tab page etc.)

Is this correct?

We load the POCO = EntityFramework object from the database, bind the properties to the textboxes (or any other editable-control) and afterwards save the entity. I assume this is the typical Workflow for data driven applications.

Now, if the user has no permission to edit some properties, we set the control to readonly (or disabled). With this we want to make sure that the property can not be changed by the client (user or JavaScript).

But with this issue the user is still able to change properties (still he has to be an advanced user knowing the JavaScript API).

Our finding on this topic is also taht if the user “clicks” a disabled button with JavaScript button.execute() you are checking if the control is enabled. Why not checking for readonly or enabled for TextBoxes, DateTimePicker or any other editable control?

Hi Bernhard,

Can you explain why this is a show stopper for you?

Thank you for your reply but for us this is not an option. I attached a simple demo how this will be a showstopper for us (and I assume this will be an issue for many other developers).

In my first example you also saw that, for example, changing the text of a label is not send to the server.

Hi Bernhard,

no, readonly protects a control from being changed by user activity.
Programatically it still can be updated (this includes javascript).

Otherwise there would be no chance to display anything in the browser.

Hope that helps.

Best regards
Frank

Thanks Harald.

I have logged issue WJ-8652 for it. We´ll inform you when a fix is available.

Best regards
Frank

Hi Nikos,

thanks, this was related to the new showProgress property we added recently to Alert Boxes.

It´s fixed already and will be included in the next Wisej build. Will inform you when it´s available.

Best regards
Frank

PS: You can also set showProgress:true in the meantime.

Hi Rudy,

thanks for raising that issue. It is logged as WJ-8650 and a fix will be included in the next Wisej release.

I´ll inform you when it is available.

Best regards
Frank

The Application.ApplicationExit event is fired when the session is disposed.

There is no Browser Closed event. There is no way with any browser to detect when a browser is closed. The window.onbeforeunload and window.onunload events (see https://developer.mozilla.org) fire when refreshing, changing the url, navigating.