That sounds great, but I don't think I will implement this, because for starters I use MySQL as databackend, therefore I have no tables, relationships or filters. Once I moved from VFP DBC to MySQL I was so positively surprised how easy it is to work with a C/S architecture that I dropped DBC support from my framework altogether. In the beginning I planned to support both, MySQL and DBC, but there was never a reason for looking back.

I am also not sure if the user would appreciate it if he opens for example a search form, when he finds his old search filters selected. Would that not be confusing? Perhaps there are scenarios where that is required by the user, but I can't think of one right now.

I also changed the approach of data entry screens: Previously I used to open the Data entry screen from the menu, showing either the last record or the first record (never could decide which is the better choice), or no record at all (which turned out to be the best choice after all). There would be a "Locate" button where the user can open a list to select a record, like an employee for instance. Before the search list opens, the form checks if the user has pending changes to commit or discard. When the user deletes a record, it goes to an empty record. There is also a "New" button where the user can create a new blank record.

Now I don't open the data entry anymore from the menu, instead I open the search list first. From the search list the user can scroll through the list, search, filter, change the order etc. Then double click on one record to modify the selected record. There is a button on the toolbar which says "New employee". Just like Outlook with the list of emails. The list stays open until you explicitely close it, which helps quickly opening several records one after another.

I found that approach much more user friendly and intuitive, also it helped getting rid of making strange code, like after you delete a record, what to do? Now I simply close the form of the record that you deleted.

I wonder how others are doing those things right now.



>I have created a class I call SuperStore, which I plan to make available for download as soon as I am done testing it properly, and I need to document it. In short it's a class with a few core elements:

>

You can create a snapshot of all your open tables, with all filters, relationships, index order and currently selected records stored.

>

You can save all normal settings, and restore them whenever you want, or store them to a file

>

The same with all normal SYS() values

>

A reservoir for storing "public" properties, making public variables redundant

>

All properties of this object with names beginning with Save, are automatically saved when the class is released, either implicit or when the application is exited

>

>When you instantiate the class, you can add a parameter to override the default file to read the SaveXXX properties from, and to which file they will be saved. Of course the default is the same file for both, making the handling of configuration values more or less automatic. All properties of this object, whether they already exist or are added while it is alive, are saved when their name begins with Save, as I mentioned. They are saved into a prg, making it very easy to do some testing and then restoring the "correct" values afterwards.
>
>Since this is a class, you can "attach" it to _vfp or _screen, which means that it will survive a Clear All and Release All Extended.
>
>>I used to store certain preferences in the Windows registry, using the Local Machine > Software folder.
>>
>>In Windows 7 that cannot be written to anymore without Administrator rights. I suppose I should use the current_user > software folder now, is this a good place for preferences/settings? I Just wanted to be sure before I do the change.