Classes and Events with a SplitForm or DataSheet (2 Viewers)

[AccessAllstars]

I have attached a database which contains a sample the issue I have.

I am implementing a clsForm so I don't have to paste the same code in over and over again. My class works perfectly when the form is a Standard form or Continuous form --> All events fire in the class!!! YEA (Thank you JOHN COLBY!)

The issue is when the forms’ default view is Split Form or Datasheet the FORMS Class Module events for forms update/insert/delete events don’t fire a.

What I have in the example DB

1. I created a form frm_OrderStatus_Continuousas a continuous form --> All Events Fire
   1. Open the form change the ModifiedBy name to another name
   2. Before and After Insert and Update events fire for the CONTROL and the FORM
2. I copied the form frm_OrderStatus_Continuous and saved it as frm_OrderStatus_SplitForm
   1. Changed the following properties on the FORM
      1. Default View = Split Form
      2. Split Form Orientation = Datasheet on the bottom
      3. Split Form Splitter Bar = NO
   2. Open the form change the ModifiedBy name to another name
      1. Before and After Insert and Update events don’t fire for the CONTROL or the FORM

Any help will be greatly appreciated!
Thank you in advance,
Kim
POST COMMENTS: I have replaced the original attachment with a new version which contains the solution ( @AHeyne AND John Colby) along with documentation so that others can learn from/walk thru this.

 

[MarkK]

I haven't looked at your database, but in order for an event to fire, its 'On<Event>' property needs to be set to "[Event Procedure]," so if you want to handle the Current event for Form1 in clsA, you need to either...
1) set the OnCurrent property of Form1 to "[Event Procedure]" in design view, or ...
2) clsA has to set it programmatically. So if Form1 in clsA is assigned to a local WithEvents variable m_frm, clsA needs to do...

m_frm.OnCurrent = "[Event Procedure]"

Then your m_frm WithEvents variable will raise the Current event.

 

[isladogs]

You hadn't actually added code to several of the events you referred to so you wouldn't know whether they fired or not

Using the split form on your example db, the Form BeforeInsert event does fire. as do the Form Before/After update events. Similarly control before/after update events do fire

Split form controls do not have before/after insert events in the property sheet and attempting to program them isn't recognised as event code

 

[AccessAllstars]

The events are set

I haven't looked at your database, but in order for an event to fire, its 'On<Event>' property needs to be set to "[Event Procedure]," so if you want to handle the Current event for Form1 in clsA, you need to either...
1) set the OnCurrent property of Form1 to "[Event Procedure]" in design view, or ...
2) clsA has to set it programmatically. So if Form1 in clsA is assigned to a local WithEvents variable m_frm, clsA needs to do...

m_frm.OnCurrent = "[Event Procedure]"

Then your m_frm WithEvents variable will raise the Current event.

The code does do that in the clsForm. The code is identical for each of the two forms. It works for the continuous form and the class events fire. It does not work for the split form.

 

[AccessAllstars]

You hadn't actually added code to several of the events you referred to so you wouldn't know whether they fired or not

Using the split form on your example db, the Form BeforeInsert event does fire. as do the Form Before/After update events. Similarly control before/after update events do fire

Split form controls do not have before/after insert events in the property sheet and attempting to program them isn't recognised as event code

View attachment 108990

I know the events fire because the message box appears. The clsForm events m_Form_AfterUpdate() and m_Form_BeforeUpdate are NOT firing in the split form. They do fire when the form is a continuous form.

 

[isladogs]

I tested them by adding message boxes to the events where you had no code.
My previous post reported back on what fired in my tests on the split form

 

[jdraw]

I looked at your database. Using OrderStatusSplitForm, I added a new record, the event messages were displayed.
Don't know if it helps.
I also noticed that there were "Event Procedure"s on the Form Property sheet.

 

[AccessAllstars]

I looked at your database. Using OrderStatusSplitForm, I added a new record, the event messages were displayed.
Don't know if it helps.
I also noticed that there were "Event Procedure"s on the Form Property sheet.

View attachment 108991

jdraw -

I should have said in the original post that the events in the FORM fire - but the events in the CLASS module do not. My bad! Sorry for that.

The events that are NOT firing for me are on the split form are in the CLASS Module: clsForm

clsForm. m_Form_AfterUpdate, clsForm.m_Form_BeforeUpdate, clsForm.m_Form_BeforeInsert

Can you please change the name in the AddedBy column and do you get these msgboxes?
"m_Form_AfterUpdate: " & m_Form.Name
"m_Form_BeforeUpdate: " & m_Form.Name

Thanks! Kim

 

[AccessAllstars]

I tested them by adding message boxes to the events where you had no code.
My previous post reported back on what fired in my tests on the split form

I should have said in the original post the Class events for the Form are not firing
See my comment to jdraw -

 

[jdraw]

Kim,

I changed the record I added---changed the AddedBy to SomeoneElse.
Here are the screen captures showing the msgboxes.






Also note there is no code in the AddedBy_BeforeUpdate


The messages are at the Form level, not the individual control

 

