Servoy 2024.3.2

[jcompagner]

We are pleased to announce the availability of Servoy 2024.3.2 (release number 3945)

See release notes for changes in this release and in the 2024.3.1 security release.

If you are on LTS release or any older version please upgrade to 2022.3.9 LTS or 2023.3.7 LTS

This version is available through the download site

An installation (coming from the normal installer or from a platform specific archive) is shipping with a Java VM (Java 21.0.1)

So for the platform specific archives you don't need to install or have java on your system.

This release can be updated by using the "latest" url: http://download.servoy.com/developer/latest/ (when you come from 2019.03 or higher)
This release is build on Eclipse 2023.12 (4.30)

See whats new and fixed issues

This is a release in our quarterly release cycle
if you want to stay on the LTS path you need to stick to 2023.03.7 LTS and enabled only the lts update site.

please also update the webpackages that also have releases for 2024.03

If coming from a much older release like 2022.03 then you first have to updated to 2023.03 and then go to 2023.12
This is because of an Eclipse update bug that prevents these updates.

[mboegem]

Hi Johan,

the release notes for this release mention:

It also has a small fix for scrollbars for the main form.

There's zero information on why this fix is done and what consequences this might have.
I've updated to this release in one of my projects as we want to use the latest releases while converting SC to TiNG, but it literally breaks a lot of forms.
We're seeing scrollbars where they weren't before.

For example FID, the dialog dimensions are sufficient to show the form, but suddenly I see scrollbars indicating at least 1/5 of overflow.
In order to get rid of the scrollbars, I need to set the scrollbar property on the form to never/never.
This was never the case and although in this case the FID is not resizable, what if it was resizable? As a result of this scrollbar setting the user can't get to all area's of the form anymore.

[jcompagner]

that main form was just a quick patch on a case what we already had for 23.3.1..
the thing is what we never did was setting the min sizes of a form where you show it. this was kind of incorrect because the height/widht of a form how you designed it is then never used.
So the viewport (the thing you really see) was really the size of the form, and everything that was outside of it was just overflowing.
So if you have a button all the way at the right, bottom corner but positioned with top/left on lets say 800, 800 and and that button is 20pixels height and 80 pixels width and you shown the form in a view that was just 400x400
then the width and the height of that form is really just 400,400 with an over flow (scrollbars) that showed exactly that form so if you scroll all the way down an to the right you would see a "size" of 820x880 and the button was squezed completely in the right bottom corner. but you designed your form the really have spacing so your form was really 900x900 (but this value was never used)

So now we do set the min width and min height to 900x900 and you see exactly how you designed it.
But yes this is not always what you want, because if that button was not set to top/left (800,800) but more like bottom/right (40,100) (so having 20 pixels margins because the height/widht is 20/80.
Then you design a form to be kind of responsive, and you in most (but not all) scenario's you don't need min-width and min-height to be set..
But there are also scenarios. that you design a form to having some bottom or right anchored stuff, but you kind of design this only to be bigger, because you have a lot of top/left with heights and widths set also that require a minimal size an the bottom or right anchored stuff should never overflow the left/top stuff... so in this scenario you also want to have min-width and min-height stuff..

So you do want a lot of time the min width and height stuff to really be correct, the thing is that we never really did set that and that kind of was working for most people because of the whole thing was more relaxed, but it was not really correct...

What we now plan todo and i will also add this to the 2024.3.x stream (so 24.3.3 will very likely have this) that we rename the 2 form properties width and height to minWidth and minHeigth (to really reflect on what they really are) and introduce a "useMinWidth" and "useMinHeight" which can have 3 values: Default, True, False..

The default value is true, but you are able to override this default value through a ui property (to set it default to false, what it was before 2024.3.1)

Then you as a designer are in full control. This is just not something what we can guess or be smart about what you as a developer really mean..

If you now see scrollbars then it is very likely that you just designed you forms to be to big, or you show it in a tab or FID that is to small... because currently we really show it exactly how you designed it

[mboegem]

That is clear and I agree, should be correct.

In the meantime I found the issue and maybe you can comment on that:

1) form in dialog
2) dialog + form settings are matching
3) the form is a css layout with a tabpanel anchored left-right-bottom
4) the tabpanel contains a form that is bigger than it should be.

This tab form causes the overflow on the main form.
Is this correct or should the tabpanel container show the scrollbars?

[jcompagner]

are you sure it causing overflow on the main form? not in the tab?
but i guess we need to see this sample, to actually see what is going on because i guess currently you have 2 forms (the main for in the fid and the tab form in the tabpanel) that now both have min sizes set..

But as an example if you remove the tab form for a moment, or you make it much smaller then no overflows anymore (no scrollbars?)

[mboegem]

It's definitely the main form that's overflowing.
Correcting the size of the form that is used in the tab resolves it (and it was too large anyway).

