Solved Closing a form from the Form_Load event (1 Viewer)

zelarra821

Registered User.
Joined
Jan 14, 2019
Messages
819
Hello.

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

If I put this:

Code:
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.
 
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
 
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.
 
Last edited:
The Open event has a Cancel argument, the Load event does not. THEREFORE as @AHeyne was trying to tell you, the Open event can be cancelled thereby stopping the open process from continuing but the Load event cannot be cancelled. So - use the Cancel event of the Open to stop the form from opening. Is that more clear?
 
would have thought a better process would be

Form 1-->asks if you want to execute an action -->If you say yes-->open form2
 
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).
 
Ask if you want to add a sale -->
Why would you ask? This seems to be pretty annoying. The user opened the sales form, why else would he open it if not to view or add a sale? Either allow direct adds to the form or add a button on the form that the user can press after he opens it OR give the user two buttons on the first form - openAdd, openView.
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)

//
You don't have the information to complete the sale record. You should NEVER create incomplete records.
if there are already sales, they undo the creation of a new record and return to the previous record (this is also done perfectly).
If you hadn't created the incomplete record you wouldn't have to undo the creation.
 
Ok, I've fixed it now.

I did this:

Code:
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.
 
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.
There is a better solution if you are open to it. When the open event runs, the user hasn't attempted to do anything. Asking him at this point is really annoying and he will tell you that after a short time of using the application.

You can catch the attempt to add by putting your question into the form's BeforeInsert event. The BeforeInsert event runs as soon as a single character is typed into the form. That way you won't bother the user with a useless question. When you use unnecessary prompts like this you actually end up training the user to always ignore your questions and that is not what you want. So, do not pop up messages unless they are absolutely necessary. I would not even prompt in the BeforeInsert event. Why? Because I always validate the data of a form before it is saved so if a user accidentally starts a new record, my form level BeforeUpdate validation code won't let Access save the record unless it is complete and has no invalid data. That solves the problem of creating bogus records.

A different solution that might suit your sensibilities better is to have a button on the form so that until the button is pressed, the user cannot add/update the current record.

Regardless, I would STILL, ALWAYS validate form data to prevent saving records with bad or missing data.
Code:
If Msgbox("Are you sure you want to add a new sale?",vbYesNo) = vbNo Then
    Cancel = True
    Me.undo
    exit Sub
end If
 
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.
 
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.
 
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.
 
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.
 
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.
 

Attachments

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.
 
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.
 

Users who are viewing this thread

Top Bottom