Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1]
  Reply  |  Print  
Author Topic: Retrieving Stored Settings  (Read 17661 times)
Martin R.
Posts: 3


« on: December 20, 2007, 01:47:12 pm »

We have a request from a number of our clients regarding the use of Stored Settings.

A large number of our forms have lots of columns, and individual companies only require a subset of them (or want to move the position of some of them to the left so that they are seen without needing to use scrollbar).
Obviously this is where stored settings become very useful - one of the selling points of moving to Genero.

However, our customer's IT departments don't like the idea of individual users hiding table columns (which will be stored) only for someone else to use the same PC and panic because a column has 'disappeared' from the system - not all users understand the concept of hiding/showing columns !!!!!

My understanding is that if the GDC has stored settings disabled then any pre-existing stored settings are not retrieved from the client - the 'standard' settings will always be used.
Is it possible to change this behaviour, so that for example the IT department could
1. set up the client with stored settings enabled
2. go into relevant forms and set the 'company standard' form layout
3. disable stored settings on the client
4. client will now use the settings that were stored previously, but any subsequent changes will not be stored, so every time a form is opened up the 'company standard' layout is presented.

As a second request, they would like the ability to copy stored settings between clients - again as a company standard they may want certain form columns hidden and with over 200 separate PCs running the software it would be very time consuming to individually open up each client and get the settings stored. 
Sebastien F.
Four Js
Posts: 545


« Reply #1 on: December 20, 2007, 02:16:12 pm »

Martin,

Instead of looking for a solution on the client side, did you consider to manage configurable forms/TABLEs from your application?

I mean, you could use the ui.Form.setDefaultInitializer() method to modify any form that is loaded by your applications, and set hidden=1 or 2 for TableColumn nodes, according to a configuration file based on table.column keys (like .sch).

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/ClassForm.html#setDefaultInitializer

This solution would be a centralized solution...

Note that HIDDEN can take 3 values: 0, 1 and 2

https://4js.com/techdocs/genero/fgl/devel/DocRoot/User/FSFAttributes.html#FA_HIDDEN

Seb
.
Four Js
Posts: 115


« Reply #2 on: December 20, 2007, 02:38:54 pm »

My understanding is that if the GDC has stored settings disabled then any pre-existing stored settings are not retrieved from the client - the 'standard' settings will always be used.
Is it possible to change this behaviour, so that for example the IT department could
1. set up the client with stored settings enabled
2. go into relevant forms and set the 'company standard' form layout
3. disable stored settings on the client
4. client will now use the settings that were stored previously, but any subsequent changes will not be stored, so every time a form is opened up the 'company standard' layout is presented.

The current behavior will not change, as I would bet that lots of users will be very confused if we change the behavior now. (Especially if the current behavior is ok for them).
But what can be done is to add another option to do what you expect: use Stored settings as "Read-Only", i.e. read the settings but not change them.

I've registred the following feature in our request list:
#2446 Read-Only Stored Settings

As a second request, they would like the ability to copy stored settings between clients - again as a company standard they may want certain form columns hidden and with over 200 separate PCs running the software it would be very time consuming to individually open up each client and get the settings stored. 

This has also been registred (Feature 2447: Import/Export of Stored Settings).
Today, you could export the registry and import it again if you're running Windows version. This is supposed to work, but of course, as any other Registry manipulation, this is not recommended and must be done very carefuly.


Anyway, Sebastien's suggestion may also be useful for you. This may be more work on your side, of course, but this may makes your application much better. I don't know if this is possible with your app, but if each user is authenticated, you could have by programation a default state (and use ignore settings for the whole GDC or just for the given form), and store the state when closing the window in a database table, and reload them using ui.Form.setDefaultInitializer().
So on any workstation the end-user will have it's own settings configured.
Martin R.
Posts: 3


« Reply #3 on: December 20, 2007, 02:51:54 pm »

Thank you both for you responses.

