Ask Reuben
Disabling Stored Settings
My Window or Table is the wrong size?
My Window or Table is used by multiple programs, how do I stop the stored setting values from one instance of the program being inherited by another.
When multiple people are using a PC/Browser, how do I stop one persons stored settings values being inherited by the next user?
Stored Settings is where the Front-end client remembers certain properties about a Window or Table so that when the Window or Table is reused, the certain property values are retained. For Windows this include the position, size, and state of the window. For Tables this can include the column width, the order of the columns, and the sort column.
For a Window, this means that the user can position multiple windows on their screen so they can see the information they require, and then the next time they run the program, the windows appear in the same position and with the same sizes.
For a Table, this may mean the user adjusts the widths of each column so that they are wide enough to display the typical data.
We do not document what format the stored settings data is in as it may change, but we used to document it, so some of you may recall seeing it in older versions of the GDC documentation.
Most of the time, the Stored Setting behaviour is desired but there are times where it is not, and I will cover some of the ways you can disable the stored settings.
The most common time you should want to disable stored settings is in the development environment. The trap you do not want to fall into is having the developer initially create a window or table column with an inappropriate size, and then for them to resize it in their development test environment, and have that value retained via stored settings for the rest of the development cycle. What then happens is that when the end-user first runs the program, they get the initially coded inappropriate size. The developer would’ve been better advised to code the window or table with the appropriate size in the first instance.
That is why I recommend developers disable stored settings in their development environments, that way you can be assured that when the end-users first run a Genero program, they see the Window or Table as the developer saw them when he/she was testing their program. I say end-users, normally I’d expect there to be some QA process between the developer and the end-user, but the same principal applies. Your QA testers either need to ignore stored settings, or know how to clear stored settings between each test cycle.
You can configure your development environment to ignore stored settings. To do this in the GDC, use the Disable the Stored Settings option, or if you are using the GBC via the Settings icon in the Chrome Bar. Same screens have options to clear or reset stored settings.
Stored Settings can also be disabled on a per Window or per Table basis via the use of Presentation Styles. This is via the forceDefaultSettings Style Attribute that can be assigned to a Windows Presentation Style or a Table Presentation Style.
A common usage for this is with generic windows or tables where you do not want the stored settings for one usage to carry over and be used in another usage of that generic window or table. You can see in my fgl_zoom example where in the fgl_zoom.4st file the fgl_zoom style for both Windows and Tables has the following line …
<StyleAttribute name="forceDefaultSettings" value="yes"></StyleAttribute>
… and both the OPEN WINDOW line in the .4gl and the TABLE definition in the generated form have STYLE attribute set to reference this.
The other common usage to disable stored settings is where the program is being used by multiple people on the same front-end device. This could be as a POS in a retail environment, or a Kiosk in a public environment. In this case you will want to disable stored settings so that user B does not inherit the changes made by user A.
The final point I will make is that you will note in the documentation that we have the following …
“When changing the layout of a form, for example when adding fields and containers, the window/form settings currently stored on the front-end side may disturb the new layout.
Or, when shipping a new release of the application, you may want to reset all stored settings for some forms.”
“It is strongly recommend that you clear stored settings when migrating to a new major release of GDC. You might otherwise encounter some side effects due to corrections or new functionality.”
You may ask the genuine question as to how do you do that? There is not a front-call that allows you to clear stored settings, or get/set individual values. The technique is to use the VERSION attribute for a form. If the front-end detects that the VERSION is different then it will clear the stored settings for that form.