Actually, I create a Mixin class that implements a behaviour using the
Activate_Area method and Activate_State property. So, as I have my own
classes, I implements my own Activate, using the Mixin class that I created.
So, when is necessary, I call the Activate_Area method, or, I just call the


"John Tuohy" <john-t@dataaccess.com> escreveu na mensagem
> You will notice that I very carefully stated:
> "You should not send activate to a control or an inner container that is
> not yet paged. If you do this, it is an error and things just won't work
> right."
> What we probably should have done in this case was to raise an error, but
> we didn't think of that those many years ago. Instead it just doesn't work
> right. The control doesn't really disappear because it never appeared in
> the first place. At this point the windows control and the DataFlex object
> are no longer working together. I am not really sure if the windows
> control gets created and if it does, where it is. I am not sure if the
> DataFlex object thinks it is active or not. I don't know because it really
> doesn't matter - it's wrong and once this happens, it will never be right.
> The only solution is "don't do it". Hopefully one of the three solutions
> presented (two by me, one by Anders) will let you solve this issue in your
> code.
> -John
> "Rafael" <rafael@softdata.com.br> wrote in message
> newsO$0BOKdJHA.2072@dacmail.dataaccess.com...
>> Ok, I undestant the point. I need "page" the object first, to call the
>> activate method.
>> But I think that the activate method don't make the object disappear. I
>> guess that just don't activate the object, if isn't paged. Am I thinking
>> wrong?
>> Rafael
>> "John Tuohy" <john-t@dataaccess.com> escreveu na mensagem
>> news:61m%239AocJHA.2076@dacmail.dataaccess.com...
>>> Yes, Request_Tab_Display will do the job as well. I almost suggested
>>> that. In certain ways it has the advantage of activate that the
>>> programmer's intent is clearer, which makes it less likely that someone
>>> else will remove the code years later thinking it is not needed. And,
>>> yes, you have to be careful where you put "Set Current_Radio" in the
>>> RadioGroup - you normally want it at the bottom of your object.
>>> -John
>>> "Anders Öhrt" <Anders.Ohrt@berendsen.se> wrote in message
>>> news:zD9DvhjcJHA.2072@dacmail.dataaccess.com...
>>>>> Garret, I think this is a different issue and my guess is that it has
>>>>> always
>>>>> been in the product.
>>>> I think so too, we've run into this occasionally for as long as I can
>>>> remember (meaning at least VDF7) and worked around it on a case by case
>>>> basis.
>>>>> You should not send activate to a control or an inner container that
>>>>> is not yet paged. If you do this, it is an error and things just won't
>>>>> work right. For example, you should not send activate to a button if
>>>>> the view itself is not yet activated. Normally this is a non-issue
>>>>> because it not something you are likely to do. Tab dialogs are an
>>>>> exception to this is a design flaw with tab pages.
>>>> Another case I just ran into yesterday, which is semi-similar, is if
>>>> you do things in Notify_Select_State in a RadioGroup, and then directly
>>>> after the code for the procedure does a Set Current_Radio to 0, then
>>>> Notify_Select_State will be called very early (End_Construct_Object of
>>>> the RadioGroup), and there other objects might not even be created yet,
>>>> much less paged.
>>>>> When tab dialogs are created we don't activate all of the child table
>>>>> pages. We only activate them as needed. We did this for performance
>>>>> reasons. So when you send activate to the control in the second tab
>>>>> page, it is not yet paged and it just does wrong things. It appears
>>>>> non-visible and internally it is really messed up.
>>>> When ever we do something like this, we do a Request_Tab_Display first.
>>>> This makes sure the other tab and any child objects are created and
>>>> paged.
>>>> // Anders