Xojo Conferences
XDCMay2019MiamiUSA

statechanged controlbehavior callback on windows vs mac (Real Studio Plugins Mailinglist archive)

Back to the thread list
Previous thread: (offlist) Re: allocation conflict...
Next thread: Time-critical windows compilation problem


macosx and unix paths   -   GOLD
  statechanged controlbehavior callback on windows vs mac   -   Alfred Van Hoek
   Re: statechanged controlbehavior callback on windows vs mac   -   William Yu
    Re: statechanged controlbehavior callback on windows vs mac   -   Alfred Van Hoek
     Re: statechanged controlbehavior callback on windows vs mac   -   William Yu
      Re: statechanged controlbehavior callback on windows vs mac   -   Alfred Van Hoek
       Re: statechanged controlbehavior callback on windows vs mac   -   William Yu

statechanged controlbehavior callback on windows vs mac
Date: 13.06.04 15:28 (Sun, 13 Jun 2004 10:28:12 -0400)
From: Alfred Van Hoek
Why is it that the statechanged callback on windows is limited to
kEnabledChanged and kBoundsChanged while excluding kActivationChanged?

In runtime:
On macosx kActivationChanged is issued when the window's activation state
changes and calling REALGetControlEnabled on my control will give the
activation state which can be used to set the focus on this control.

In runtime:
On windows the only time the callback is issued is when the bounds changes,
activating, or deactivating the window never invokes the callback.
kEnabledChanged isn't issued either in this scenario.

Setting the focus in the rb environment:

This limitation on windows goes even further: When using me.SetFocus in the
open event, the control won't get the focus.

This limitation is seriously affecting the control's ability to function as
it should and will delay commercial application.

Further:

In design time windows (IDE)
kEnabledChanged is issued when properties are set on the control in the
pr0perties window.

kActivationChanged is never issued in the IDE.

In design time mac (IDE)

When the window changes its active state, kActivationChanged is issued, and
similar to the Runtime one can obtain the active state by calling
REALGetControlEnabled.

Is all of the above intentional????????????

Alfred


_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: statechanged controlbehavior callback on windows vs mac
Date: 14.06.04 20:53 (Mon, 14 Jun 2004 14:53:06 -0500)
From: William Yu
On 6/13/04 9:28 AM, "Alfred Van Hoek" <<email address removed>> wrote:

> Why is it that the statechanged callback on windows is limited to
> kEnabledChanged and kBoundsChanged while excluding kActivationChanged?

Probably because you don't need to adjust the state of the control on
Windows/Linux when it's activated/deactivated?

> In runtime:
> On macosx kActivationChanged is issued when the window's activation state
> changes and calling REALGetControlEnabled on my control will give the
> activation state which can be used to set the focus on this control.
>
> In runtime:
> On windows the only time the callback is issued is when the bounds changes,
> activating, or deactivating the window never invokes the callback.
> kEnabledChanged isn't issued either in this scenario.

You don't normally need to do anything on Windows when the window
activates/deactivates.

> Setting the focus in the rb environment:
>
> This limitation on windows goes even further: When using me.SetFocus in the
> open event, the control won't get the focus.

Have you specified the REALcontrolAcceptFocus flag?

> In design time windows (IDE)
> kEnabledChanged is issued when properties are set on the control in the
> pr0perties window.
>
> kActivationChanged is never issued in the IDE.
>
> In design time mac (IDE)
>
> When the window changes its active state, kActivationChanged is issued, and
> similar to the Runtime one can obtain the active state by calling
> REALGetControlEnabled.
>
> Is all of the above intentional????????????

As far as the activation state goes, yes.

Regards,
William Yu
<email address removed>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: statechanged controlbehavior callback on windows vs mac
Date: 14.06.04 23:44 (Mon, 14 Jun 2004 18:44:17 -0400)
From: Alfred Van Hoek
on 6/14/04 3:53 PM, William Yu at <email address removed> wrote:

> On 6/13/04 9:28 AM, "Alfred Van Hoek" <<email address removed>> wrote:
>
>> Why is it that the statechanged callback on windows is limited to
>> kEnabledChanged and kBoundsChanged while excluding kActivationChanged?
>
> Probably because you don't need to adjust the state of the control on
> Windows/Linux when it's activated/deactivated?

