I see now what you're referring to. This is by design :-). The reason is this: Assign events are not and cannot be recursive. This is sensible because a cannonical assign method is as follows:

  FUNCTION x_Assign( tz)
    * code
    This.x= tz
    RETURN

We certainly don't want an assignment to trigger itself since that would blow the stack. So it's sensible for VFP to completely throttle subsequent assign events for the scope of that root assign event.

This is doubly sensible considering the case where A calls B calls C which, for all we know, can call A again, and around we'd go.

So the root cause of the problem is the assign event sets values in objects eminating of the same class. To get around this, consider sending a message to a method of the Cascader class, or any other mediator object, and have that set the properties of the siblings of the cObj class.

This is sensible considering this heuristic: Objects that share lexical scope should not have UsesRelationships between them. which is from http://fox.wikis.com/wc.dll?Wiki~RelationshipHeuristics

**--** Steve



>Sorry for the position of the response but it seemed proctical to place the response after the entire message for the sake of those who have not had the opportunity to read the preceeding messages.
>
>Regarding dynamic events, I do believe that the code which I submitted demonstrated a dynamic event. Please notice that the assignment fault I am referring to is not one which occurs during object creation but as a result of an independent assignment.
>

>local lo
>clear
>lo= createobject('cascader')
>lo.changex()  && The bug is evident after this invocation
>lo.showx()
>lo = ''
>

>
>Clip the code and test it. It is an unfortunate aberration of oo.
>
>Thanks
>
>Glenn
>
>>Glen, please do not respond 10-screens down. It's aggravating to search for replies.
>>
>>>> I understand the static property value assignment as you illustrated, but I do not unerstand nor appreciate the dynamic event processing as per my illustration.
>>
>>These are not static property value assignments. In OO, "static" has a precise meaning and this is not what we're seeing here. Also, there is no "dynamic event processing" in any of these examples. Again, in oo, the term "event" has a precise meaning and this is not what we are seeing here.
>>
>>>> Each object must have a unique entity in memory so that each may support independent data and behaviors, therefore each unique identity must fire its events in its own space and time.
>>
>>This is exactly what is happening. Each object occupies distinct memory space. What is not in disctinct spaces is the class definition, which is invariant and is stored in memory exactly once. This is why you get exactly one Assign event. This is entirely sensible. Once your object is instanced, it is thereafter free and distinct from other instances, and the properties are free and distinct from one instance to the next, as you migt expect.
>>
>>>> This may be by "design" but I believe the design is flawed, aka "bug".
>>
>>As I explained, this is not a bug, it is by design. You may not like it, but this will definitely never change. If you need to fire this Assign event for every instance creation, you must code it in the Init event.
>>
>>**--** Steve