Solved Saving Control properties

[Sanguineus]

I have a form that I have opened with a standalone app feel. I also have some code that detects if the application background has been maximised and hides that part again. However to do so Ihave to close and re-open the active form.

What I am struggling to do is save the properties of each control, such as visibility, enabled and values that when I re-open the form I can return each control to its state at the point it was closed rather than a blank canvas.

The only way I have thought of in the last 30 minutes would to be to create a function with multiple variables for each property for each control that I want to store. But I just feel there's got to be a better way than having c.100 variables in a function.

Hopefully someone will have a better idea.

 

[theDBguy]

Hi. Welcome to AWF!

Have you considered using a table to store the form settings?

 

[CJ_London]

not all properties change - you need to store them in a table, then recall them when the form opens. Table might have the following fields

PK
formname
controlname
propertyname
propertyvalue (has to be string)
propertytype (text/number)

and if you need it to be different for different users, include a userFK as well

 

[Sanguineus]

Thank you -- I had thought of that but thought that would be a fairly huge table again with lots of fields for each property, but me being a collossal moron has just realised it wouldn't matter as simple loop would take care of the heavy lifting. Think i've had my head in the VBA Window for far too long today. Thank you both!!

 

[The_Doc_Man]

If the form you close and re-open is bound, you are implicitly saving the associated record regardless of its completion state. So that has to be considered when getting ready to implement your code. If the form is unbound, you will face a lengthy "save" process before you close it because as you point out, you are looking at literally a hundred elements.

I have not had to do what you described, but something I did in the past might be relevant here. I had the concept of a form "state" where a form could be "virgin" (i.e. just navigated and not yet dirty), "new" (just created a new record), "dirty" (at least one element changed), "locked" (which was a data-based read-only state), and a couple of others. Then I had a routine that would take that state and revisit the controls. By using the form state, I eliminated about half of the decision process. If this is a bound form, though, when you close it you lose the individual field information and that would make it nearly impossible to completely effect that return to a previous state.

I would attack the problem by finding a way during the form's OnLoad (or even OnOpen) event to prevent you from getting in this state in the first place. If the app background is in an undesirable state, do something about it immediately and after that, live with it.

 

[CJ_London]

Not quite for the same reason but I use a table similar to the one I suggested, but for translation and user preferences - so primarily caption, backcolor and font properties - and they are set in a 'admin or user design mode' (it also handles vba generated messages) rather than being captured on form close. For the average app there might be 1-200 records (mainly translation).

I load the table into a recordset when the app first opens (saves frequent gets from the BE) and have a function that interrogates the recordset on open to set the relevant properties. It takes no time at all.

I don't capture control dimensions, instead I use the form resize event to position controls and a form 'format' function called from the current event (and perhaps others) to hide/enable/disable controls.

If I wanted to have the form open to the record I was on when I closed the form, I might pick that up from a log table or an entry in the properties table. if the form does not go through a close event (as a result of a powercut/whatever), it probably would not pick up that detail.

control, such as visibility, enabled and values

values bothers me - implies the form is unbound, but could be added to the table

 

[theDBguy]

Thank you -- I had thought of that but thought that would be a fairly huge table again with lots of fields for each property, but me being a collossal moron has just realised it wouldn't matter as simple loop would take care of the heavy lifting. Think i've had my head in the VBA Window for far too long today. Thank you both!!

Actually, regarding the potential size of the table and number of fields in it, I imagine you'll only need a couple of fields and the size would be nothing more than a table storing as many records as the number of properties you want to track. For example, this table structure:

tblFormProperties
ID
FormName
ControlName
PropertyName
PropertyValue

Hope that helps...

 

[Sanguineus]

If it helps this form is a Time in motion tracking form so has a tme and a few drops down boxes to help classify the activity. There are 4 comboboxes and two text boxes (one of which is a timer) I literally only need to hold the values for asecond or two. Between the form closing and then re-opening so storing them in a recordset/table is a good ideafor me. The forms are unbound as I have split the DB into a Front and back end but rather than using linked tables use SQL statemnts with an IN clause to specify the location of the BE. We have a couple of wifi black spots in our public accessible areas so I prefer this approach to a linked table as it prevents a lot of the errors we used to have when the wifi dropped. (in this scenario the data is stored in a local table and uploaded at a later date when there is a connection. Its not fool proof but has helped us save a lot of the data we would have normally lost.

Occasionally the user uses the taskbar icon for the access pplication to restore the form which also shows the ugly application window the only option i've seen is to close and re-open the form - but storeing the values at that point I can essentialy allow the motion tmers to continue while retaining a nice looking application.

Hopefully this makes sense and i've not made too big a fool of myself ><

 

[CJ_London]

makes more sense - however since this is about data capture, would suggest bind the form to a local table (better in a separate BE but local to your user - i.e. somewhere on the c drive, you can still use your IN method) and on form close, attempt to update the server BE - if success, remove from local table, if fail, leave local table alone to update at a later time.

Your timer event can then do a save to the local table as frequently as you want and/or use control after update events to set a timer interval of 1

 

[zeroaccess]

Occasionally the user uses the taskbar icon for the access pplication to restore the form which also shows the ugly application window the only option i've seen is to close and re-open the form - but storeing the values at that point I can essentialy allow the motion tmers to continue while retaining a nice looking application.

Hopefully this makes sense and i've not made too big a fool of myself ><

I avoid all of this mess the following way:

1. Open main forms maximized
2. Access Options > Current Database > select "Tabbed Documents" and unselect "Display Document Tabs"
3. Access Options > Current Database > unselect "Use Access Special Keys", scroll down, unselect "Display Navigation Pane", scroll down, unselect "Allow Full Menus", unselect Allow Default Shortcut Menus"
4. Hide ribbon with DoCmd.ShowToolbar "Ribbon", acToolbarNo
5. Open small forms that don't need maximization as popup

Use code to disable the bypass key and save as .accde.

 

[isladogs]

I am having difficulty understanding what you are trying to do but perhaps two of my example apps may be helpful to you.
Control Application Interface - demonstrates how to show/hide any or all of the application window, navigation pane, ribbon, taskbar
Set Controls - shows how to use the Tag property to set the state of a group of controls at the same time. The properties that can be controlled are: Visible, Enabled, Locked.