Can forms be made to 'remember' control settings? 4

[6ftAndClean]

Being only an occasional VBA coder I occasionally struggle to convert my usual programming practices (ArcView Avenue, Perl) into somthing that works in VBA.

I have a form with around 30 checkboxes. The purpose of this form is to act as a 'user preference settings' control panel. The 30 checkboxes relate to the 30 fields in a large listbox in another form. The checkboxes are intended to allow the user to choose which fields are displayed.

Under other programming environments I am used to being able to store data (arrays, numbers, strings, etc.) on controls and forms in such a way that they will persist until programmatically cleared or changed. Importantly, these values presist when the form, and indeed the program, is opened and closed.

I have spent a while fruitlessly playing with the 'tag' object on the form but this seems only to permenantly store the string typed into the properties box, whilst the form is in design mode.

How can I get the form to remember the state of each of the 30 checkboxes? I think I may have to store each checkbox's state as its DefaultValue. Longwinded and boring!

Any better options?

Thanks in advance!

 

[alvechurchdata]

I share your frustration.

If you Hide the form, rather than Close it then the controls should stay as they are and you can refer to the values on the hidden form.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[snyperx3]

Setting the default value seems like the best method.

Dim ctl As Control
For Each ctl In Me.Controls
    If ctl.ControlType = acCheckBox Then
        ctl.Properties("DefaultValue") = ctl.Properties("Value")
    End If
Next

may work in the form_onunload event

-Pete

 

[6ftAndClean]

Thanks guys.

Thanks for the idea Geoff but I am expecting users to only very occasionally use this form (i.e. 90%+ of the time it will be closed) so hiding doesn't seem to be the best option in this case. I like your idea though, it is an option I have used elsewhere but only as a temporary measure to clear the screen for other forms, etc.

I think I will end up using a variant of Pete's method.

Thanks again,

Nick

 

[6ftAndClean]

Was driving home before I realised I had not awarded you guys some stars! Thanks again for pointing out the options.

Nick

 

[danvlas]

SaveSetting and GetSetting would be another option if you want the settings to be computer-based.

In this way you create registry values that can be written and read from the current computer and used to set the values of the controls in the Load event.

HTH




Daniel Vlas
Systems Consultant

http://www.geocities.com/danvlas/AutoMail.html

 

[RoyVidar]

Well, working with a database tool, why not store it in a table?

Roy-Vidar

 

[danvlas]

In shared database, various users set various options. The table could store the settings per each user/workstation, it's true, and it's a perfectly valid alternative. This should be used if the user needs to get his settings from any workstation over LAN.

However, it's an additional overhead on the database and requires additions, editions and deletions, with their corresponding SQL statements/queries and management tools, not to mention indexes, constraints that will raise errors that have to be handled...

My opinion is that a certain amount of work is saved by writing/reading values to the registry. But only if each user works on the same computer every time - or seldom changes the workstation.




Daniel Vlas
Systems Consultant

http://www.geocities.com/danvlas/AutoMail.html

 

[6ftAndClean]

Thanks for all the additional suggestions.

Pete, sad to report that I could not get your idea to work. Seems that, although the dafault value can be changed programmatically, the form only stores the info whilst the form is open. When it is closed all changes are lost and the form defaults back to what was set whilst in design view. TheAceMan1 has this workaround -

http://www.tek-tips.com/viewthread.cfm?qid=912261

- which I looked into but eventually rejected as being too overblown for what I want to achieve and also for it's possible instability (the end users have no Access knowledge so the system must be reliable).

In the end I linked the form to a "UserPreferences" table and each checkbox to a corresponding field as per Roy-Vidar's suggestion. Although, Roy, I feel that Access could benefit by having the means of storing data on forms and controls that is persistent.

Although I could interogate the OS to find out which user is logged on I am going for a simpler, and in this case, more robust option where the user is identified by part of the application title name (different for each user's front-end).

I then filter to show only the record for the current user.

It all works fine so far (although I have yet to sort out how I can interogate the application title).

Daniel, in this case each front end will be associated with a staff member's computer. There are only 4 staff so it is really a very small controlled environment. As for edits to the table, all I do is store the state of each checkbox for each user. There is no need for additions or deletions. Should staff change they can edit their own details to suit. Additional staff would probably necessitate my involvement to set up a new front end and new user in the prefs table. I shall include instructions in the help files. Didn't know that vals could be stored in the registry though. Could be v useful another time!

Thanks all! Your input and support is very much appreciated.

Nick

 

[MichaelRed]

In even a small group / application, it is best to seperate the (persistient) data from the program and transient data into two sections (commonly refered to as BE / FE and have users log on via network. This provides a good mechanisim to identify the user, minimize network traffic and even personalize the environment for the user (via the table of user preferences).




MichaelRed