Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Inconsistent Destroy behaviour.
Message
De
21/09/1999 17:15:39
Mark Hall
Independent Developer & Voip Specialist
Keston, Kent, Royaume Uni
 
 
À
21/09/1999 14:16:52
Information générale
Forum:
Visual FoxPro
Catégorie:
Programmation Orientée Object
Divers
Thread ID:
00265929
Message ID:
00267346
Vues:
19
>>>>The problem for me is that I need to be able to take action if THIS objet is the last child belonging to its immediate parent. The ambiguity mentioned in (2) above makes that impossible. Because of (1) above, I cannot even implement a manually coded alternative.
>>>>I could take some action in the parent, when it's last child is removed, but there is no event that always fires at the parent when one of its children is removed. RemoveObject doesn't fire in the second case in (2) above.
>>>>
>>>Hi, Mark
>>> If you are using VFP6 you might want to try Access/Assign on the parent object's ControlCount property.
>>> I am also curious(I read Eric Moore's message) as to what you are trying to do.
>>> Let me know how it works.
>>>
>>>Ned
>>
>>Hello Edwin and Erik,
>>
>>Edwin, the Assign idea looked promising, but...
>>
>>Quote from the manual
>>"You can create an Assign method for a native Visual FoxPro property that is read-only (for example, the ParentClass property), but the method will never be executed."
>>
>>What am I trying to do? I'm re-writing my Menu classes (see files section) to correct a bug introduced by this new (to VFP 6) Destroy behaviour.
>>
>>If the user decides to remove an item from the menu e.g.
>>_SCREEN.Menu.Tools.RemoveObject("Options")
>>
>>a number of flags/counters must be adjusted and these in turn will mean changes to the 'real world' state of the displayed menu.
>>
>>As the object structure models the physical menu structure it is tricky to operate the PAD/POPUP/BAR mechanism without quite a lot of parent/child communication.
>>
>>Any suggestions?
>
>How about giving the user a RemovePad() method to use, instead of RemoveObject. This way, you have control over what happens.

Actually, the problem isn't with the RemoveObject method, it's when objects are automagically released due to an object in their parent hierarchy being RemoveObject-ed. Aha!!, as I write this I have had a 'lightbulb' moment.

When the user uses RemoveObject, maybe I can run code to traverse all of it's child objects, removing them one-by-one, rather than relying on the automatic release process.

As the tag line of an ad campaign here in the UK goes -- "It's good to talk"
Regards
Mark

Microsoft VFP MCP
Menulib - OO Menus for VFP www.hidb.com/menulib
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform