I have a subclass of Listbox, and some instances of that (all are hierarchical). All these Listboxes should show the same content. One of the Listboxes has some Drag/Drop stuff which may alter the row ordering, or perhaps the entity a row represents is deleted, a new one made, or an existing one renamed. In all these cases I want the other Listboxes to be refreshed to reflect the new state. At the minute I would do that for each listbox by calling a method, for each listbox, which regenerates the top row of the hierarchy in that listbox, after which the ExpandRow event does the rest of the work.
However reading RaiseEvent made me wonder if I could generalise that a bit. My reading was that I could create a new event in the subclass, then a method to raise it, and that this would raise the event in all instances, which could then do their own refreshing. But it seems I can only call a class method from an instance, according to the compiler. Am I missing something here about RaiseEvent? If I can’t do it as I had supposed, then I can’t see any benefit in using RaiseEvent over my previous more procedural approach.
RaiseEvent will work only on a given instance, but you can still leverage it.
Add a shared property like an array or Dictionary to hold instances of your Listbox. In the ListBox Constructor, store a WeakRef in that property. When content changes, call a Shared Method that will cycle through the WeakRefs, remove the ones whose value is Nil, and raise the appropriate event on the rest.
have a look at inspiring Observer Pattern Example.
in your case you need a list of instances/objects as Kem said then you can notify them.
xojo allow only register a event once.
a event is more or less a method call with optional parameter input and data return.
Yes, that seems to work nicely, with the only difference from what I originally envisaged being that I have to get the event raised for each instance individually. As the instances are in the layout and not constructed at runtime, I just do the registration in the Open event.
Hmmm, can’t instances on the layout have a constructor?
Interesting example. Do these Class Interfaces do anything other than enforce that a class implements a set of methods? Doesn’t the compiler do that? I found I could remove both of the Class Interfaces, then with mionor fixups the example ran as before.