Switchboard - Open Form vs. Select Form (1 Viewer)

[Marshall Brooks]

In my switchboard and elsewhere in the database, I open forms like this:
DoCmd.OpenForm "frmFormA", acNormal, "", "", , acNormal

If the form is already open, Access seems to select it automatically.

Is there any drawback to doing this as opposed to something like:

    If SysCmd(acSysCmdGetObjectState, acForm, "frmFormA") <> 0 Then ' if FormA is open
        forms("frmFormA").setfocus
    Else
        DoCmd.OpenForm "frmFormA", acNormal, "", "", , acNormal
    End if

The one line solution is simpler, but I didn't know if there were any disadvantages to telling Access to open a form that was open already?

 

[DenverDb]

Sorry, Marshall, you've got me. I have only used macros to open forms for the past several years.

 

[theDBguy]

Drawbacks? I can't think of any?

 

[Marshall Brooks]

I might have found one, but I'm not positive of how Access Works.

I could run a test by adding a MsgBox in From_Load.

I was adding progress bars to my forms: https://www.access-programmers.co.u...-a-progress-bar-on-form-loading.328507/page-2

I had the form open and then added the progress bars and clicked to open the form again and the progress bar showed up.

So I'm thinking the second method just selects the open form, while the first method has to run through the form load, form activate, form current events.

But I could be wrong, and I'd like to know before I start adding five lines of code where one would suffice.

But if I don't hear from the forum, I'll run a quick test tomorrow.

 

[isladogs]

FYI, default values and empty strings can be omitted

DoCmd.OpenForm "frmFormA", acNormal, "", "", , acNormal

is exactly the same as

DoCmd.OpenForm "frmFormA"

I'll leave you to run your test....

 

[Pat Hartman]

When you open a form that is already open, the Load event does not run and so the form opens showing whatever data it was showing when it previously opened. To see the new data, the form has to go through its open and load events. Therefore, you should check to see if the form is open and if it is, close it. Then open it with the new criteria.

This is one of reasons that I do NOT allow multiple forms to be open at one time. A new form cannot be opened until the previous form is closed. The exception of course is popups. In this case formA opens formB as a dialog. This stops all the code in formA and limits focus to formB. formB must close to give focus back to formA.

PS - same situation for reports. If you open an open report, you see the old data.

 

[MajP]

I had the form open and then added the progress bars and clicked to open the form again and the progress bar showed up.
So I'm thinking the second method just selects the open form, while the first method has to run through the form load, form activate, form current events

As @Pat Hartman points out these events do not happen again on an already open form. So I would be interested in how your progress bars are set up because that should not happen. There are a lot of state changes that do not matter if you "reset" them. You can open an open form and hide/show a hidden/visible form.

 

[Marshall Brooks]

Good info - I haven't run the test, but I trust you guys, and it matches what I was seeing previously.

Odd what VBA likes and does not like. I just tested and you can close a form without it being open also - i.e.

  DoCmd.Close ObjectType:=acForm, ObjectName:="frmFormA"

Works fine even if the form is not open.

FYI, default values and empty strings can be omitted

I'm not going to argue with you and in this case you might be correct. However, for years we had an intermittent "Not Available" error when adding a new record to a form. I found the solution on here. The command we were using was:

GoToRecord , , acNewRec

we changed it to

DoCmd.GoToRecord acDataForm, "frmFormA", acNewRec

and haven't had any errors (over maybe 6 months) - although both lines should do the same thing.

So I would be interested in how your progress bars are set up because that should not happen.

Didn't give you the full story, but here is what I think happened:
I had frmFormA open.
I then opened the VBE and added my progress bars.
I'm pretty sure when I did this, it kicked the form into design view.
I then opened the (already open) form from the switchboard and the progress bars appeared, which surprised me.

I think that since the form was in design view, it had to go back through the load and activate events to get to "normal" view - but I'm not positive about that.

 

[Pat Hartman]

Yes, when you went from design view to normal, the form opening events would have run. It is when the form is currently open in normal view and you open it again, that the opening events do not run. Therefore, you would be seeing old data.

 

[isladogs]

I am correct regarding default values & empty strings.
Your intermittent error could have occurred when e.g. Access 'lost' details of the form concerned due to some earlier error
One of the rerasons for using TempVars! is that they retain their value even after an error occurs

 

[Marshall Brooks]

I am correct regarding default values & empty strings.

I never said you weren't!!! (Although I did somewhat imply that you might be) ...

I just wanted to point out that in some cases omitting the defaults CAN cause errors.

(And if they aren't being specified, omitting them probably would do the same thing as leaving them blank).

No offense intended.

 

[isladogs]

None taken!

 

[MajP]

I am correct regarding default values & empty strings.

I am going to disagree with that statement, if you are speaking in general and not specific to this example. In this specific example you can omit defaults, but as @Marshall Brooks points out it is unsafe to omit the values when they identify the Access object.

So this is fine since you specified the Access object ("frmA")
docmd.openForm "frmA"
is the same as
docmd.openform "frmA",acnormal, ... other default properties such as acFormEdit, AcWindowNormal

This is very different then omitting the default when it is the access object.
Docmd.Close
is definitely not a safe replacement for
Domcd.close acForm, "FrmA'
or

Docmd.gotoRecord ,,acNewRec
is definitely not a replacement
DoCmd.GoToRecord acDataForm, "frmFormA", acNewRec

When you omit the Access object then all bets are off. The active object gets acted on and may not be what you expect. Chasing down these "focus" related problems can be a real pain. It may work under some conditions and then all of a sudden something closes that you do not expect or errors.

If you leave the ObjectType and ObjectName arguments blank (the default constant, acActiveDataObject, is assumed for ObjectType), the active object is assumed.

I just wanted to point out that in some cases omitting the defaults CAN cause errors

Most of the time it is not an error, but it is acting on something you did not assume.

 

[isladogs]

Point accepted.
As I don't consider those as examples of defaults, I don't omit the object items that you gave in your examples.