Unfortunately a similar structure in a sample solution doesn't show this, so it might be custom css that is causing it.
Need to dig in further.

[huber]

Using Developer Version 2024.03.2 and looking at the Property > Component settings, there is a difference of 1 property in the case where the data grid already existed, and when making a new data grid.

The difference is the property: continuousColumnsAutoSizing.

I also noted that for the new data did to enable auto resizing the columns, one just has to click the plus (+) button in the Value column to activate it, then a set of defaults appear.

Is my assumption correct, that both, the newly created and already existing data grids are the same, except the displaying of the continuousColumnsAutoSizing property on the already existing ones?

Regards,

new data grid.png

existing data grid.png

[paronne]

Hi Robert,

the property continuousColumnsAutoSizing has been deprecated in favor of the columnsAutoSizeOn which has more fine-grained settings.
On new grids you don't see the boolean continuousColumnsAutoSizing but just the new columnsAutoSizeOn. For your existing grid you can also use columnsAutoSizeOn and discard the old continuousColumnsAutoSizing setting ( right click the property & restore to default ).
To note, since these settings are often global ( you normally want your grids to behave consistently across all forms ) could be configured globally using the NG Grid services:

Code: Select all

   var columnsAutoSizingOn = plugins.ngDataGrid.createColumnsAutoSizingOn();
   columnsAutoSizingOn.columnRowGroupChange = true;
   columnsAutoSizingOn.columnResize = false;
   columnsAutoSizingOn.displayedColumnsChange = true;
   columnsAutoSizingOn.gridSizeChange = true;
   columnsAutoSizingOn.toolPanelVisibleChange = false;
   plugins.ngDataGrid.columnsAutoSizingOn = columnsAutoSizingOn;


These settings basically define when the grid should recalculate column's width trying to fit all columns in available with without horizontal scrollbar ( if possible ).

Regards,
Paolo

[huber]

On forms with Choice Group elements, I noticed that the Component > alignment property vertical does not work anymore. If I switch between horizontal and vertical, nothing happens.
May be someone can confirm this.
Regards

[jcompagner]

compared to what version? and are we talking about the bootstrap Choice Group?
there are not really any changes for this (since beginning of last year), and the only thing TiNG (bootstrap choice group) really does it add a class "horizontaldirection" to the component

[huber]

Compared to 2022.06 which does differentiate between vertical and horizontal setting. Servoy 2024.03 can only horizontal, which is the default.

Please see the 2 screenshots. They are done in the form editor of 2022.06 and are shown in the application correctly (vertical or horizontal, depending on the setting). Not so in 2024.03

Hope this helps.

Regards,

[jcompagner]

but now you are comparing versions that are almost 2 years apart.
and are both NG1? or is the 22 version NG1 and the 24 version TiNG?
(a lot of defaults changed)
And i guess we talk here about the legacy choice group?

[huber]

You asked what I compare Yes, 2022.06 is NG1, whereas 2024.03 is NG2. I am talking about the latest (newest) Choice Group in 2024.03.

The problem in 2024.03 is simple: If I set the Choice Group to vertical, it still remains in horizontal, but I need vertical. Attached a screenshot how it looks correct (2022.03) and wrong (2024.03) in the application.

[mboegem]

Hi Robert,

Just ran a quick test in v2024.6 which is using the same component package (2024.3.3)
The choice group component works fine for me, so setting either horizontal or vertical does display as expected.

You could check the exact setting in the '.frm' file to see if it has really changed
(so after you change do you see a change in GIT?)

Another option would be to check the result in a brand new form.
If that works, just compare the structure of these 2 instances in the .frm files.

Hope this helps

[huber]

Hi Marc

Thanks for your hints.

I checked in 2024.03 the file and the code part looks like the following code when setting the choice group to horizontal. When setting the choice group to vertical, the line: alignment:horizontal" is removed.
That seems to be correct (vertical seems to be the default). But the behaviour of the choice group does not follow the vertical/horizontal setting in my form.

I also created a new form and voilà, the choice group setting works as expected.

As the original form is a copied SC form, it seems there is some code in the form which prevents in the Developer 2024.03 the correct behaviour (do not know about the LTS version). Quite weird, as it works correctly in the 2022.06 version.

Code: Select all

{
cssPosition:"160,20,-1,160,-1,120",
json:{
alignment:"horizontal",
cssPosition:{
bottom:"-1",
height:"120",
left:"160",
right:"20",
top:"160",
width:"-1"
},
dataProviderID:"selectedReceiver",
formIndex:0,
inputType:"radio",
styleClass:"checkbox higher",
tabSeq:7,
valuelistID:"05ED80F8-7760-4628-BD7A-432EECAB2309"
},
styleClass:"checkbox higher",
typeName:"bootstrapcomponents-choicegroup",
typeid:47,
uuid:"3EDD2E87-EEDB-46AD-A67E-6A828E39276C"
},


Regards,