Servoy Forum

We are pleased to announce the immediate availability of Servoy 5.0 rc3

Usage at own risk. Install in separate directory from your production versions.

For updating Servoy eclipse developer, use menu item: Help -> Check for updates
Note: since the Eclipse.org and SQLExplorer both have problems with the update-site you have to disable those update-sites in: Window -> Preferences (update sites)

For updating a Servoy application server install, use:
java -jar servoy_updater.jar -beta (in the install directory)

Client changes:
[fix] 249898 ColorChooser dialog usage with parameter has strange behavior
[fix] 248180 Calculations depending on relation size do not trigger after size change
[fix] 248865 When creating records in linked tables using a in-memory transaction they don't save in the proper order
[fix] 232676 Form in dialog not sizing properly
[fix] 249293 WebClient anchoring issue in Tableviews
[fix] 245911 WebClient is reserving space for paging controls - even when not needed
[fix] 249307 WebClient images do not anchor
[fix] 219146 Allow extending an existing multi select selection easily through scripting
[fix] 249761 Format for currencies fields
[fix] 249762 Application.overrideStyle doesn't effect form background style
[fix] 249623 TEXT_AREA fields are breaking the reverse tab sequence (when using Shift + Tab) if they are the last field on a form

Developer changes:
[fix] 247147 Servoy team provider does not warn for dirty editors before committing
[fix] 246424 User country preferences i18n editor is wrong by default
[fix] 247148 Servoy Team Provider: merge action cannot handle simple merges automatically
[fix] 247755 Dataprovider Editor Filter Box Infinite Loop
[fix] 249543 Intermittent problems with RC2.
[fix] 248788 Searching for objects in the picker where you can select over relationships is impossible with lots of linked relationships
[fix] 250592 Stackoverflow with code completion
[fix] 249343 Developer freezing up temporarily when on a large .js file
[fix] 248146 Sybase database license corrected

Hi Jan,

I especially like this release!
Servoy 5 rocks!

Thanks to you and all the team!

I tried to use my 3.5.10 application by importing first into 4.1.4 then into 5.0.0.rc3 with the same results :
dreaded stack overflow and the polite message: please exit!
Yes. it is a large application, many modules and one large main module. So I think that maybe the fix for stack overflow reported as being fixed may have to be revised.
There is no related log error message. Stacktrace is on.
Perhaps I should break this app into more smaller modules to see if that still breaks the developer?

After some more sleuthing I found this is a "build" error while it tries to activate the large solution.
Here is part of the error log created:

java.lang.StackOverflowError
at java.util.ArrayList.get(Unknown Source)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testContains(CombinedOrReference.java:73)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testTransparentRef(CombinedOrReference.java:104)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testContains(CombinedOrReference.java:76)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testTransparentRef(CombinedOrReference.java:104)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testContains(CombinedOrReference.java:76)
a

this continues for a total of 1025 lines.
IS this a bug or have we overloaded capacity in some way?

OS: Winxp pro, Java 1.6_15

Issue:
Moving forms to another module seems to remove all calculations on all dataproviders so that there are no longer any calculations.
For example I moved a lot of forms from one module (named wf_ESS_pitc) to another (named wf_dispatch_pitc). After this I look at the Database_Server for any server and the columns are there but the calculations tab shows under Name 'wf_dispatch_pitc' - see the screen shot.
Now this may be related to the previous error posted and my whole system may be corrupted so I can try to restart from scratch.
However, is this behaviour normal? When moving a form to another module should I do soemthing to save the calculations on a database_server?

Thomas Parry wrote:After some more sleuthing I found this is a "build" error while it tries to activate the large solution.
Here is part of the error log created:

java.lang.StackOverflowError
at java.util.ArrayList.get(Unknown Source)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testContains(CombinedOrReference.java:73)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testTransparentRef(CombinedOrReference.java:104)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testContains(CombinedOrReference.java:76)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testTransparentRef(CombinedOrReference.java:104)
at org.eclipse.dltk.internal.javascript.typeinference.CombinedOrReference.testContains(CombinedOrReference.java:76)
a

this continues for a total of 1025 lines.
IS this a bug or have we overloaded capacity in some way?

OS: Winxp pro, Java 1.6_15

stackoverflow are problems in the code. i will look at this.
It would be nice to know what javascript construct did cause this, but i guess thats not so easy to know.

Johan,
I can try to narrow down the area by reducing the large solution to a smaller one by moving more forms off to another solution(ie a module) and seeing if the build error occurs in one specific area. If you want sample code let me know.

Thomas Parry wrote:Johan,
I can try to narrow down the area by reducing the large solution to a smaller one by moving more forms off to another solution(ie a module) and seeing if the build error occurs in one specific area. If you want sample code let me know.

the stackoverflow shouldnt happen anymore, i already fixed that.
So try out RC4 when it is released.

Thomas Parry wrote:However, is this behaviour normal? When moving a form to another module should I do soemthing to save the calculations on a database_server?

no, if you can reproduce this in a small example with a sotion and 1 or 2 modules then make a case.
forms shouldnt do anything with calculations.

I shall repeat the experiment of moving forms from one module to another and see if the fixes to RC4 will affect the disappearing calculations.
I will let you know the results.

We have noticed that the new event onRightClick on an element is disabled when controller.find() is called. We would really like this event to be enabled like anyother event on a field such as onAction events. Is this an oversite or a bug? We have created a case for this event to be enabled during controller.find(). It should be up to each developer to decide how they use it.

Without this our custom find methodogy becomes very cumbersome and our entire solution takes a hit as we must then attach popup menus to every 'findable' field on a form and remove these attached popup menus when the find state has been cancelled.

Gary
TMA

Hi Gary,

Methods won't trigger when you are in findmode. This is by design, not a bug. There is however one exception.
When you do a controller.search() in a method then Servoy will trigger them.
Even one commented line will do.

Code: Select all

//controller.search()

Hi Robert,

So it sounds like //controller.search() is kind of a backdoor switch when used will let your method runs and the events fire that trigger your method. We don't really care how we get to where we need to be, just as long as there is a way to get there. Servoy is a great tool, just a little more constrictive than the Omnis environment we came from. We haven't been in it long enough to be aware of these little 'trick's.

Thanks,

Gary

Robert,

We found that in version 5.0 it doesn't appear you have to execute the hack (//controller.search()) to enable events and methods to run while in 'find' mode. This is an improvement, but we Servoy still doesn't allow the same flexibility on the dataprovider itself, only on buttons and labels. We really needed this to work on the dataprovider field so we are back to ground zero, with no way to implement an interface that was in our legacy application in Omnis. I'm not sure if this restriction has any reason to exist or if it just Servoy trying to 'protect' beginner programmers from shooting themselves in the foot. As Servoy as a product matures, they need to relinquish this 'parental' type of control which was fine for FileMaker programmers and make the assumption that we are adults now and can handle the consequences of our own 'coding'. I guess this is why some programmers stay away from 4GL's and stick with C++ and Java so they have 'full' control.

My opinion

Gary
TMA

Hi Gary,

Interesting to hear that buttons and labels (i.e. a button without painting it as such) do work now in find mode.
And I actually agree with you on the notion that we are all adults here and that having these methods trigger in find mode as well (even if we have to apply the 'hack' to do so).