Open Form & pass Property

[kirkm]

I want to open a Form and pass a property to it.

However there's code in the Form_Load event that needs that property.
So I have renamed Form_Load event "Activate" and use this

        DoCmd.OpenForm "MyForm"
        Form_MyForm.MyProperty = "Test"
        Form_MyForm.Activate

It works as hoped but is it correct/right ?

Thanks

 

[theDBguy]

Hmm, according to this MS article, the Load event fires before Activate.

Order of events for database objects - Microsoft Support

support.microsoft.com

 

[kirkm]

I'm not using either Form_Load or Form_Activate.
That was a useful article but it didn't show any Get or Let Properties.

 

[theDBguy]

I'm not using either Form_Load or Form_Activate.
That was a useful article but it didn't show any Get or Let Properties.

I was just saying you said the Load event needs the property, so you decided to assign it using an event that fires after the event that needs it. If I misunderstood, then I apologize.

 

[kirkm]

I'm probably nor explaining it properly, it's not assigned to an event that fires after it needs it. That was what was fixed.
My question was, is the fix ok ? Although it's working it could be wrong, or be improved.

 

[theDBguy]

I'm probably nor explaining it properly, it's not assigned to an event that fires after it needs it. That was what was fixed.
My question was, is the fix ok ? Although it's working it could be wrong, or be improved.

Hi. Sorry, I don't think I can state an opinion on your question, because I am still unclear as to what you are doing, but I really hope someone does. Cheers!

 

[moke123]

Perhaps you should explain your in a class module writing a class.

It may help to show more of the code and explain further.

 

[Uncle Gizmo]

However there's code in the Form_Load event that needs that property.

From your question I make the assumption that you're not getting the results you expect.


If that's the case then from experience I can tell you that the events that are called automatically when a form opens don't always produce the results you would expect.


The solution is to create your own public function, and use that public function to set your custom property.


More information about this on my blog here:-

Form Load, Activate, Open, Issue, – Form Load Events - Nifty Access

Form Load Events When you first open a form, the following events occur in this order: Load Events, Open, Load, Resize, Activate, Current.... Now you could be forgiven for expecting that a value passed into a form would be available for the form's events to use. However it's not! These videos...

www.niftyaccess.com

 

[kirkm]

I'm a bit lost as to whats left to explain. Its all in Msg1, Line 1.
Is this an unsual thing to do? It is all working as intended so maybe assume its ok.
Thanks anyway and apologies if an oddball question.

 

[Uncle Gizmo]

However there's code in the Form_Load event that needs that property.

But this won't work.

The property is set after the load event, as explained in my blog....

 

[Uncle Gizmo]

Test it yourself, put a message box in the load event to display the content of the property..

 

[Uncle Gizmo]

So I have renamed Form_Load event "Activate" and use this

Revisiting your question I wonder if you discovered that this didn't work, but then you added the code:-

Form_MyForm.Activate

And this fixed the problem.

So your question is:- is it correct to call the activate event again?

Well I wasn't aware that you could call the ACTIVATE event again.

I will need to test it myself when I get to my PC and then I will know more.

As to the question of whether it is correct/allowed to call the activate event again....

I don't think it's considered good practice. I can't give you good reason why you shouldn't, accept that "it's just not done".

And it's not as if it's the only way to get the result you want, you could use the method I show where you call your own function.

 

[kirkm]

> Well I wasn't aware that you could call the ACTIVATE event again.
It's not again. It's just called once. It's not Form_Activate, just Sub Activate.
In your blog you were suggesting OpenArgs as a solution to a Property. I'm familiar with that method.
Really, my question was about my bit of code. Is there anything "wrong" with it, that is some problem to come I haven't thought of. Or some reason why it's bad.

 

[vhung]

I want to open a Form and pass a property to it.

However there's code in the Form_Load event that needs that property.
So I have renamed Form_Load event "Activate" and use this

        DoCmd.OpenForm "MyForm"
        Form_MyForm.MyProperty = "Test"
        Form_MyForm.Activate

Open a Form
>then 1 property needs to be applied
like: DoCmd.OpenForm "MyForm"
Me.Caption = "Test"

 

[Uncle Gizmo]

Really, my question was about my bit of code. Is there anything "wrong" with it,

