We are pleased to announce the immediate availability of Servoy 6.0.4 release.
This version is available through the download option on the Servoy website and auto-update.
Always make a backup of your current Servoy installation (directory and database) before installing/upgrading.
To update a Servoy eclipse open Check for updates via help menu.
Client Changes
[fix] SVY-891 Anchoring issue.
[fix] SVY-987 onRender on a label in listview hides the label, but not the label border
[fix] SVY-1031 Error Calling Server message shows when closing dialogs
[fix] SVY-1053 Loading Foundsets should not allow for multiple items with the same pk
[fix] SVY-1223 Strange row selection tableview behaviour in 6.0.3 smartclient
[fix] SVY-1080 Setting a label @designtime to not visible doesn’t hide the label if the label is used as a label for another element using the labelFor relation
[fix] SVY-1090 Column converter interupts onDataChange() event of a combobox in Servoy 6.0.2
[fix] SVY-1093 Popup not showing the full content
[fix] SVY-1112 Slow performance over WAN with large number of portals on a form
[fix] SVY-1208 Right anchored labels overlap after show (inherited) form
WebClient Changes
[fix] SVY-981 Dialog sizes shouldn’t be persisted for non-resizable dialogs.
[fix] SVY-898 Submenu code from Servoy 5 does no longer work in 6.0.x in older versions of IE
[fix] SVY-1024 Internal Error triggered by WicketRuntimeExc
[fix] SVY-1027 event.getModifiers() is not working well in table view
[fix] SVY-1244 Not Logging Out All The Way?
[fix] SVY-1250 Reports aren’t working reliably.
[fix] SVY-1264 Deadlock in Web Client when running in IE
[fix] SVY-1033 Web Client Label Vertical Alignment
[fix] SVY-1034 Combobox that is set to not enabled is still changable when the field is transaparent
[fix] SVY-1036 Opening of dialog the second time ends up causing it to resize incorrectly
[fix] SVY-1038 Servoy webclient freezes
[fix] SVY-1040 FormInDialog in webclient sticks to mouse
[fix] SVY-1220 Textfield doesn’t fire methods when focus is lost via [Enter] key
[fix] SVY-1239 Clicking a radio button on a form with multiSelect enabled, resets multiple row selection
[fix] SVY-1240 Choosing a value from typeahead list via mouse fails sometimes.
[fix] SVY-1094 Modal dialogs may end up displayed off-screen.
[fix] SVY-1102 Clicking between rows in a table view in Webclient is too slow.
[fix] SVY-1110 Table View Header Issue - Java 7
[fix] SVY-1121 Java 7 is causing strange rendering of table headers and field in the Web Client
[fix] SVY-1111 Type Ahead Drop down Issue
[fix] SVY-1056 Putting a form into design mode does not always work in Internet Explorer
[fix] SVY-1057 The onSelect event is not properly triggered when a form is in design mode
[fix] SVY-1058 Unable to access a label with an image when a form is in design mode
[fix] SVY-1071 Internal error in dialog
[fix] SVY-1084 field value is not selected in typeahead list when field gets focus
[fix] SVY-1117 Every once in a while a dialog will refuse to open and then can’t be opened again without terminating the session.
[fix] SVY-1120 Can’t select item with mouse in type ahead fields on a table view when multiple type aheads in multiple colums
[fix] SVY-1122 Labels with mutliple lines (using html) are not centred vertically but start from centre
[fix] SVY-1123 Internet explorere 9 gets continuous full page refreshes in web client, after some time gets into an infenite loop of refreshing (flickering screen)
[fix] SVY-1129 The color set using the designtime foreground property on a checkbox doesn’t result in the correct color being applied in the Web Client on the text set in the checkbox’ titletext property
[fix] SVY-1132 Msg “a render component: shape, is missing” in 6.0.3
[fix] SVY-1136 Webclient: Forms opened in a modal dialog from within another modal dialog do not display later when shown from the main form.
[fix] SVY-1138 Field in portal with relation based dataprovider does not work
[fix] SVY-1154 Opening a modal dialog, and then when closing it, open another modal dialog fails
[fix] SVY-1155 setting titletext property of a html area field at runtime does not work
[fix] SVY-1162 Typeaheads with spaces in the display value can not be selected.
[fix] SVY-1182 Textfield expands as if anchored to bottom, right corner of page in IE7.
[fix] SVY-1185 Issue with get/setUserProperties in the Web Client
[fix] SVY-1091 HTML in the titleText property of a checkbox not supported
[fix] SVY-1206 support for injecting Link tags with href attributes linking to entries in the media library through a non-editable HTMLArea
Developer Changes
[enh] SVY-770 Option to exclude entire tables in a database from being shown inside Servoy Developer
[enh] SVY-1169 Should exclude ignored tables in Solution Explorer.
[fix] SVY-958 Format property gets bogus character when used with templates
[fix] SVY-1013 SVN checkout causes loads of invalid warnings
[fix] SVY-1186 New code disappears in export solution
[fix] SVY-1029 Outline doesn’t work for calculations anymore
[fix] SVY-1242 Rhino usage warning
[fix] SVY-1070 Solution Tree won’t build after adding new module
[fix] SVY-1209 excluded columns still shown in Code Completion
[fix] SVY-1210 Missing builder markers for usage of excluded columns `
[fix] SVY-1114 exceptions and unneeded solution loads
[fix] SVY-1149 Paste in to the Interactive Console doesn’t works
[fix] SVY-1150 IDE: ‘Search for References’ & ‘Open SQL Editor’ missing from option menu for Views.
[fix] SVY-1170 Form Editor: the inline Label text editor is not always dismissed
[fix] SVY-356 Selecting the same field of the same table more than once (via 2 different relationships) in the initialSort dialog
[fix] SVY-270 CC on JSFile object returned by plugins.file.showFileOpenDialog(1, null, false) after casting also yields JavaScript object properties like prototype
Application Server Changes
[fix] SVY-1141 App Server: NullPointerException at com.servoy.j2db.Za.Zr.startEvictor(Zr.java:8)
[fix] SVY-1064 Server log shows invalid warning about ‘addRow index paramer after createDataSource call is ignored on data set’
[fix] SVY-1067 If a method in a headless client throws an exception using ‘throw new Error(‘error msg’)’ the callback receives incorrect exception information
[fix] SVY-1074 Not all modules referenced by a solution are initialized if the solution requires authentication and uses login and authenticator modules
[fix] SVY-1116 exception in getDataSetByQuery
[fix] SVY-1124 After Import module variables are undefined
[fix] SVY-1135 Admin Console: Clearing statistics also clears actively running queries.
[fix] SVY-1198 Multiple WARN entries in log
[fix] SVY-1204 login module won’t allow solutionModel.newForm (nullpointer exception)
[fix] SVY-1216 com.servoy.j2db.util.Debug Could not load record
Plugin Changes
[fix] SVY-1089 PDF Forms plugin does not display form correctly
[fix] SVY-1189 nullPointer when calling plugins.mail.isValidEmailAddress(null), instead of it returning false
[fix] SVY-376 Mark the whole row in a DBTreeTableView bean
Since I have upgraded the Servoy Developer from 6.0.3 to 6.0.4 I get Warnings like:
For performance reasons on the internet/WAN it is strongly suggested to place no more then 3 portals/tab panels on a form.
For performance reasons on the internet/WAN it is strongly suggested to place no more then 20 fields on a table view form.
But only for one solution!? Other solutions with similar forms don’t have the performace warnings!?
Ok, I can ignore and/or delete the warnings, but it would be nice to know more about this.
I can tell something a little bit more about this.
if you use more than 3 tabpanels on a form, and more than 20 fields/labels in a tableview, your WAN performance will decrease. (bit by bit, the more fields, the more performance will decrease)
So Servoy warns you about this, but there is little bug in this, that will be solved in Servoy 6.0.4
Servoy is counting every field/label on a table-view form, instead of counting only the body-part. this will be fixed in the next version.
For me it is complete unrealistic to create practical forms in my solutions with less than 3 tabpanels/portals and 20 fields/labels.
It’s nice to get the performance warnigs to think about it when creating forms, but it should be possible to deactivate this preference.
Harjo:
If you use more than 3 tabpanels on a form, and more than 20 fields/labels in a tableview, your WAN performance will decrease. (bit by bit, the more fields, the more performance will decrease)
This is the first we’ve heard of this. Our impression is that once Servoy UI elements are cached on the client there is no additional incremental performance penalty based on the amount of Servoy UI elements. Instead, you take your performance hit up front when the UI is loading and there are some great ways to mitigate this if you are going with a complex UI.
By far the single biggest impact on performance in a WAN environment (smart client here) is how many trips to the server Servoy has to make to generate a cached UI. You can easily have great performance with a dozen tab panels showing 100 fields and you can easily have really bad performance with one table view with a couple of related fields, a couple of comboboxes with related value lists (a relation-based value list attached to a column in table/list view can create a trip to the server for every row visible…), and a summary field or two at the bottom.
We have Smart Client solutions running across ~2,000 miles to the server with UI screens that have 3+ split beans, literally dozens of tab panels and a lot more than 20 fields (but never in the same table as that is just bad UI) – running faster than terminal services over the same distance.
Generalizing performance with this warning is overly simplistic and hence misleading. Needs just as much explanation as not having it there to begin with.
These warning are put inplace to make developers aware of out doing things.
Over the last months more and more performance issues where filed, these cases entailed for example tableviews with more then 40 columns and the complains where “it does not perform”.
Something becoming slow when outdoing things, might seem normal for most of us but apparently not for every one…
And yes we have to generalise when it comes to performance warnings, I will make sure they can be disabled in next release as you are saying these warnings bug you.
BTW It does warn for more then 3 tabpanels/portals on 1 form. To make things clear this is not about tabs! (and does have no relation to nesting of forms by means of tabs!)
The problem I have with this warning is that it is like throwing up a warning telling a developer their UI is ugly because there is too much stuff on a form. While the ugly part is most likely true, the reason doesn’t really help.
Numbers of objects in a table view is not a real reason. You can easily have one html area field on a form and have a performance issue. Draw time for an html area field that gets 1,000 bytes of data shoved into it can take a whole second (depending on client processor). Put an html area field in a table with 20 rows showing and it only takes 50 bytes of data in each html area field to make that table 1 second slower to render.
It is the type of objects that is the reason. Some – like rft/html areas and blobs – take significantly longer to render than others. There is no problem with putting 40 text fields in a table view with no calculations. Only one query to the server and it renders fast.
The only truth in numbers of objects is that it is more likely to have more slower objects. Which I guess is a worth a warning but it is a warning that requires a lot of explanation.
It seems to me that if you are going to get into the business of counting things and throwing up warnings, why not flag known offenders? Calcs, blobs, html/rtf fields, and related value lists in a table for starters.
Better yet, have a feature that highlights all the objects on a form with a color representing their render speed potential – green, yellow and red. In a table of 40 columns, you’d instantly see which columns are most likely to cause speed issues.
Along the same lines, I’d love to see the performance page of Servoy server (which is brilliant) as a view in Servoy developer. Sort of like the profiler view except you see the queries that are generated for the interface showing. Clicking on an item takes you to the object that generates the SQL. This would save a lot of time as matching up performance page items to what is generating the SQL can be tedious.
I really like the idea of flagging performance issues. I just think that if you’re trying to help newbie developers out (and we all have our newbie moments) – I think it requires better solutions than generic warnings.
david:
It seems to me that if you are going to get into the business of counting things and throwing up warnings, why not flag known offenders? Calcs, blobs, html/rtf fields, and related value lists in a table for starters.
Better yet, have a feature that highlights all the objects on a form with a color representing their render speed potential – green, yellow and red. In a table of 40 columns, you’d instantly see which columns are most likely to cause speed issues.
Along the same lines, I’d love to see the performance page of Servoy server (which is brilliant) as a view in Servoy developer. Sort of like the profiler view except you see the queries that are generated for the interface showing. Clicking on an item takes you to the object that generates the SQL. This would save a lot of time as matching up performance page items to what is generating the SQL can be tedious.
I really like the idea of flagging performance issues. I just think that if you’re trying to help newbie developers out (and we all have our newbie moments) – I think it requires better solutions than generic warnings.
I don’t believe that SVY-1154 is completely fixed. I still have a series of FIDs using the JSWindow (modal) where I run into problems in web client (Safari, Firefox, Chrome). This is with Servoy 6.0.4 and Mac OX 10.6.8.
I changed the way I was doing things even before this fix came out. Namely I just used one named JSWindow and then changed the title and forms it was showing (with various pop up warnings using ServoyForge’s (Robert’s) globals.DIALOGS methods when I need one of those). This seemed to stop the problem with opening/closing the JSWindow modal FIDs. However there is still a problem with webclient when I need to bring up a globals.DIALOGS during this process. I need to stop the user closing the FID by clicking on the ‘X’ and forcing them to hit the designed button. This works fine in smart client. But in web client the FID disappears and the the Warning dialog never appears. Below is one example code. There is an existing FID in a JSWindow. The FID has an onHide event tied to it to prevent users closing it themselves. The first function is called by a button on the form and works fine if the users use that button to close the form. However it they simply close that FID and thus go straight to the second function (onHide event) then it works fine in smart client but not in web client.
function CopyLocationAndClose(event) {
globals.g_trigger = event.getElementName();
if(name == 'btn_copyLoc') {
forms.linvlocationaccess.controller.loadRecords(globals.g_locationAccessID);
var curWindow = controller.getWindow();
curWindow.title = 'Action Taken with Inventory';
curWindow.setSize(900,250);
curWindow.resizable = true;
forms.linvlocationaccess.controller.show(curWindow);
}
}
function onHideWindow(event) {
//The if statement checks if the onHide is called by the above method in which case it simply closes the FID.
//Otherwise it gives the users a warning message and cancels the closing of the FID. Fine in smart, not in web.
if(event.getElementName() == null && globals.g_trigger == 'btn_copyLoc') {
globals.g_trigger = null;
return true;
}
else {
}
var warning = globals.DIALOGS.showWarningDialog('Copy and Close!','Close this form by clicking the button ','OK')
return false;
}
John
(P.S. There might very well be a better way to force users to use the correct button for closing the FID but I couldn’t seem to find a way to do that…)
I have a form variable canClose set to false in the onShow event of the form. I just set it to true in the onAction event of the OK button and the onHide event returns canClose.
Sometimes not always, to be honest two times, when you create a form that extends another, some of the elements that are inherited shows a problem indicating that the UUID is duplicated.
The two times were with the same element, a tabPanel. The main form is in a module of that solution and it only has code, in the main solution it is subclassed to add some elements like tabPanels, labels, etc. Some of those tabPanels are in another module. Then that form is subclassed again many times.
It´s like I have a form with the code I need to manage a table, for example the customer table. In the main solution I create a subcalssed form with the common elements for that solution, let´s say the record navigators buttons, etc. Finally that is the form that I use to extend the Providers Management form, the Customer Management form, etc.
I have also seen, that is since 6.0.3, that it is impossible to change the tabSequence of the inherited tabPanels, you cannot move them out of the sequence nor change it. Also the tabPanels added to the subclassed form, not the inherited, have a similar behaviour, you can only put them at the bottom of the sequence.
Thanks Juan I’m sure that works great for stopping the user from closing the FID and much more elegant than my way! However I would still like to give the user a warning dialog to tell them that they have to hit the button and I don’t think that will help in web client. It works fine in smart client but just not in web client (at least in Safari, Chrome and Firefox on a Mac). It’s late here and I’ll try it tomorrow but I’m pretty sure I’ll get the same issue with the warning dialog when the onHide is triggered.
var warning = globals.DIALOGS.showWarningDialog(‘Copy and Close!’,'Close this form by clicking the button ',‘OK’)
is the mod_dialog module?
That works with continuations, so the return value “return false” after that will not happen when you show the dialog
so the onhide doesn’t really return false but generates an exception and returns “undefined” and then we just close the dialog
What you need to do is not use the mod_dialog module, but really show another modal dialog (jswindow) there.
and do return false, then in that modal dialog you have stuff that can really close that main modal dialog or something like that (by booleans which is already suggested )
That would work.
But only for dialogs that don’t give an option as in “close dialog or not” because the code where this dialog was called from is already moved on. So the main dialog is already closed or blocked from closing depending on the return value.
So I guess the real solution to this is to have control over the X control itself. If we can hide/disable it then the user would never be able to trigger the onHide in this manner.
If I understand it correctly I would also very strongly support Robert’s suggestion. ff you want a user to only be allowed certain actions, the best, cleanest, most elegant solution is to limit the actions that they can take in the first place. So, if there is a modal dialog and you don’t want the user to be able to close the dialog in any other way, then it is better if there are simply no other alternatives. Otherwise the developer has to program a way to both prevent the user closing it in other ways and inform the user that they cannot do it any other way. And for the user it is more confusing and more dialogs they have to deal with. Much better if there is no other way to ‘close’ the modal dialog, no ‘X’ or ‘red dot’ at all. Is that possible?
In fact I think it would be best if the default for modal dialogs was like that as generally with a modal dialog I think the developer most of the time wants to dictate the user’s options. For some of the dialogs hitting the ‘X’ is akin to ‘canceling’ the action which sometimes works so no harm done. But I think generally with a modal dialog especially you want to be able to control the users response completely so better to have no other alternative visible at all for the user in the first place…
then the close button never does do anything, and you can only close it through the modal dialog itself.
if you want to show a dialog telling the users that they can’t press close thats also quite easy just show another modal dialog in the onhide (but don’t use the mod_dialogs plugin or something like that, just plain modal dialog with a simple form)