I have created a custom class which I use in form of window properties. On this class, different controls can register to receive and send notifications via an interface that connects them. Currently, I am using the window open event to initialize this custom class and then register the controls on it.
But registering sucks and it’s easy to forget to register a newly added control. So I thought about an auto-register method in the constructor of my class.
If only one of the properties would be used in a window layout, this would work: I could scan the window for its controls and register existing controls by checking their isA value if they belong to one of the control subclasses that carry the interface, I can register them.
But in theory several of the base class properties can be used in a window layout, and only some of the controls on a layout could belong to one of this instances, so I need some way to match control and class instance. I considered an inspector property on the controls. I cannot expose a property of a custom class type in inspector, that’s why I thought about using the class instance’s inspector name. But the name on a desktop project is only available for the layout. Object as the base class of classes without subclass carries no properties. A Webobject does, so I think this implementation A class instance constructor makes the instance scan the layout for available controls, and if their inspector “MatchClassInstance” property matches the class instance’s name, it registers them would work on a web project by using “webobject.name” but not on a desktop project.
Do you have any ideas on how a match could be created using inspector properties?
Perhaps you could in the open event of a window, do a for X=0 to window.controlcount-1 loop, call a method in each of the window.control(x) control that lets it self-register to an array property of the window and then use this list to initialize your class, or run a method in each control toregister in the class, using some unique identifier (a custom property that holds the control name?). Or some similar concept using the window.control() property.
hum… this sounds too simple. Surely you thought of it already…
a constructor is way too early since nothing else may be set up on the layout
the open event may be too early for the same reason - not all controls may be present yet
to “automatically” register them you’d need this to happen as part of the windows open event but then you have to write some code to say “scan for controls that implement this interface” (which amounts to an IsA check)
but you could get away with one line of code in the window open event
Thanks, you two. Yes, Louis, what you propose is what I have been trying. But the problem is the custom class instance doesn’t know about its name. I could change this by tying it to some RectControl they know their name , but that feels a bit like cheating. There’s no need to keep them attached to a window via a Control.
And Norman: Yes, basically that’s what I am doing, triggering the registration from a call in the window open event. But I cannot match the controls to selected class instances I want to choose via Instance properties. I have the feeling my idea won’t work unless a Desktop Object returns its name.
Not sure I’d have multiple notifiers on one window
If you have several then a single control trying to listen for ALL messages HAS to register with every notifier - there’s no other option.
If one notifier on a window handles & forwards all messages then registering with one would potentially give you access to all messages.
But there could easily be a way to say “only notify me about THESE messages” - basically a “subject”
And then its also possible I misunderstand your goal
Here is a brainstorm idea. The window is assigned a property with a default value at design time that the class instance reads early on, say in the constructor or anywhere else before controls are going to try to register with it. The class reads the property and copies the value to its own property, say myInstanceName. Each instance in each window would have a unique identifying property / name, derived from the window and possible to asociate with the class and with the window.
Controls can read the window property and register with the class instance that corresponds.
Thanks again, and yes, Norman, you got me right. I felt the problem wasn’t easy to explain but succeeded
Not so much with the solution, because basically it really looks like this solution wouldn’t work on a desktop project. And I believe in many cases there would be only one object to register to but one never knows what a developer could come up with. Thanks a lot for your assistance too, Louis! Yes, maybe this could work, but I have the feeling it would increase the complexity, not really lower it. I would still have to install a way to match instance and controls, and when the class reads the instance and assigns a unique value to itself I wouldn’t know in advance which instance will receive which value.
Anyway, you helped me understand this solution doesn’t work indeed. I’ll meditate about another approach. Thanks a lot!
I wrote a class some time ago that basically was “springs & struts”
It had two string properties for the controls that it joined together + several others for the min distance + max distance and whether the distance was fixed, flexible etc
So it did some of what autolayout would do
All I used was a string with the name of the instances that it related and at run time it could then iterate over the controls & find them by the name of the instance since you can get at the Instance’ Name property (see http://documentation.xojo.com/index.php/Control)
