Need help! Event Order

[Lee]

Can someone tell me what I can do to work around this
problem? I have a tab control hosting multiple subforms.
I'm trying to do validation on the sub forms control's
_Exit events. In one subform, when clicking on a new tab,
the tab change event fires the control's _exit event. In
all the other subforms the control's _exit event fires
before the tab change event. I've been pulling my hair
out for almost 2 days trying to get this to work so that I
can validate this one form. I've tried the
Before/After_Update events on the same controls that are
giving me problems but the Tab_Change event always fires
first fot this one subform. There must be something that
controls the event firing order. Please help me if you
can!

 

[Rick Brandt]

Can someone tell me what I can do to work around this
problem? I have a tab control hosting multiple subforms.
I'm trying to do validation on the sub forms control's
_Exit events. In one subform, when clicking on a new tab,
the tab change event fires the control's _exit event. In
all the other subforms the control's _exit event fires
before the tab change event.

From the Access Help file....

· The Exit event occurs just before a control loses the focus to another control on
the *same* form.

Unlike the GotFocus and LostFocus events, the Enter and Exit events don't occur when
a form receives or loses the focus.

I have never seen a proper validation strategy that used the Exit event. Can you
explain why you cannot use the BeforeUpdate event of the form?

 

[Lee]

Rick,
Thanks for helping...
I can use the BeforeUpdate event instead of the Exit event
but I have the same problem in that the Tab_Change event
occurs before any of the control's events on this
particular tab/subform which prevents the validation for
required field(s) before the user moves to another tab.

 

[Lee]

Rick,
That's what I get on all the other subforms except for
this one. Yes this Tab has a subform. In this subform's
code is where I'm debugging the sequence of events that
are occuring. However, I do think it has something to do
with the implementation of that particular subform. This
is a new Tab/Subform that I've added to the application.
I added this because the users whated to split out some of
the data (a logical group of a subset of data) from the
main form. It's linked to the same table as the main
form. I basically just added the Tab/SubForm and moved
the specific controls to the new subform. BTW - This is
an upsized (to SQLServer) application that I'm working
on. I did this a couple of weeks ago. I would appreciate
any additional help or sugestions you could provide
because I am stuck here.

-----Original Message-----
Rick,
Thanks for helping...
I can use the BeforeUpdate event instead of the Exit event
but I have the same problem in that the Tab_Change event
occurs before any of the control's events on this
particular tab/subform which prevents the validation for
required field(s) before the user moves to another tab.

I placed temporary MsgBox() functions in a form I have that is set up similarly. A
main form with a TabControl with one page of the

TabControl having a subform. I

 

[Lee]

Yes, I created a new form, copying the controls from the
main form to the new form and the I dragged the form onto
the new page of the new Tab.
Is there another way?

-----Original Message-----


I'm not clear on this part.

You added an additional TabPage to the existing

TabControl, then you added a subform

 

[Rick Brandt]

Yes, I created a new form, copying the controls from the
main form to the new form and the I dragged the form onto
the new page of the new Tab.
Is there another way?

No, that sound right. I have always had trouble trying to do that anyway. When two
different forms are attempting to edit the same record, it usually causes errors.
I'm surprised you haven't been encountering those. Access will usually treat this
the same as two completely different users editing the record at once.

If you just wanted to organize the controls on the form you didn't really need to use
a subform. Why not just move the parent controls onto the Tab Page?

 

[Lee]

The user's wanted it moved to a new tab for consistency.
They are already using tabs for "grouping" controls. Most
of the tabs are one-to-many, however there are a couple of
one-to-one relationships. This new subform is the only
one that is using the same table as the main form. I am
getting crashes though. Do you think it's because it's
using the same table?

 

[Lee]

Do you mean just add a new tab and move the controls onto
the tab page without a form? Will the code-behind still
be in the main form?

Could you tell me the steps to add a Tab & an empty page?

Thanks!

 

[Lee]

Rick, I think I understand what you're saying about just
adding a new tab and move the controls directly onto
the tab page without a form? Will the code-behind from
the main form still work with these controls?

Whenever I add a new tab to the Tab control, all the
controls that are on the main form shows on the new tab as
well. How do I get rid of these on the new tab only so
that I can add the new controls? It seems if I add a tab
control page, this is not a container for controls and
only allows me to specify a subform. This is confusing.

Thanks!

-----Original Message-----


Could be, but as I stated in last post you could have

moved the controls to a TabPage

 

[Lee]

Rick, thanks for all your help!

-----Original Message-----

Do you mean just add a new tab and move the controls onto
the tab page without a form? Will the code-behind still
be in the main form?

Could you tell me the steps to add a Tab & an empty

page?

It is easier if the TabControl is added at the beginning because only new
controls can be dragged n' dropped onto Tab Pages. For existing controls you
need to cut them to the clipboard, select the desired TabPage, and then paste.
Controls that are cut n' pasted in this manner will lose their "[Event
Procedure]" properties. The code will still be there in the module. You just
need to restore the "[Event Procedure]" setting in the property box.


.