Sounds ok with me, did not realize this is a general feature of windows...
>
>> In runtime:
>> On macosx kActivationChanged is issued when the window's activation state
>> changes and calling REALGetControlEnabled on my control will give the
>> activation state which can be used to set the focus on this control.
>>
>> In runtime:
>> On windows the only time the callback is issued is when the bounds changes,
>> activating, or deactivating the window never invokes the callback.
>> kEnabledChanged isn't issued either in this scenario.
>
> You don't normally need to do anything on Windows when the window
> activates/deactivates.

Guess you're right,
>
>> Setting the focus in the rb environment:
>>
>> This limitation on windows goes even further: When using me.SetFocus in the
>> open event, the control won't get the focus.
>
> Have you specified the REALcontrolAcceptFocus flag?

Yes I did experiment with this in conjunction with setfocus. With the sole
control on the window setfocus or REALSetControlFocus did not do a thing...
>
>> In design time windows (IDE)
>> kEnabledChanged is issued when properties are set on the control in the
>> pr0perties window.
>>
>> kActivationChanged is never issued in the IDE.
>>
>> In design time mac (IDE)
>>
>> When the window changes its active state, kActivationChanged is issued, and
>> similar to the Runtime one can obtain the active state by calling
>> REALGetControlEnabled.
>>
>> Is all of the above intentional????????????
>
> As far as the activation state goes, yes.
>

OK, but this leaves me with a lack of ability to set the focus on the
control, only a win-api SetFocus does the trick, which I need to set every
time the window activates. changestate callback could have given the
activate change, but unfortunately, it does not..

Do you see the problem?

Alfred

PS, I did file 2 separate bugs earlier..

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: statechanged controlbehavior callback on windows vs mac
Date: 15.06.04 00:08 (Mon, 14 Jun 2004 18:08:02 -0500)
From: William Yu
On 6/14/04 5:44 PM, "Alfred Van Hoek" <<email address removed>> wrote:

>>> Setting the focus in the rb environment:
>>>
>>> This limitation on windows goes even further: When using me.SetFocus in the
>>> open event, the control won't get the focus.
>>
>> Have you specified the REALcontrolAcceptFocus flag?
>
> Yes I did experiment with this in conjunction with setfocus. With the sole
> control on the window setfocus or REALSetControlFocus did not do a thing...

Alfred,
What exactly were you expecting it to do? If you specified the
REALcontrolAcceptFocus flag for your control, then the gainedFocus function
should fire, is it not?

>> As far as the activation state goes, yes.
>
> OK, but this leaves me with a lack of ability to set the focus on the
> control, only a win-api SetFocus does the trick, which I need to set every
> time the window activates. changestate callback could have given the
> activate change, but unfortunately, it does not..
>
> Do you see the problem?

When the window becomes active, we call the gainedFocus function again. If
it's not being called, then I'd file a bug report. I'm not sure how you're
determining whether or not the control has focus, perhaps you can explain
some more.

> PS, I did file 2 separate bugs earlier..

Ok, I see them, do you still consider them bugs?

Regards,
William Yu
<email address removed>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: statechanged controlbehavior callback on windows vs mac
Date: 15.06.04 02:16 (Mon, 14 Jun 2004 21:16:43 -0400)
From: Alfred Van Hoek
on 6/14/04 7:08 PM, William Yu at <email address removed> wrote:

> Alfred,
> What exactly were you expecting it to do? If you specified the
> REALcontrolAcceptFocus flag for your control, then the gainedFocus function
> should fire, is it not?

Right, but the control does not get the focus, and calling setfocus does not
set the focus, nor does REALControlSetFocus.

I have to agree that gained focus will give the active state which can be
used to call the winapi setfocus.

The potential problem with the advance focus RB provides when 2 or more
acceptfocus-controls are on the window is that the tab key is used for
advancing, but we need the tab for advancing within embedded controls of one
REALcontrol.

Currently we capture the tabkey in the keydown you remove from the
WM_KEYDOWN of the controlHWND and send it back to the controlHWND.

We eventually would want to have 2 of our controls on the window, and
foresee a lot of problems if rb is handling the advance focus. Therefore we
thought to not use the REALcontrolAcceptFocus flag, while being able to do
our own "housekeeping".

