Servoy Forum

We are pleased to announce the immediate availability of Servoy 5.1 beta 2

This version is available through auto update only, always make a backup of your current Servoy installation (directory and database) before upgrading.
To update eclipse open, Window -> Preferences (update sites), change:
-The servoy update site in eclipse to: http://www.servoy.com/developer/5xx_updates/beta
-Disable both eclipse.org update-sites for now, since there is a problem at the eclipse side!

Client changes:
[fix] 267020 Image with a tooltip in form in dialog has display problems in webclient
[fix] 267810 Problem with calculations in 5.1 when using datasets
[fix] 267883 editable field format problem

-Splitpane issues:
[fix] 267362 splitpane obfuscation issue: getLeft/RightForm returns Zs instead of Form
[fix] 267552 splitpane component always has a border, even if you set all borders to empty (splitpane element border + borders of forms in the splitpane)
[fix] 267553 BorderStyle settings do not work for 'splitpane' element
[fix] 267557 dividerSize property required on 'splitpane' element
[fix] 267561 continuousLayout property on 'splitpane' elements required

Developer changes:
[fix] 267935 Enhancement: CTRL+A in form editor when there is nothing selected
[fix] 268022 i18n Editor Error
[fix] 267579 No Dialect mapping for special JDBC type when importing solution exported from ms sqlserver

Plugin changes:
[fix] 268188 The serialize plugin produces erroneous results when serializing/deserializing objects or arrays which contain two different references to the same object
[fix] 266934 Jobs running in scheduler don't go into errorhandler.
[fix] 267745 plugins popupmenu is putting context menus from the treeview bean out of the client and behind it
[fix] 265664 Problem with i18n key usage in plugins

Thanks !!

It solved the two problems I had with beta 1 !!

Another question :

I see that there have been changes in the way the calculations are handeled.
I see a different behaviour and some off my calcs are not fired, this worked fine in 4.x

I do not say that this is a bug, if I understand the new behaviour, I can probably
adjust my code to that.

Can one of the Servoyans explain a bit about these changes ??

Thanks

the calculation engine is changed yes in servoy 5+
It now should only fire on data changes where it really depends on.
Previously we where flushing calcs way more then we do now because we had to make sure that they where correctly calculated.

What change in behavior do you still see in 5.1b2?
Because in the end it still should be transparent.

jcompagner wrote:the calculation engine is changed yes in servoy 5+

Are there any changes to updating of 'stored calcs' as well, in other words:
before 5, only the results of stored calcs using related data were updated when these related records were in cache. Has this been changed?

calculations where really only updated when you asked for them through what ever means (ui or scripting) or when you save the record (then we make sure the calcs are update to date)
this is already the case in <4 and should also be the case in >5

So if you dont ask for them or dont save them your calcs wont update even if those records are in memory or not (if they where not in memory it also wouldnt result in an update)

What change in behavior do you still see in 5.1b2?
Because in the end it still should be transparent.

It has to do with calling a stored procedure in an unstored calc
which is triggered by making a reference to a related field.

Example :

Code: Select all

var _dum1 = bvko_full_offertekaarten_to_offerteregels.offergl_aantal
      
   var args = new Array();
   args[0] = java.sql.Types.NUMERIC;
   args[1] = offekrt_id
   var typesArray = new Array();
   typesArray[0] = 1;
   typesArray[1] = 0;
   var proc_declaration = '{?=call get_offerte_inkbedr_tot(?)}';
   var dmesp = plugins.rawSQL.executeStoredProcedure('berp2', proc_declaration, args, typesArray, 1);
   application.output('ik : ' + dmesp.getValue(1, 1))
   return dmesp.getValue(1, 1);

This calc fires in 4.1 when the related field (bvko_full_offertekaarten_to_offerteregels.offergl_aantal) is changed but not in 5.1
So the _dum1.. line is only there to get the calc fired.

Also I notice that calcs that do fire, fire immediately ( We use Autosave of and transactions)
where in 4.1 they fire after the savedata.

Regards,

so that code you there is your calc and you reference there bvko_full_offertekaarten_to_offerteregels.offergl_aantal so that if that is changed the calc is updated?

so inside some other code behind a button if you do:

var calcBefore = theCalc
bvko_full_offertekaarten_to_offerteregels.offergl_aantal = +1 (alter it)
var calcAfter = theCalc

then calcAfter doesnt trigger the calculation? So it still just gives the previous value (if the value really changes because of the related alter)

Hi,

Since I have upgraded I get an error with the batch processor and some plugins. See here: viewtopic.php?p=70249#p70249

so that code you there is your calc and you reference there bvko_full_offertekaarten_to_offerteregels.offergl_aantal so that if that is changed the calc is updated?

so inside some other code behind a button if you do:

var calcBefore = theCalc
bvko_full_offertekaarten_to_offerteregels.offergl_aantal = +1 (alter it)
var calcAfter = theCalc

then calcAfter doesnt trigger the calculation? So it still just gives the previous value (if the value really changes because of the related alter)

I tested it. It does fire !!
I looked more into my code and it seems that the calc is fired !! where I thought it did'nt.

But I think due to the fact that the calc now triggers BEFORE the save instead of After it,
the data in the database ( bvko_full_offertekaarten_to_offerteregels.offergl_aantal) has not changed yet.
Since a stored procedure does the calculation it works on database data and not on foundset data !!
So the calc is done with the old data, whereas in 4.1 the save is done first, so the calc works on the new data !!

Regards

but thats a weird dependency from your end i think

calcs should be triggered at the moment data did change where they are depended on.

so i guess for you it did work because first the related data is changed and then the data of the record where the calc is in is changed and that always triggered again a recalculation of the data.

So my guess is that it is highly possible that your calculation was done twice in 4 and now once in 5

So my guess is that it is highly possible that your calculation was done twice in 4 and now once in 5

Probably, but I have to use a stored procedure, if I would do the same in javascript within Servoy it would
(i guess) cause a performance issue.

I'll try to trigger the calculation code in my (and Sanneke's ) frameworks Save/Cancel methods.
I'll also try to do it in javascript and look at the performance.

Thanks for the excellent support !!


Regards

After upgrading to 5.1 beta 2 we found that events such as onLoad will no longer file on an cloned form from the solution model. Since all of our forms are cloned using solutionModel.cloneForm that means none of our forms work anymore. A case was created yesterday and a sample solution sent.

Gary

Hi,

I also see issues with onLoad, onRecordSelection methods etc.

In smartcleint started from developer they get the event as an argument and it has a value.

In smart client started from server the event argument is null !!

Is this a known issue in 5.1 b2 ??

Regards,

Gary R. Schaecher wrote:After upgrading to 5.1 beta 2 we found that events such as onLoad will no longer file on an cloned form from the solution model. Since all of our forms are cloned using solutionModel.cloneForm that means none of our forms work anymore. A case was created yesterday and a sample solution sent.

Gary

ahh i know what the problem is have to look how to fix it (and not break the fix i did again)

Hi Johan,

I wished you had a complete description of all the trigger moments of stored and unstored calculations...

My main question now is : Is a stored calculation always executed when touched for the first time in UI ?
If so I think it's not a good idea to use it in case of multi-level calcs with lots of related records (what we need in some places of our app)

Alvast thanks for your previous info on calcs.