[AccessAllstars]

Kim,

I changed the record I added---changed the AddedBy to SomeoneElse.
Here are the screen captures showing the msgboxes.

View attachment 108995


View attachment 108996

Also note there is no code in the AddedBy_BeforeUpdate
View attachment 108997

The messages are at the Form level, not the individual control
View attachment 108998

Thanks Jack - you have confirmed what I found; the clsForm events are NOT firing for the Form_BeforeUpdate and Form_AfterUpdate on the split form. Those do fire when it is a continuous form.

 

[jdraw]

I added a msgBox to the AddedBy control's BeforeUpdate event.

and changed the AddedBy to AnotherPerson and got the msgbox


I'm not sure how you would put the event procedure into the class--if that is what you are trying to do.
(I think this little poser is one for JC to resolve)

I looked again at clsForm and see this

'Form Events
'~~~~~~~~~

Private Sub m_Form_AfterUpdate()
'The VB editor will  remove unused but valid event sinks for us.
'Since we placed no code/comments in that event sink, it is UNUSED and removed by the editor when we compile the code
    MsgBox "m_Form_AfterUpdate: " & m_Form.Name
End Sub

What is it really saying??? An empty event will be removed by the editor on compile??
You figure that the MsgBox "m_Form_AfterUpdate: " & m_Form.Name in clsForm events should have displayed, correct?
May be something specific to Splitform???

 

[AccessAllstars]

I added a msgBox to the AddedBy control's BeforeUpdate event. View attachment 108999

and changed the AddedBy to AnotherPerson and got the msgbox
View attachment 109000

I'm not sure how you would put the event procedure into the class--if that is what you are trying to do.
(I think this little poser is one for JC to resolve)

I looked again at clsForm and see this

'Form Events
'~~~~~~~~~

Private Sub m_Form_AfterUpdate()
'The VB editor will  remove unused but valid event sinks for us.
'Since we placed no code/comments in that event sink, it is UNUSED and removed by the editor when we compile the code
    MsgBox "m_Form_AfterUpdate: " & m_Form.Name
End Sub

What is it really saying??? An empty event will be removed by the editor on compile??
You figure that the MsgBox "m_Form_AfterUpdate: " & m_Form.Name in clsForm events should have displayed, correct?
May be something specific to Splitform???

1) Yep! If m_Form_Update you remove the comments and the MessageBox and then compile, Private Sub m_Form_AfterUpdate() will disappear. I just learned that!

2)Yes I expected the MsgBox "m_Form_AfterUpdate: " & m_Form.Name in clsForm events to display - it does display when it is a continuous form

3) Yes - I suspect it is a bug/issue with the split form and/or datasheet

 

[MajP]

A lot of people here do not bother with split forms. More pain then worth. Not sure why @isladogs did not mention but this is IMO a lot more controllable and tailorable.

Emulating the split form

Like many users of this forum, I abandoned split forms a long time ago as I found them difficult to adapt if you want to modify them in any way In a recent thread another user wanted to keep the idea but to emulate it using a single form with a continuous subform. See this thread...

www.access-programmers.co.uk

 

[isladogs]

Kim (@AccessAllstars) is a member of the team who created the Northwind 2.0 template databases.
She is currently working on an update to those templates and is, I believe, limited to built in Access tools.

It was for that reason that I didn't mention either the Emulated Split form or its sister article Build Your Own Simulated Split form

 

[jdraw]

MajP,
I agree. My hope was that you could look at the class and event aspects, regardless of split form per se, and see if there was something preventing an event to fire, or was it some issue/bug, or was it a small change to code that was required to make it work as expected.

I had mentioned that split form was not well-accepted generally and Colin had a simulated split form article. However, I think the current issue of class and events may be important on its own. It isn't the split form itself, but the class and events that may show yer another issue/problem/opportunity with split form.

 

[AccessAllstars]

Everyone - thank you for the suggestions on split form alternatives! I use them to present dashboards to senior management. They like them because they feel more like excel to them, showing and hiding columns, moving columns etc.

Colin(@isladogs) this is not for NW2 - its for a client. But thanks for reminding everyone, we cant put stuff in NW2 that the team did not create

As Jack stated - I was hoping to understand the issue between the SplitForm and the class.

 

[isladogs]

Hi Kim
In that case, as its not for NW2, I'd definitely use one of the alternatives discussed in my two articles which have all the benefits of split forms but without the disadvantages

 

[AccessAllstars]

Based on the comments - I tried the class with same form, setting the Default View to Datasheet. All the events in the class work - which I didn't think it would!

Colin( @isladogs ) I can solve the design issue in my app easily enough. I just need a form with a header and then a datasheet for the sub form.

I would however like to understand why 3 out of the 4 Default Views worked and only the SplitForm did not.

Again - thank you everyone for all the input!

Kim

 

[jdraw]

Kim,
I think you have confirmed that it is an issue associated with SplitForm and not your coding of class and events.
Perhaps time to have M$oft have a look.
Could be a bug/oversight or a purposeful design/implementation "feature"?