Keeping Hidden Forms HIDDEN 1

[eksortso]

I have an Access database that opens an invisible Monitor Window, which is used to store global settings. The monitor window is opened via a procedure called by the AutoExec macro. There is also another form that is opened at startup, and this other form is visible to users. It is named in the Startup settings.

However, I am having serious problems with this database, and I don't know why. The Monitor Window, which is supposed to stay hidden, will often reappear when my users run the database. It usually happens when they switch from Access to another application and open something. Usually, the Monitor Window appears when they send an email message in Outlook, or when they open Internet Explorer.

Access's main menu is turned off, so they cannot view the Monitor Window directly. But the window keeps appearing. And there is nothing in the code anywhere in the application that would cause this form to reappear after it has been opened.

Why is it doing this? How can I stop it from becoming visible? Please help!

 

[TheAceMan1]

How are ya eksortso . . .

The Monitor Window . . . is [blue]native access or windows?[/blue]

See Ya! . . . . . .

 

[eksortso]

It's a native Access form. I call it with DoCmd.OpenForm (with the option that keeps it invisible, which I've temporarily forgotten).

 

[randy700]

Why not just store your global settings in a public module? It should accomplish the same results without the need for an additional form.


Randy

 

[eksortso]

I did try storing global settings in a public module. But occasionally, all of the settings would be lost. Nothing in my code was clearing them. The system would just reset them, without errors or warnings.

I started using a hidden form to keep these settings, because this is advice that Microsoft has given in the past.
[URL unfurl="true"]http://www.jnsk.se/articles/body_wrap.htm[/url]
[URL unfurl="true"]http://groups.google.com/ ...[/url]

These settings are dynamically set, BTW. I can't hard-code them. I wish I could, but I can't rely on the servers and directories staying in one place in this office.

 

[randy700]

I personally don't like the idea of an extra form being open. How about storing the values in a separate table?


Randy

 

[eksortso]

I agree, randy700. It's like carving a marble column, then writing your grocery list on it. But it's a Microsoft-recommended practice. I at least expected it to work properly.

Actually, most settings in the system are stored in the database. That's not a problem. But I have settings that cannot be kept on the server, because some of these settings are needed to build connections to the database in the first place.

These settings are read from a configuration file, which is updated by an external update program. If a server moves, I have to change the database settings in the update program. Then my users run the update program to get the new database settings. When the Access app is run, it reads the database settings, along with others, from the updated config file. It will change the system DSN used by the linked tables so that it can find the data, and then it will use the database settings to create connection strings for back-end database stored-procedure calls. It may seem complicated, but it's easy to keep track of. I made sure that it would be.

Hmm. I just realized that putting the second form in the Startup settings might lead to a race condition. That will be easy to fix.

I'll change this bit in the program and see what happens. If there's still a problem, you'll hear from me again. Thanks for all of your help so far.

 

[payback]

I use the CurrentProject.Properties collection(?) to store items that I do not want exposed. Once they are "created" for the application, you can change them or read them using VB. If you want examples, let me know.

 

[eksortso]

payback, that would be immensely useful! Please do post some examples.

 

[payback]

In order to use this, you will first need to create the property (for your information I am using Access XP in Access 2000 format so presume that it works for Access 2000 onwards - not sure about prior versions).

I created the following function, and called it from a macro to initialize the data -

Private Const Registered_Name As String = "MY SYSTEM"

Function SetRegisteredName()
On Error GoTo Errorhandler

    CurrentProject.Properties.Add "RegisteredName", Registered_Name
    
    Exit Function
    
Errorhandler:
    Call Error_Display_Vars(Err, Application.CurrentObjectName)

End Function

The "Registered_Name" variable is a string constant at the top of this module.

Then to read this property, I can use the following function from anywhere (form, report, VB)

Function GetRegisteredName()
On Error GoTo Errorhandler

    GetRegisteredName = CurrentProject.Properties("RegisteredName")
    
    Exit Function
    
Errorhandler:
    Call Error_Display_Vars(Err, Application.CurrentObjectName)

End Function

You can also use the first function to reset it if you want to change the variable e.g. I use similar functions for maintaining a version number that is reset with each release.

 

[eksortso]

That's absolutely perfect, payback. Thank you!