servoy.properties file filled up with window rectangle info

Hi all,

I just noticed that my servoy.properties file is filled up with lines similar to:

...
rect_solution_name_window_name_bounds=763,415,456,283
...

These appear to be the saved position and size of dialog windows. I can see these entries only in Servoy Developer (the regular server do not have that)

In our case, we display dynamically generated forms with unique names in dialogs, so we simply use the unique form names for the dialog window names as well (by unique, I mean GUIDs). This basically causes a new entry to be saved to the .properties file every time I test/debug something which displays a dialog.

Is there a way to disable the option of saving the last position and size of dialog windows in displayed by a solution running from the Servoy Developer? Is there any performance penalty for using unique window names when the application runs from a regular application server?

this is a client feature (so yes don’t see it on a pure server properties file) because that data is specific to a client.

This can’t be disabled currently, its just a feature that sizes are stored automatically for you for windows/dialogs so that the next time they are on the place and have the size the user did want…
(i personally really really hate that when a program doesn’t do that, for example eclipse → preference dialog… really annoying that it doesn’t store my last size)

I my eye’s you really should use the same name for specific features that are shown to a user. This way the same kind of dialog the next time has the sizes the user wanted.

Please open a case if you want to disabled this, then we have to see if we just make it a application property (for all the windows/dialogs) or for a specific one.

I can definitely see where something like this is a “must” for certain dialogs/windows, however there are cases where this feature needs to be disabled - like in our case where multiple instances of the same “type” of dialog can be displayed at the same time but each instance is unique and will never be shown again (think for example, the file properties dialogs of the OS - you can open as many as you want of those, each for a different file; they are all the same “type” of dialog but you would not want to save the position and size of each one of them because every time a different instance of that dialog type is displayed). I think that the option to store or not the last position and size should be at the individual window instance level, so perhaps it can be a new property of the JSWindow class? You can have it enabled by default to match the current behavior but allow it to be disabled, when necessary. I will add a feature request for this in the support system.

i agree with the file properties dialog, but that is a very special one because that is a “context dialog” that should open at the place of the context menu itself, because there is where you do your action.
And this is possible by just setting the location and size hard in the code (so besides the initial location properties)

yes - this is exactly what we have - context driven dialogs which are controlled in code as far as size and position is concerned and would like to prevent any caching of their last position/size, otherwise the client cache will be filled up with data which is never going to be used again