Unfortunately, we won't get the keydown callback, and the tab key we want to
capture has then to be done somewhere else..

So a couple of issues:

1) no REALcontrolAcceptFocus so RB will not advance focus for us, and a
novel mechanism to sense active window (via statechanged)

2) We want the tabkey to be able to do our own focus advancing of embedded
controls

3) RB's SetFocus to set the focus on the realcontrol, which currently does
not work with or without the REALcontrolAcceptFocus being set

>
>>> As far as the activation state goes, yes.
>>
>> OK, but this leaves me with a lack of ability to set the focus on the
>> control, only a win-api SetFocus does the trick, which I need to set every
>> time the window activates. changestate callback could have given the
>> activate change, but unfortunately, it does not..
>>
>> Do you see the problem?
>
> When the window becomes active, we call the gainedFocus function again. If
> it's not being called, then I'd file a bug report. I'm not sure how you're
> determining whether or not the control has focus, perhaps you can explain
> some more.

It appears the setfocus on windows does not work, therefore I consider this
a bug. We also would want another mechanism to sense active/deactive, to
avoid gain and loose focus, and a way to get the tabkey when we wouldn't
want to use the REALcontrolAcceptFocus flag..

>
>> PS, I did file 2 separate bugs earlier..
>
> Ok, I see them, do you still consider them bugs?

Yes, I do, and the tab key steal I should report too...

I appreciate your questioning, it is helpful to nail the issues.

Also, all of the limitations of the above does not seem to be present on the
mac. Setfocus works with or without the REALcontrolAcceptFocus being set,
REALControlSetFocus works, and we can easily get the tab using carbon
events...

regards,

Alfred
>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: statechanged controlbehavior callback on windows vs mac
Date: 15.06.04 16:38 (Tue, 15 Jun 2004 10:38:44 -0500)
From: William Yu
On 6/14/04 8:16 PM, "Alfred Van Hoek" <<email address removed>> wrote:

>> Alfred,
>> What exactly were you expecting it to do? If you specified the
>> REALcontrolAcceptFocus flag for your control, then the gainedFocus function
>> should fire, is it not?
>
> Right, but the control does not get the focus, and calling setfocus does not
> set the focus, nor does REALControlSetFocus.

Well, I suppose this is debatable, but what happens when you call
REALControlSetFocus is that we check for the REALcontrolAcceptFocus flag,
and if it's set, then we call the gainedFocus function, and in that function
you can call the WinAPI SetFocus function to set the focus to the
appropriate control. Perhaps this is not what you expected... Nor did I
really, until I looked at the code some more. However, this is how its been
working for the longest time I think, so to change the behavior now would
take a few more votes.

> I have to agree that gained focus will give the active state which can be
> used to call the winapi setfocus.

Yes, that's how it needs to be done.

> The potential problem with the advance focus RB provides when 2 or more
> acceptfocus-controls are on the window is that the tab key is used for
> advancing, but we need the tab for advancing within embedded controls of one
> REALcontrol.
>
> Currently we capture the tabkey in the keydown you remove from the
> WM_KEYDOWN of the controlHWND and send it back to the controlHWND.

Right, but I'm not sure what you want requested here, a TabbedOut function
maybe, so you can prevent the tab from exiting your control?

> So a couple of issues:
>
> 1) no REALcontrolAcceptFocus so RB will not advance focus for us, and a
> novel mechanism to sense active window (via statechanged)
>
> 2) We want the tabkey to be able to do our own focus advancing of embedded
> controls

These two sound like the same problem, perhaps a function callback to
prevent tabbing out is what you want, but please feature request exactly
what you need, otherwise we'll start implementing something that makes
absolutely no sense in your situation.

> 3) RB's SetFocus to set the focus on the realcontrol, which currently does
> not work with or without the REALcontrolAcceptFocus being set

That's debatable, perhaps better docs would help. It would be feature
request to change our current behavior, which I'm not opposed to, but it'll
take some votes.

> Also, all of the limitations of the above does not seem to be present on the
> mac. Setfocus works with or without the REALcontrolAcceptFocus being set,
> REALControlSetFocus works, and we can easily get the tab using carbon
> events...

Then perhaps it is a bug... But not of the showstopper variety I imagine,
since there is an easy workaround for that focus problem.

Regards,
William Yu
<email address removed>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>