I had considered adding functionality to our base application so that each company (or each user within a company) can have their own settings for each form.
This may be the way we go, but I'm not sure how user-friendly we could make this, and if its not user friendly our customers won't understand it !

Read-only stored settings would definitely work for me, and combining that with the ability to export/import settings across clients would remove the need for the manual solution you have suggested.

I guess my final decision will depend on whether and when you could provide your changes, compared with how long it will take us to write a user-friendly maintenance routine.

Sebastien F.
Four Js
Posts: 545


« Reply #4 on: December 20, 2007, 03:05:39 pm »

I guess by "user friendly" you mean the ability to configure visible columns as you do today with the hide/show contextual menu of GDC...

Of course that's not possible with 4gl today...

However, if you consider the configuration of your application from the database point of view, you would just have to implement list where with table.column and check box to indicate if the column is usable or not in the application... no need to go to each form and check if the column is there or not...

Note that this could apply not only to TableColumns, but also to simple form fields.
However, there might be some layout-reorg issues if you hide fields on the fly.
But theoritically, front-ends are supposed to deal with that.

Seb
.
Posts: 14


« Reply #5 on: December 20, 2007, 09:11:56 pm »

We have a request from a number of our clients regarding the use of Stored Settings.

A large number of our forms have lots of columns, and individual companies only require a subset of them (or want to move the position of some of them to the left so that they are seen without needing to use scrollbar).
Obviously this is where stored settings become very useful - one of the selling points of moving to Genero.

However, our customer's IT departments don't like the idea of individual users hiding table columns (which will be stored) only for someone else to use the same PC and panic because a column has 'disappeared' from the system - not all users understand the concept of hiding/showing columns !!!!!

My understanding is that if the GDC has stored settings disabled then any pre-existing stored settings are not retrieved from the client - the 'standard' settings will always be used.
Is it possible to change this behaviour, so that for example the IT department could
1. set up the client with stored settings enabled
2. go into relevant forms and set the 'company standard' form layout
3. disable stored settings on the client
4. client will now use the settings that were stored previously, but any subsequent changes will not be stored, so every time a form is opened up the 'company standard' layout is presented.

As a second request, they would like the ability to copy stored settings between clients - again as a company standard they may want certain form columns hidden and with over 200 separate PCs running the software it would be very time consuming to individually open up each client and get the settings stored. 

Martin,

We had the issue you described when we rolled out a POS application nationwide.  Head Office wanted to dictate the column settings that applied to a screen in the POS application for the 600+ POS lanes up/down the country.

The solution we hit upon involved using the import/export functions of regedit.

Head Office sets the columns up as they want, and then click a button that leads to the following code being executed ...

 
Code
  1.  LET l_command = 'regedit /e "', l_filename, '" "',
  2.   'HKEY_CURRENT_USER\\Software\\Four J', ASCII(39), 's Development Tools\\GDC\\Forms\\Table Columns\\', l_formname,'.', l_screenrecord,'"'
  3.  
  4.   CALL ui.Interface.FrontCall("standard","execute",[l_command,1],l_ok)
... This stores the registry settings in a .reg file on the network.  Then when the POS programs are run they execute the following to import the registry settings from that .reg file.  Then when the window is opened it uses those settings ...

 
Code
  1. LET l_filename = "../reg/", l_formname,"_",l_screenrecord,".reg"
  2.   LET l_command = 'regedit /s "', l_filename,'"'
  3.   CALL ui.Interface.FrontCall("standard","execute",[l_command,1],l_ok)
... The .reg file is stored and distributed in the same manner as the GDC images.  The reg folder is at the same level as the pics folder in the GDC

The only trick in the whole process is you have to remember that the registry settings aren't written to the registry when the user moves them around on the screen but later when the user exists the window.  So the head-office user has to change the screen to how they want it, exit the window, re-enter the window and then click the button to save the settings.

Also this is on Windows, but I am sure the method would work equally well with other platforms replacing regedit with the appropriate command.

Hope that helps,

Reuben
Pages: [1]
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines