Page History

...

On a Column, Table or Server level you can configure what the sort order should be with nulls first or last and you can specify that sorting should always be done with upper/lower casing.

A new handler event is now available at the form level: "onBeforeHide".

• Why? It was needed because the "hide" operation of a form can be blocked either by a combination of auto-save enabled + stop editing failing or by a solution registered "onHide" handler for that form (that returns false). That denied the switch/hide in case that form was the main form or a root form in a tab of a tabpanel that is trying to change it's active tab. Problem was that - in case of deeply nested tabs (so forms nested through components like tabpanels/splitpanes and so on) it could happen that a form that is deeply nested denies hide (either due to stop editing blocking it or by return false in it's "onHide" handler) but, as it is not the root form affected by the change, the denied hide was not taken into account and the hide happened anyway. This could result in the nested form thinking it's still visible (it denied hide didn't it?!) when in fact it was hidden in the UI. That could lead to unexpected state in both solution code and internal Servoy code.

• New way: Things are now more predictable. In order for the solution to know correctly that a form was hidden or not, we added an "onBeforeHide" event (returns boolean) on forms and deprecated (but can still be used) the return value of "onHide" - so only the return value not the whole "onHide". "onHide" will only be called if the form actually gets hidden. Any form (even nested) can now actually deny the hide operation - if it returns false in "onBeforeHide" or the combination auto-save/stop editing denies the hide. If we would not have added "onBeforeHide", but just made nested forms "onHide" return value matter, it could still happen that a form returns true in "onHide" (so it thinks it will get hidden) but another (nested form) returns false thus blocking the whole hide operation; and the confusion would still be there.

• How it works: any of the forms (nested or not) that are being hidden can block the hide operation. This is a behavior change, but previous behavior was not working correctly, so it should not be a problem. The hide of a form first goes through the UI hierarchy and checks the "onBeforeHide" handlers of affected forms and auto-save/stop editing (inner most forms first), then onHide will only be called if all those allow hide - in all affected forms. This means that the execution order of onBeforeHide handlers will be reversed (first called on the leafs (most deeply nested forms) then on their parents) compared with current onHide call order. The onHide call order remains the same in case of nested forms.

Other changes

The way TiNG is build is changed, now we have a build directory per solution so when you switch there is not always a need to start a build again.

...