Why would Access 2010 not trigger the form unload event when browseto is invoked from subform, instead of parent form?

2
votes

As stated, this is an Access 2010 .accdb.

I have a main, navigation form: frmNav.

On frmNav I have a Navigation subform control: NavigationSubForm.

I use docmd browseto to move between tabs on the navigation control.

The first form to load in the NavigationSubForm control is frmInboundShipments.

frmInboundShipments contains a sub form control sfrmListInvoicesByShipment.

sfrmListInvoicesByShipment consists of a filtered datasheet of invoices associated with each shipment in frmInboundShipments.

frmItemInvoices contains the invoices referenced in sfrmListInvoicesByShipment.

The following methods of moving between frmInboundShipments and frmItemInvoices using the browseto command do trigger the UnLoad event on frmInboundShipments:

  1. Click command button on frmInboundShipments to invoke browseto to frmItemInvoices
  2. Click the navigation tab/button on the navigation control on frmNav to invoke browseto frmItemInvoices.

However, when I perform the following action(s), the UnLoad event on frmInboundShipments fails to trigger:

  1. Double click on a field/datasheet row in sfrmListInvoicesByShipment to trigger the browseto command to show/move to frmItemInvoices by either:

    a. Immediately executing docmd browseto to show frmItemInvoices

    b. Set focus first on the parent form, then execute docmd browseto to show frmItemInvoices

     i. e.g.: Me.Parent.sfrmListInvoicesByShipments.SetFocus

          DoCmd.BrowseTo acBrowseToForm, "frmItemInvoices", "frmNav.NavigationSubform", ...criteria....

I can't understand for the life of me why the event doesn't trigger when the browseto command is issued from the subform, but is triggered in every other scenario when navigating between the two forms.

I've looked at the Access 2010 order of events and I don't see anything that explicitly states that the Unload event of the main form would not fire when moving to view another form from the subform.

The Deactivate event also does not fire in this circumstance.

Update, 10/18/13: further investigation reveals that the parent form's Close event does fire, but definitely not the deactivate nor unload events. Problem is that the value I want to capture is already gone once the form Close event occurs. Not sure what to do from here...

1
ms-accessnavigationvbams-access-2010
I won't close this just yet, but I did find a work-around: instead of capturing the value in the unload event of the parent form when the browseto is invoked from the subform, I decided to move the data capture to the Enter event for the subform control. The end result may be that it gets written more often, when the user tabs through the subform control or goes to search for a value in that form, etc. In the end, it accomplishes the goal. I'd still really like to know why unload never fires. The MS documentation on order of events for subforms, at least in this case, is really inadequate. – rudelerius
I found that in Access in order for a Form to be Disposed, it needs to be Closed and then Disposed. VBA will not allow for an Open (visible or not) Form to be Disposed, in my previous uses. Unfortunately you will have to be granular when it comes to VBA, if you dont tell it to do it, it will not imply it. – GoldBishop
Have you tried triggering the BrowseTo command from the parent form rather than the subform? If there's (as I assume) a variable that's important on the subform, you could pass it to a public string and use that string when triggering the code? – Sinister Beard

1 Answers

0
votes

rudelerius,

I feel your pain. I have had long experience debugging Access Form events, and have come away with several rules:

  1. Form events don't always fire when you expect them to.
  2. Form events do not always fire in a particular order, despite what the documentation may say.
  3. Finally, debugging by putting a Breakpoint in an event procedure can change the order or number of events that get fired.

So what can you do? My recommendations:

  1. Form events are for handling Form-level actions. They are just plumbing, and you should not overload them with Application-level functions
  2. Separate your Application or Business logic from your forms, and especially do not plug Business logic into any Form or Report Event. In other words, the code that supports what your application does should be separate from how it does it.
  3. For debugging, use things like Debug.Print in the event procedure, and avoid Breakpoints.

So, how does this help you? My (necessarily broad) answer is put whatever information you want to preserve in an external module-level variable, or class, before you take your form action. Your main form can then use that information without relying on the state of the child.