flaky events in A97

[MLH]

open form in design view
then allow it to be opened into form view
from code.

then set its visible propery to false
then open into design view from code
then set its visible propery to false
then open into design view from code
then set its visible propery to false
then open into design view from code
then set its visible propery to false
then open into design view from code
..... over and over and over

Activate event fires EVERY time.

However, if form is NOT first opened in
design view... if, instead, it is closed and
not opened at all and you do everything
else as above described - Activate Event
NEVER fires.

Is Access 97 broke, my computer broke or
am I broke?

[David W. Fenton]

MLH <CR**@NorthState.net> wrote in
news:bh********************************@4ax.com:

open form in design view
then allow it to be opened into form view
from code.

then set its visible propery to false
then open into design view from code
then set its visible propery to false
then open into design view from code
then set its visible propery to false
then open into design view from code
then set its visible propery to false
then open into design view from code
.... over and over and over

Activate event fires EVERY time.

However, if form is NOT first opened in
design view... if, instead, it is closed and
not opened at all and you do everything
else as above described - Activate Event
NEVER fires.

Is Access 97 broke, my computer broke or
am I broke?

I don't understand.

What does design view have to do with it?

Why are you opening it in design view?

I can't replicate any of what I understand you to be saying.

Indeed, I found that opening a form with acHidden even causes the
Activate event to fire (to my surprise).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Trevor Best]

David W. Fenton wrote:

I don't understand.

What does design view have to do with it?

I've noticed in a difference on mine (A2K2), opening from design mode
causes the form footer to disappear. No biggie, esp. fop clients as they
won't do that but a bit of a pain when debugging something and I want to
see something in the footer.

--
[OO=00=OO]

[MLH]

David, I swear, I hate to put stuff on this forum that
might mislead everyone, causing them to look into
something that I've misinterpreted as a problem -
But honest to God, this is really what is happening.

As you can probably deduce from a couple of earlier
posts, I was wanting to handle a couple of things
during the activate event and I seemed to have
some flaky events. So I started testing various
scenarios. The design view thing, as you suspected,
has nothing to do with the application. I just discovered
the anomoly during testing. Here IS what is happening...

I open a form this way...
ThisForm = Me.Name
DoCmd.OpenForm "frmVehicleChooserForm", , , , , acDialog, ThisForm
Notice the 6th parm is acDialog.

FACT: If that form is NOT open in any view, the Activate event does
NOT fire. If that form is ALREADY open in design view, its Activate
event DOES fire. For me, this has happened at least a dozen times
straight over the past 48 hours. It has NOT varied in its behavior. I
have noticed that the acDialog parm seems to affect this. Removing
it from the equation, Activate event seems to fire every time in all
cases.

[Tim Marshall]

MLH wrote:

I
have noticed that the acDialog parm seems to affect this. Removing
it from the equation, Activate event seems to fire every time in all
cases.

acDialog avoids the activate event. However, since you're opening from
design view, then the act of opening from design view will negate the
acdialog parameter. I found this to be the case in A97 and A2003.

What you have to do when developing a form that is opened with the
acDialog parameter is to first close it.

But then, if you don't want the on activate event to fire, why on earth
do you have anything there????
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[MLH]

The activate event is supposed to fire whether I want it to or not.
I want it to do that. Problem is exactly that - it is not firing when
I was hoping it would. I guess acDialog is to blame. That leaves
me no choice but to do away with the acDialog parm.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

acDialog avoids the activate event. However, since you're opening from
design view, then the act of opening from design view will negate the
acdialog parameter. I found this to be the case in A97 and A2003.

What you have to do when developing a form that is opened with the
acDialog parameter is to first close it.

But then, if you don't want the on activate event to fire, why on earth
do you have anything there????

[Bri]

MLH wrote:

The activate event is supposed to fire whether I want it to or not.
I want it to do that. Problem is exactly that - it is not firing when
I was hoping it would. I guess acDialog is to blame. That leaves
me no choice but to do away with the acDialog parm.

On Load?
On Open?

Would one of these events be the place for your code?

--
Bri