Now I'm at my PC I can see that I have assumed that the Forms "Activate" Event is named "Activate" where in fact it is named "Form_Activate"... You are not calling the Form Activate routine, you are calling your own routine. In essence you are doing as I suggested and calling a public Sub/Function named "Activate". I don't see any problem with this other than the fact you have named your routine "Activate"

I would suggest using a less ambiguous name, and also, "Activate" may well be a reserved word, if it is, it could cause you issues... I would suggest naming it either fActivate or MyActivate. Adding a prefix like this practically eliminates the possibility of you Falling Into the trap of accidently using "Reserved Words" in your code... By CJ London It also makes your code very clear, in that you are not using the forms activate event. It's got to be the right thing to do.

 

[Uncle Gizmo]

In your blog you were suggesting OpenArgs as a solution to a Property.

Actually I don't agree with using OpenArgs for anything other than what it was intended for. I promote the use of custom properties over the use of OpenArgs.

 

[MajP]

It works as hoped but is it correct/right ?

Yes you will have to do a workaround like this. This is a limitation in access and one of the reasons for openArgs. Unlike other languages you cannot set the properties before opening the form. So if you need it on load you cannot. You can do a workaround open args.

Or like you said you can build your own procedure in the form and call it. Activate was a bad name for a procedure and caused some confusion. since there is already an Activate event with that name. Instead I would have built a public Procedure (with a better name) and have it parameterized. Then you could do it in one step and maybe not event need the Property.


docmd.openform "myForm"
Forms("Myform").CustomProcedure SomeParameter

Then in My Forms

Public sub CustomProcedure (SomeParameter as datatype)
use the passed parameter
' if you need to store it as a property you can do it here without even a setter
'mSomeClassVariable = SomeParameter
end sub

So to be clear you did not rename an Event you renamed an Event Procedure (Event Handler) and thus all you really did was create a procedure called Activate and got rid of the Event Handler OnLoad

Need to understand events and events handlers. Because you terminology and poor naming convention made this hard for everyone to understand.

What You Need to Know About Access Events

There is often a lot of confusion about Access Events and often answering questions posed here is difficult because of inaccurate terminology. People often say "Event" when it is unclear if they mean the actual event that takes place, the event procedure, or the event property. This thread...

www.access-programmers.co.uk

 

[theDBguy]

Okay, this is starting to make sense to me now. It seems the functionality you're after could have been accomplished with using OpenArgs. But you don't want to use OpenArgs (you prefer custom properties), so you had to create this workaround.

If that's the case, another potential workaround is maybe to use TempVars. I wonder if you could assign a TempVar to a property in the Form's Load event.

Just a thought...

 

[Isaac]

It was also confusing that you stated " So I have renamed Form_Load event "Activate" "
There is no such thing as "re-naming" an EVENT. An event is an event is an event. You can't rename them, only Microsoft can.
Also as Maj said naming a procedure the same as a naturally occurring event is a really bad idea and I'm not sure if it could actually cause some problems, especially if you manually changed a true Event stub to Public. Maybe not, I just avoid naming conflicts so I am not sure.

You don't "pass a property" to a form. You "pass" arguments and parameters into procedures and functions. So your post was extremely confusing.

In the very rare-if-ever case where you have written code in an Event, but due to poor planning, it's not firing because it's not really in the right event, you may be able to force the event to fire by calling it explicitly. If you're outside the class scope of that event you may need to manually change the Private event to Public. In your case it looks like you were trying to make Load fire by Activating the form, which doesn't make a whole lot of sense.
I would recommend using the right events rather than trying to fudge it.

If you take the time to explain yourself in complete detail when first creating a post, it shows responsibility and reasonableness to forum you are asking to help you, rather than putting a 10-word question that numerous people then require a lot of questions to "drag" it out.

 

[kirkm]

I do think the question was well put, and I'm surprised at some responses. Sub Form_Load was renamed to Sub Activate. I almost called it "MyActivate" then decided not to. "Activate" made sense. The Form was Activated with the property available to use. And Activate doesn't seem to be a reserved word. Whether you call it argument or property is semantics, I'm sure it was obvious what I meant.
OpenArgs gets really messy if you've more than one value. I understand now it needn't be Property, a Sub sould have worked too. That's handy to know.
I'll lookup TempVars too. Heard of it but long ago... Cheers all.