saving control properties (e.g. backcolor after a click) @ runtime

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

In Access 2003, on a form, I can change properties during runtime for
controls using VBA (for example... changing the backcolor of a label if it's
been clicked), but I would like to update the color permanently using code
during runtime so that the next time I call the form, the label is now the
new color. Please help! Thanks....
 
Hi,
2 do this u need to save ur details of colors in registry and retrieve
it while loading ur form the next time. u can save details in registry
using save settings and get settings. through code.

best reguards
fd
 
When you close your form, do it like this:

Docmd.Close acForm, Me.Name, acSaveYes

The acSaveYes will save any changes made to the form.
 
Thanks... but I don't know how to manipulate the registry to do this. Can
you explain?
 
In Access 2003, on a form, I can change properties during runtime for
controls using VBA (for example... changing the backcolor of a label if it's
been clicked), but I would like to update the color permanently using code
during runtime so that the next time I call the form, the label is now the
new color. Please help! Thanks....
Click to expand...

To save the changes, you need to open the form in Design View, make
the changes, then save the form.

I have no idea how you are currently doing this, but here is an
example, using code in the already open form to permanently change the
Backcolor of a label:

You can place this code in the label's double-click event.

DoCmd.Echo False
DoCmd.OpenForm "FormName", acDesign, , , , acHidden
forms!FormName!LabelName.BackColor = vbRed
DoCmd.Close acForm, "FormName", acSaveYes
DoCmd.OpenForm "FormName"
DoCmd.Echo True
 
Sounds simple, but that would be a HUGE NO NO. It will do
what you say, but the Database Bloat may rapidly get out of
control, which in turn will force way more frequent Compact
operations. In addition, both the save and the compact
operations greatly increase the chances of corruption, which
then requires a more frequent and more robust backup
procedure. Furthermore, you can not save an object's design
when you get around to making the application into an MDE or
distributing it with Access runtime.
 
Instead of using the registry, save the info using Access's
natural data storage: tables. Records in a table are far
easier to use than registry entries.
 
AND if you send out a new version of the program then all of those
changes are lost.

IF all users are using the same FE then one person's change affects all
others and the last person to make the change is the one whose changes
are saved.

I have an app where many users arranged their columns in different ways
for a number of different datasheet views.

I added a table keyed by user and form along with a save and reset
column buttons.
I saved the column sequence and size for each form for each user If
they pressed the button and restored them to that formation if they
pressed the reset button. For us the FE is replaced quite frequently so
this saved a LOT of time and energy.

Ron
 
Ron2006 said:
AND if you send out a new version of the program then all of those
changes are lost.

IF all users are using the same FE then one person's change affects all
others and the last person to make the change is the one whose changes
are saved.

I have an app where many users arranged their columns in different ways
for a number of different datasheet views.

I added a table keyed by user and form along with a save and reset
column buttons.
I saved the column sequence and size for each form for each user If
they pressed the button and restored them to that formation if they
pressed the reset button. For us the FE is replaced quite frequently so
this saved a LOT of time and energy.
Click to expand...


That just one good reason why each user needs their own copy
of the front end.

Adding a field for the user is a good idea. This way, the
table can be in the back end.
 
Back
Top