[Tim Marshall]

MLH wrote:

The activate event is supposed to fire whether I want it to or not.
I want it to do that. Problem is exactly that - it is not firing when
I was hoping it would. I guess acDialog is to blame. That leaves
me no choice but to do away with the acDialog parm.

Did you try setting the form to modal and pop up? I'm not 100% off the
top of my head if this will work or not, but I do know it will give the
same appearance as opening it in acdialog and will allow you to perform
code after the docmd.open rather than the rather complicated approach
you've suggested in another post.

--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me

[David W. Fenton]

MLH <CR**@NorthState.net> wrote in
news:um********************************@4ax.com:

David, I swear, I hate to put stuff on this forum that
might mislead everyone, causing them to look into
something that I've misinterpreted as a problem -
But honest to God, this is really what is happening.
I really do feel your pain! It's just that I couldn't reproduce your
problems.
As you can probably deduce from a couple of earlier
posts, I was wanting to handle a couple of things
during the activate event and I seemed to have
some flaky events. So I started testing various
scenarios. The design view thing, as you suspected,
has nothing to do with the application. I just discovered
the anomoly during testing. Here IS what is happening...

I open a form this way...
ThisForm = Me.Name
DoCmd.OpenForm "frmVehicleChooserForm", , , , , acDialog, ThisForm
Notice the 6th parm is acDialog.
Well, let me tell you -- I'm discovering some weird things, too. I'm
using A97, like you (if I'm remembering correctly).

I have an app that opens to heavyweight forms hidden when the main
switchboard screen opens. The if I put MsgBox "Activate" in the
OnActivate event of one of those forms, it first when the form is
open with acHidden, which actually surprises me.

The other surprise is that it activates for my Close button (which
sets Me.Visible = False).

Then, the other weird thing is when I then unhide the form (with the
switchboard, which is issueing a DoCmd.OpenForm), the Activate event
does *not* fire!

I tried moving the event to OnGotFocus, but the form itself doesn't
appear to be *getting* the focus, so it never fires!

Now, testing your scenario with acDialog, I see exactly the same
thing.
FACT: If that form is NOT open in any view, the Activate event
does NOT fire. If that form is ALREADY open in design view, its
Activate event DOES fire. For me, this has happened at least a
dozen times straight over the past 48 hours. It has NOT varied in
its behavior. I have noticed that the acDialog parm seems to
affect this. Removing it from the equation, Activate event seems
to fire every time in all cases.

Well, as I said in another message, I think you have a flaw in your
design. No, I can't explain why OnActivate is not working the way
I'd think it would, but you can easily re-engineer your form to make
it a non-issue.

Assuming that your dialog form's CLOSE button is setting Me.Visible
= False, and then code somewhere else is pulling values out of that
form's controls (or the global variables), at that point you ought
to be able to then re-initialize your global variables.

I don't like using global variables for passing information between
forms, myself. I would tend to use a class module an instance of
which I could destroy and recreate at will. I would also tend, then,
to make the opening of the form part of the class module, so that
the method of the class that opens the form would make sure the
class module was appropriately initialized.

There are other ways to avoid depending on OnActivate that I've
outlined in other replies. If you didn't see those, I'll let you
know the Google URLs for them.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Bri <no*@here.com> wrote in news:7O8Ee.12890$s54.11245@pd7tw2no:

MLH wrote:

The activate event is supposed to fire whether I want it to or
not. I want it to do that. Problem is exactly that - it is not
firing when I was hoping it would. I guess acDialog is to blame.
That leaves me no choice but to do away with the acDialog parm.

On Load?
On Open?

Would one of these events be the place for your code?

Geez, people -- read back in the thread.

He has a form and this form is sometimes open but hidden.

He wants the initialization code to run each time the form is opened
or made visible. So, OnLoad/OnOpen will work if the form isn't already
open, but it won't accomplish anything then the form is open and
hidden. The Activate event is the obvious place for it, but OnActivate
doesn't fire for form's opened as dialogs, so that won't work.

The only solution is to re-engineer the initialization so that it
doesn't happen in the dialog form's code.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc