Solved Closing a form from the Form_Load event

[zelarra821]

Hello.

I am trying to close a form from the Form_Load event when a boolean variable is True.

If I put this:

Private Sub Form_Load()

    If Cerrar = True Then DoCmd.Close

End sub

I get the following error:

2585

This action cannot be executed while a form or report event is being processed.

Therefore, I wanted to know if there was someone who could guide me on how to do this.

Thank you very much.

 

[AHeyne]

Did you try to alternatively use the forms 'Open' event instead and set its parameter 'Cancel' to 'False' in case?

 

[zelarra821]

I don't get it.

Here is the sequence

Form 1 --> Button to open Form 2 --> Asks if you want to execute an action --> If you say no --> You have to close Form 2

 

[LarryE]

So you wish to immediately close the form you just opened. Is that correct? Because that is what your code is doing. If you wish to close a different form then you need to complete the command with DoCmd.Close "Form 2". The command needs to know which form you wish to close.

 

[CJ_London]

would have thought a better process would be

Form 1-->asks if you want to execute an action -->If you say yes-->open form2

 

[zelarra821]

Please wait a minute, you either misunderstood me or I didn't do it very well.

Main Menu -->

Button to open the Sales Form -->

Ask if you want to add a sale -->

If the user says yes,

a new record is added with the code of the sale associated with the record (this is already done perfectly)

//

On the other hand, if the user says no, two possibilities:

if there are no sales recorded yet because they are just starting to use the database, they have to close the form;

now, if there are already sales, they undo the creation of a new record and return to the previous record (this is also done perfectly).

 

[zelarra821]

Ok, I've fixed it now.

I did this:

Private Sub Form_Open(Cancel As Integer)
        
    If DCount("*", "TTPV") = 0 Then
    
        Select Case MsgBox("Vas a generar tu primera factura, ¿quieres seguir?", vbYesNo, NombreBD)
        
            Case vbYes
            
                AplicarDiseñoFormulario Me
                
                TempVars!CrearFactura = True
                
            Case vbNo
            
                Cancel = True
                
        End Select
    
    End If
    
End Sub

With this, I manage to guide the user so that he doesn't get any errors or get confused when creating new sales, that's why I put the message to warn him that he is going to do it, because deleting it later is a hassle and the codes have to be consecutive by law.

Thank you all very much.

 

[zelarra821]

I'm going to do what you are proposing, @Pat Hartman . Thanks for you help.

 

[The_Doc_Man]

Just for the record, the last time I ran into this one, I found out that you stop it from opening in the Form_Open routine or else you have to wait until the Form_Current routine - at which time if you really wanted to catch it, and if your _Current code doesn't actually change anything to make the form dirty, you can just close the form safely from there.

I know this because of experience. You do know what it means to be experienced, right? You recognized your mistake when you make it again. About 2007 or 2008 I was confused enough to attempt the same thing and learned (the hard way) that once you get into the Form_Load routine, you ARE going to open that form.

 

[gemma-the-husky]

I presume there are some things not yet available to a form until after it has opened, as otherwise there would be no need for a form load event as well as a form open event.

I can't recall precisely, but I know I often have both events in my code, so there must be some objects that aren't available immediately.

 

[DickyP]

I do this differently - just open the form but add a value(s) to the openargs that will indicate that you want to create a new record, or if not the record you want to select to edit.

I have standard Library code which uses semi-colon separated value pairs in my Open Args so I don't have keep reinventing the wheel.,
In the openform code I pass:

"IsNew=True;"
or
"IsNew=False;RecordID=1234;"

If I don't want to traverse all the records then of course it is just "IsNew=False;" and use criteria to go to and exact record.

In the form opened I check in the Open event if the OpenArg Exists by using the function

If OpenArg("IsNew") = True Then .....' and check/retrieve its value with a separate function.

var = GetOpenAgr("IsNew")

I have been using this code virtually unaltered since Access 97 back in the last century and it works.

 

[isladogs]

I know this because of experience. You do know what it means to be experienced, right? You recognized your mistake when you make it again. About 2007 or 2008 I was confused enough to attempt the same thing and learned (the hard way) that once you get into the Form_Load routine, you ARE going to open that form.

To be pedantic, that's not 100% true.
Although doing so is pretty dumb, If you just put DoCmd.Close in a Form_Load event, the form WILL close immediately (or appear not to open).
However, if you put any other code such as a message box before that code line, the form will stay open.

 

[DickyP]

Order of events for forms and sub-form when opening:

Open => Load => Resize => Activate => Current.

On closure:

Unload => Deactivate => Close

See attachment for the rest of the document from which I sourced the above.

 

[The_Doc_Man]

To be pedantic, that's not 100% true.
Although doing so is pretty dumb, If you just put DoCmd.Close in a Form_Load event, the form WILL close immediately (or appear not to open).
However, if you put any other code such as a message box before that code line, the form will stay open.

In my case, neither DoCmd.Close nor anything else I tried would close the form from _Load. Kept on giving me a "Action not available" message. I don't recall whether I actually built a _Load that ONLY contained DoCmd.Close or not. But I eventually learned to do it using the _Open via a Cancel=True. This was Ac2007, perhaps, and that what ... 17 years now? It was for the Navy and I wasn't allowed to keep my notes because the app was indirectly involved in a security-action tracking function, basically a log/journal of system patches across multiple CPUs and multiple projects. I was building in a role-based security setup. Eventually got it to work right.

 

[The_Doc_Man]

I presume there are some things not yet available to a form until after it has opened, as otherwise there would be no need for a form load event as well as a form open event.

Actually, the events are pretty straight-forward as to what they do.

The _Open event opens the form object and the recordset object. and anything else that might be openable. The _Load event reads the form object and places the conttrols contained therein. The _Current event looks at the now-open recordset and synchronizes the bound controls with the current record. (There's maybe a little bit more to it than that, but that's the idea.) Note specifically that the controls theoretically get painted "empty" before they get loaded with data. If you have a complicated routine in the _Load event, there might be just enough of a delay that you see the tiniest flicker as data gets loaded. That might also occur on first load if you have a non-trivial _Resize or _Activate event, since they occur before the _Current event.

Note also that if there is a populated sub-form, that gets populated first. Sub-forms are processed before main forms. Note also that sub-forms don't fire the _Activate event on initial form load.

 

[Uncle Gizmo]

In my tinkering with MS Access, I became quite frustrated with the Load event because it didn't behave as expected. I tried placing custom properties in the form's code module and setting their values when the form was opened, expecting to use these properties in my code.

However, I discovered that Access ignores these custom properties during the Load and Open events. It seems that, in Access's mind, these properties are not available to the VBA code during these events, which I found both strange and annoying.

After much experimentation, I realized I could create my own pseudo Load/Open event. Essentially, this involves writing a public function and calling it explicitly. Initially, it felt odd to create a function to emulate the Load or Open event in the way I wanted, but I soon understood this approach has its benefits.

The Load and Open events are intended to set up the form in a specific manner as designed by Access. If you deviate from this standard setup, it makes more sense to put your custom code in a separate function rather than in the Load or Open event or any other built-in event of the form.

So, what am I trying to convey here? I created a public event, which I named `fSetUp`. By doing it this way, I can set the custom properties to the desired values and then call the `fSetUp` routine, which has access to these custom properties.

 

[zelarra821]

Ok, thanks for all anwers. Thanks.