>Chapter 3 from Nightmare on VFP Street?
>

It's just an attempt to get the code to stay alive during the removal; since things are Destroyed inside out, the child button has to be released before the parent container, so where does VFP pass control when the RemoveObject is done if the context is no longer valid...

>>
>>I'd try to avoid the headache here by having something outside the containership (a hidden control maybe) do the dirty work, and send control and focus to it, so that I'm not trying to kill something that contains my current code context. Maybe something like the following:
>>
>>(1) Create a form property oThingToKill. At Init() set it NULL
>>(2) Create a control subclass based on a class with a WHEN (TextBox is OK); does not matter which. In the When of the control:
>>
>>

IF VARTYPE(thisform.oThingToKill) = 'O' AND ! ISNULL(thisform.oThingToKill)
>>   LOCAL oParentOfCondemned
>>   oParentOfCondemned = thisform.oThingToKill.Parent
>>   oParentOfCondemned.RemoveObject(thisform.oThingToKill)

the line should read:

   oParentOfCondemned.RemoveObject(thisform.oThingToKill<b>.Name</b>)

>>ENDIF
>>thisform.oThingToKill = NULL
>>RETURN .F.

>>
>>(3) Instance the subclassed control on your form, call it 'txtAssasin' or something on those lines. It should not be visible but should be enabled.
>>
>>(4) In the Click() of the child control that demands the RemoveObject:
>>
>>thisform.oThingToKill = this.parent
>>thisform.txtAssasin.SetFocus()
>>
>>This is completely untried, but should give you a start that will rely on some control not contained in the thing being Removed handling the Remove process.
>>
>>This still sounds like a bad way to do things, but it's your design nightmare, not mine!