Knowing who called a form event, how?

[mdlueck]

Greetings,

I am needing to develop a subform version of a form that is already in my application.

That form calls an AddRecord / EditRecord form itself.

When those forms Commit an update, they call back to the parent form, firing a re-query event and passing the event the ID of the record which was added/updated.

That all works fine and dandy, until...

Now I am developing this clone of that records list form, to be used in a subform context on another main form. It will be known via a different name this time to receive the callback upon successful commit of the INSERT/UPDATE.

I am thinking to make this record list / add+edit dialog handshake unique in that the list form will pass some sort of token to the add/edit dialog in order that it know who called it, thus know who to send the requery event to when it has successfully committed.

Is that sort of information (which form opened another form) available automatically? Or do I need to pass it along myself when the child form is opened?

 

[spikepl]

My suggestion to you is don't go there. Right now it seems like a brilliant idea, enabling you to reuse some component in different contexts. When you come back to this 12 or 24 months from now, to do some extensions, the brilliant logic of today will be less evident, and you'll spend ages figuring out what is going on, because Access was not born this way.

The KISS principle is king, when mainenance is involved. In this respect Access is pretty "good", because it's fairly limited in what you can do. The price for this is a lot of instances of code or objects that do almost the same, but the benefit is simplicity. If you wish to enforce structures inherited conceptually from more complex languages, you can do that too, at the price of sacrificing KISS: your code will not be maintainable by anyone else less qualified than you.

 

[mdlueck]

My suggestion to you is don't go there. Right now it seems like a brilliant idea, enabling you to reuse some component in different contexts. When you come back to this 12 or 24 months from now, to do some extensions, the brilliant logic of today will be less evident, and you'll spend ages figuring out what is going on, because Access was not born this way.

Just trying to prevent having to configure something two places rather than simply one place.

Already in the call back I need to introduce a select based on which form to send the requery event to.

I was trying to prevent having to custom pass in an identifier token to have that call back select be based on.

 

[mdlueck]

Since I was not using anywhere in this application the OpenArgs of Forms, I am using that to pass the name of the parent / calling form. Example:

DoCmd.OpenForm strDocName[B][COLOR=Blue], , , , , , Me.Name[/COLOR][/B]

Then when I need to call the event of the caller form...

    'Hack to refresh the prior window UI
    'Needed since this form was opened via its class and the
    'Forms Collection does not have the form name set as the key
    For Each frm In Forms
      If frm.Name = [COLOR=Blue][B]Me.OpenArgs[/B][/COLOR] Then
        Call frm.Refresh_Click(ObjMEToolingTbl.id)
        Exit For
      End If
    Next frm

Woo hoo! No need for customized switch logic on a per-form basis due to standardized naming of Events.

 

[Rank Am]

I generally try and avoid openargs although it is OK for the use you mentioned but as said before it gets pretty difficult to trace what's going on. I generally find the neatest way to add such functionality is to use VBA class modules. Instead of using DoCmd.opemform you instance a custom class and use this to open the form . All of the code is kept in one place and you an add as many properties and methods as you want, such as 'Parent' (the opening form), it's more complicated at the design stage but much easier to debug and maintain in the long run

 

[mdlueck]

Instead of using DoCmd.opemform you instance a custom class and use this to open the form.

I found out about such a little late to fully implement for this application. I learned such when the topic of inter-form messaging came up. So for this time forms which need inter-form communication I open via class, and all the rest I open the legacy way.