Versions des environnements
>
It's quite nice, as you can work with bindevent etc. within the inner control structure. And it's still all encapsulated.
>
That's the key for me right there. Since BindEvent() requires its participants to have public visibility, I was worried that objects _within_ the control wouldn't be able to communicate with each other.
But what if some of those objects are conrols themselves? For example, my EXPANDER control encapsulates, at minimum, a TITLE_BAR, a COLUMN_HEADER_BAR, a CONTENT_REGION, and a FOOTER. If the minimize box in TITLE_BAR raises an event, will EXPANDER be able to bind to it? Right now, all of those objects are CONTAINERs and everything works fine. Last night I tried the event management scheme that I had laid out to Viv, and it works like a charm! Each EXPANDER instantiates its own public EventManager upon init. Events are raised and bound in this EventManager instead of directly to each class. This allows me to control the visibility of contained objects without sacrificing event processing. I suppose I could do the same thing with Controls...
>
But there is one little bug with this pseudo protection: SETALL() will not respect this boundary. So if you put some class based on control that has several labels in it on a form and isse THISFORM.SETALL("fontbold",.t.) also the labels within your protected control will get bold. although you couldn't do THISFORM.mycontrol1.label1.fontbold = .T.
>
Since use of a free function like SETALL() would violate encapsulation, at least to me, I probably wouldn't use it anyway. I would most likely take the performance hit and implement some iteration scheme for recursively setting the font.
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement