form instances sharing actions

[NauticalGent]

As is usually the case whenever Galaxiom gets involved, I end up learning of an Access/VBA feature I have never heard of. In this case dictionaries.

So, I consulted the good Dr. Google and he led me to this article on Experts Exchange:

https://www.experts-exchange.com/articles/3391/Using-the-Dictionary-Class-in-VBA.html

What I really like about the article is that not only does it explain what they are and how they can be used, it also goes into great detail about how and when they would be a better option over Collections - kinda of what G was alluding to.

As is with most "tools" in my ever expanding tool-box, I will need to determine when is best to use this and try not to make it fit just because I want to. I fell into that trap with Class Modules...trying to kill mosquitoes with a bazooka.

At any rate, thanks for the education!

 

[jleach]

I've generally preferred dictionaries over collections for ease of use, but never liked that I had to late bind or include the scripting reference. A while back I found the drop in class (see post 19) that works very well, but these days it's rare I do a VBA project from scratch, so usually just utilize whatever's already in there.

If you plop in the dictionary class and get rid of the reference requirement, I'd say in most cases the dictionary is easier to use wherever you would typically use a collection.

Cheers,

 

[MarkK]

Like Galaxiom, I tend to feel that it's better to be able to explicitly have a reference.

Your feelings are totally fair here and I don't want to tread on those, but you don't have this explicit reference when you open a default instance. Why should you need it for your non-default instances when it doesn't exist for your default instances?

Wouldn't we all love to be freed from the oppression of DoCmd.OpenForm(), and be able to treat forms more like classes???

Mark

ps, How I discovered this was using a form/subform arrangement where the subform maintained a strongly typed variable reference to the mainform (in order to expose it as a strongly typed object in the subform's code) and I noticed that non-default instances did not wink out of existence when I destroyed their host collection/variables. Then it was just a short step to realize a form could support it's own reference to itself as the mechanism to keep itself alive, without external references, making it behave much more like a default instance.

 

[jleach]

I was going to say that it's because if I need multiple instances, I need to manage them externally, but it occurs to me that this may very well just be a byproduct of the way I manage them and don't actually need the external reference at all. Food for thought! (for me, I mean)

 

[isladogs]

Hi Colin, there's a lot going on in this thread, but do you see the little trick for keeping non-default instances of forms open in post #9? I think you might like that.
Mark

Yes I did see it & also thought it was a very clever bit of code that would never have occurred to me.
However, perhaps like Nautical Gent, I can't envisage a real world example where I would want or need to use it.
That was why I requested an example showing its use.
I would still welcome that if you can spare the time.

Maybe I'm misunderstanding the point of this thread by Jaxie, but I'm not sure it is applicable for that situation either. If I've got that wrong, my apologies.

 

[MarkK]

I can't envisage a real world example where I would want or need to use it.

Any situation where non-default instances make sense or are desirable. Say you write an accounting system and you want to be able to display an Invoice transaction and the Payment transaction on that invoice, both of which are separate rows in the same table, and both of which are most simply displayed by the same fTransaction form. In the usual scenario, if you want non-default instances like that you need a lot of overhead--a bunch of variables or a collection or dictionary--some code to create and add new instances to the infrastructure so they don't go out of scope, code to handle the removal of references if the user closes a form, and so on--non trivial.

But with this code on a fTransaction form...

Private m_frm As Form_fTransaction

Private Sub Form_Open(Cancel As Integer)
   Set m_frm = Me [COLOR="Green"] 'This variable assignment keeps this non-default instance alive.[/COLOR]
End Sub

Sub GoToID(TransactionID As Long)
   With Me.RecordsetClone
      .FindFirst "TransactionID = " & TransactionID
      If Not .NoMatch Then Me.Bookmark = .Bookmark
   End With
End Sub

... and a Show() method like this, you can open as many non-default fTransaction instances as you need...

Sub ShowTransaction(TransactionID As Long)
   With New Form_fTransaction
      .GoToID TransactionID
      .Visible = True
   End With
End Sub

That's it. Non-default instances that stay open without any external infrastructure, and possibly simpler to create than default instances.
Makes sense?
Mark

 

[NauticalGent]

Nicely done MarkK.

 

[Galaxiom]

but you don't have this explicit reference when you open a default instance. Why should you need it for your non-default instances when it doesn't exist for your default instances?.

An explicit reference exist for the default instance via the Forms Collection. This object can be assigned to a variable if desired.

Loading non-default instances also adds them to the Forms Collection but without a variable with outside its own scope, the instances are not easily distinguishable from each other. You have to resort to iterating through their Hwnd properties of items in the Forms Collection.

Even then there is no clear relationship between the Hwnd and process that opened the instance. The relationship between the instance and the Hwnd has to be managed if the instances need to be identified, which is largely why a Collection or Dictionary is often used.

 

[MarkK]

An explicit reference exist for the default instance via the Forms Collection. This object can be assigned to a variable if desired.

Loading non-default instances also adds them to the Forms Collection but without a variable with outside its own scope, the instances are not easily distinguishable from each other. You have to resort to iterating through their Hwnd properties of items in the Forms Collection.

Even then there is no clear relationship between the Hwnd and process that opened the instance. The relationship between the instance and the Hwnd has to be managed if the instances need to be identified, which is largely why a Collection or Dictionary is often used.

But are these facts impediments to the functionality as described? If so, how? Except to open them, I never manage forms from the outside. I manage forms using UI elements on the form, and in that case identifying the form is trivial, and so the problem you describe never arises.
Mark

 

[Galaxiom]

But are these facts impediments to the functionality as described? If so, how? Except to open them, I never manage forms from the outside. I manage forms using UI elements on the form, and in that case identifying the form is trivial, and so the problem you describe never arises.

Sure, I acknowledged earlier that a need to refer to the instance from the outside is probably quite rare.

My comment was just in response to your suggestion that a default instance would not have an explicit reference.