no easy way to get notified when the application is *reall..

"TJ" <someone DeleteThis @somewhere.com> wrote in message
news:af-dnbFPxoqtty3fRVn-jQ@midco.net...
> Use GetForegroundWindow to make sure your window(s) aren't active.

that's not sufficient, and in addition it does not work (how do you know the
window handle of system modal dialog like MessageBox ?).

and when your applications becomes active again, how do you get notified ?
if the active window of your app is a model dialog like MessageBox, your
window procedure will never receive an activate message when the modal
dialog (that belongs to your app) becomes active.

>
> The PocketTV Team wrote:
>> do you know an easy way to get notified when your application is *really*
>> deactivated (and *really* activated)?
>>
>> when i mean by *really* is that the application is *really* deactivated
>> when ALL its top-level windows (indluding its modal dialogs) are
>> deactivated - i.e. the active window belongs to another application. and
>> the application is *really* activated when the active window belongs to
>> it (i.e. it is one of its top-level windows or a modal dialog that
>> belongs to the application).
>>
>> yes, i know about WM_ACTIVATE, but this message only indicates that a
>> particular window (which received the message) gets deactivated or
>> activated. it does not mean that the application is *really* deactivated
>> or activated. for example, your main window will receive WM_ACTIVATE
>> with WA_INACTIVE when it opens a modal dialogs.
>>
>> i find it very difficult to get notified of the actual
>> activated/deactivated status of the application because in some cases,
>> when a modal dialog is active, the deactivated/activated messages for
>> this modal dialog are sent to the modal window, which in some cases has
>> an event loop that is not controlable by the application (e.g.
>> MessageBox).
>>
>> am i missing something obvious ?
>>
>>

Actually it does work. When you have a modal dialog (MessageBox..) then
GetForegroundWindow() will return your parent window's handle. Thus you
can tell if it is or isn't the active window even if there is a
MessageBox up. So you can use that when then WA_INACTIVE parameter is
sent with the event to know if it really is inactive.


The PocketTV Team wrote:
> "TJ" <someone.RemoveThis@somewhere.com> wrote in message
> news:af-dnbFPxoqtty3fRVn-jQ@midco.net...
>
>>Use GetForegroundWindow to make sure your window(s) aren't active.
>
>
> that's not sufficient, and in addition it does not work (how do you know the
> window handle of system modal dialog like MessageBox ?).
>
> and when your applications becomes active again, how do you get notified ?
> if the active window of your app is a model dialog like MessageBox, your
> window procedure will never receive an activate message when the modal
> dialog (that belongs to your app) becomes active.
>
>
>>The PocketTV Team wrote:
>>
>>>do you know an easy way to get notified when your application is *really*
>>>deactivated (and *really* activated)?
>>>
>>>when i mean by *really* is that the application is *really* deactivated
>>>when ALL its top-level windows (indluding its modal dialogs) are
>>>deactivated - i.e. the active window belongs to another application. and
>>>the application is *really* activated when the active window belongs to
>>>it (i.e. it is one of its top-level windows or a modal dialog that
>>>belongs to the application).
>>>
>>>yes, i know about WM_ACTIVATE, but this message only indicates that a
>>>particular window (which received the message) gets deactivated or
>>>activated. it does not mean that the application is *really* deactivated
>>>or activated. for example, your main window will receive WM_ACTIVATE
>>>with WA_INACTIVE when it opens a modal dialogs.
>>>
>>>i find it very difficult to get notified of the actual
>>>activated/deactivated status of the application because in some cases,
>>>when a modal dialog is active, the deactivated/activated messages for
>>>this modal dialog are sent to the modal window, which in some cases has
>>>an event loop that is not controlable by the application (e.g.
>>>MessageBox).
>>>
>>>am i missing something obvious ?
>>>
>>>
>
>

Hi,

> >>>when i mean by *really* is that the application is *really* deactivated
> >>>when ALL its top-level windows (indluding its modal dialogs) are
> >>>deactivated - i.e. the active window belongs to another application.
and

I would suggest that you should really only have one top level window--The
main app window. This makes WM_ACTIVATE management much easier,
as NULL windows are "not yours."--Not to mention the havoc wreaked with
task managers just listing top level windows--Imagine a user using the task
manager to activate one of your top level windows that should not be
accessible at the time.

My $0.02

Almon B. Strowger
KOOK Pocket Software

> I would suggest that you should really only have one top level window--The
> main app window. This makes WM_ACTIVATE management much easier,
> as NULL windows are "not yours."--Not to mention the havoc wreaked with
> task managers just listing top level windows--Imagine a user using the
> task
> manager to activate one of your top level windows that should not be
> accessible at the time.

i agree in theory, but in many case, this is not possible.

1) as soon as you have a modal dialog in your app, it becomes the active
window, and that's not the main window app.

2) in our case (video player), we want to support full-screen, so we have a
fullscreen mode, and in this mode, an alternate window (which is fullscreen)
becomes active.

but the case that concerns me most is the case of modal dialogs. how can
you have a modal dialog without it becoming the active window ???

Hi,

"The PocketTV Team" <support.TakeThisOut@pockettv.com> wrote in message
news:edkcqVpeFHA.2288@TK2MSFTNGP14.phx.gbl...
> > I would suggest that you should really only have one top level
window--The
> > main app window. This makes WM_ACTIVATE management much easier,
> > as NULL windows are "not yours."--Not to mention the havoc wreaked with
> > task managers just listing top level windows--Imagine a user using the
> > task
> > manager to activate one of your top level windows that should not be
> > accessible at the time.
>
> i agree in theory, but in many case, this is not possible.

Okay, so check if windows are decsendants or owned by your two
top-level windows.
Make all windows parented or owned.

> 1) as soon as you have a modal dialog in your app, it becomes the active
> window, and that's not the main window app.

That's kindof the idea of a modal window. What is the problem here?
If you are using, say, MessageBox, make it owned by one of your two
top level main app windows. GetParent() also gives the owner of an
owned window.

> 2) in our case (video player), we want to support full-screen, so we have
a
> fullscreen mode, and in this mode, an alternate window (which is
fullscreen)
> becomes active.
>
> but the case that concerns me most is the case of modal dialogs. how can
> you have a modal dialog without it becoming the active window ???

Are you saying you want a modal dialog box that is not fronted, but another
window of the same app is?!? Maybe running two separate processes is
better for you. Please explain in more detail.


Almon B. Strowger
KOOK Pocket Software

Almon B. Strowger, i don't think you read my first post in this thread.

if you had, you would know what problem i was raising, and you would
understand why it is a problem.

here is a copy:

===========================
do you know an easy way to get notified when your application is *really*
deactivated (and *really* activated)?

when i mean by *really* is that the application is *really* deactivated when
ALL its top-level windows (indluding its modal dialogs) are deactivated -
i.e. the active window belongs to another application. and the application
is *really* activated when the active window belongs to it (i.e. it is one
of its top-level windows or a modal dialog that belongs to the application).

yes, i know about WM_ACTIVATE, but this message only indicates that a
particular window (which received the message) gets deactivated or
activated. it does not mean that the application is *really* deactivated or
activated. for example, your main window will receive WM_ACTIVATE with
WA_INACTIVE when it opens a modal dialogs.

i find it very difficult to get notified of the actual activated/deactivated
status of the application because in some cases, when a modal dialog is
active, the deactivated/activated messages for this modal dialog are sent to
the modal window, which in some cases has an event loop that is not
controlable by the application (e.g. MessageBox).

am i missing something obvious ?
=============================

what i am saying is that when your application has an active modal dialog
(i.e. your application it is the active application), it is very difficult
to get notified in the case it is de-activated (e.g. because another app of
a shell window becomes active).

that's because in that case, the WM_ACTIVATE message with WA_INACTIVE will
be sent to the active dialog, not to your main window.

in other words, what i am saying is that the fact that the main window is
de-activated deos not mean that the *application* itself looses the
foreground, it only means that the application's main window looses the
forground.

the notion of active application is different from the notion of active main
window, but most people tend to identify the two.

anyway, the people who are confronted to this problem do understand it, i'm
sure, and the people who don't understand that there can be a problem
probably don't need to deal with it.


"Almon B. Strowger" <strowger.TakeThisOut@NOSPAM.kook.com> wrote in message
news:%23x3Xf6reFHA.1400@TK2MSFTNGP15.phx.gbl...
>
> Hi,
>
> "The PocketTV Team" <support.TakeThisOut@pockettv.com> wrote in message
> news:edkcqVpeFHA.2288@TK2MSFTNGP14.phx.gbl...
>> > I would suggest that you should really only have one top level
> window--The
>> > main app window. This makes WM_ACTIVATE management much easier,
>> > as NULL windows are "not yours."--Not to mention the havoc wreaked with
>> > task managers just listing top level windows--Imagine a user using the
>> > task
>> > manager to activate one of your top level windows that should not be
>> > accessible at the time.
>>
>> i agree in theory, but in many case, this is not possible.
>
> Okay, so check if windows are decsendants or owned by your two
> top-level windows.
> Make all windows parented or owned.
>
>> 1) as soon as you have a modal dialog in your app, it becomes the active
>> window, and that's not the main window app.
>
> That's kindof the idea of a modal window. What is the problem here?
> If you are using, say, MessageBox, make it owned by one of your two
> top level main app windows. GetParent() also gives the owner of an
> owned window.
>
>> 2) in our case (video player), we want to support full-screen, so we have
> a
>> fullscreen mode, and in this mode, an alternate window (which is
> fullscreen)
>> becomes active.
>>
>> but the case that concerns me most is the case of modal dialogs. how can
>> you have a modal dialog without it becoming the active window ???
>
> Are you saying you want a modal dialog box that is not fronted, but
> another
> window of the same app is?!? Maybe running two separate processes is
> better for you. Please explain in more detail.
>
>
> Almon B. Strowger
> KOOK Pocket Software
>
>

Hi,

Well, yes, AFAIK if you are using MessageBox, this is a problem.

If your app is trying to "be a good citizen" and needs to change settings
when something else is activated, etc. either:
Don't use MessageBox.
Change those settings before you call MessageBox then restore them when it
returns.
Don't let it bother you.

Even if your app can't know that there has been another app fronted because
it was
done during a MessageBox, if you take care that it is owned, when your app
is
reactivated and the user hits 'OK' or whatever, your app still thinks it is
active, and
it now is, so it's not that serious. And on return from the MessageBox you
can have
your app check and restore any settings that the user may have changed
outside of
your app.
Now if you plan to be able to have the user go to another window in your app
while the modal (MessageBox) is up, this kindof violates the idea of a modal
app
window, as I mentioned before, and could cause more issues--This is why I
mentioned
the possibility of separate processes.

If you roll your own "MessageBox", obviously you'll have access to the
WM_ACTIVATE's that you so crave, so maybe you should seriously consider it.
(Didn't you guys already do that at some point anyway?)


Almon B. Strowger
KOOK Pocket Software

Yes, but the problem is not just with MessageBox. The same problem will
happen if you use any other library call that will cause a modal dialog,
e.g. GetOpenFileName, GetSaveFileName etc...

Yes, of course you can roll your own version of each of those, but it quite
defeats the idea that if MSFT provides a service, you should not implement
an equivalent one yourself. And re-implementing correctly all those dialogs
is certainely more work than it looks, especially if you need to handle
correctly all cases of localization (i.e. non-english language).

So this does not look like a good solution.

> Change those settings before you call MessageBox then restore them when it
> returns.

Yes, the simplest solution is to do that, but it's kind-a stupid because in
most cases, it requires doing lots of things that are not necessary.

> (Didn't you guys already do that at some point anyway?)

Yes, we have made a replacement for MessageBox, and it is a shareware called
MsgBox (see http://www.mpegtv.com/wince/msgbox/ ). but because MsgBox is a
100% compatible replacement of MessageBox, it does not give access to the
WM_ACTIVATE's.

The only purpose of MsgBox is to have a version of MessageBox that works
correctly on Pocket PC 2003 SE when the screen is rotated to Landscape mode
(MessageBox is completely broken on Pocket PC 2003 SE, see
http://www.mpegtv.com/wince/msgbox/ if you don't know why).

So basically you do confirm my analysis. thanks.

-t


"Almon B. Strowger" <strowger.DeleteThis@NOSPAM.kook.com> wrote in message
news:u2gpsISfFHA.3448@TK2MSFTNGP12.phx.gbl...
>
> Hi,
>
> Well, yes, AFAIK if you are using MessageBox, this is a problem.
>
> If your app is trying to "be a good citizen" and needs to change settings
> when something else is activated, etc. either:
> Don't use MessageBox.
> Change those settings before you call MessageBox then restore them when it
> returns.
> Don't let it bother you.
>
> Even if your app can't know that there has been another app fronted
> because
> it was
> done during a MessageBox, if you take care that it is owned, when your app
> is
> reactivated and the user hits 'OK' or whatever, your app still thinks it
> is
> active, and
> it now is, so it's not that serious. And on return from the MessageBox
> you
> can have
> your app check and restore any settings that the user may have changed
> outside of
> your app.
> Now if you plan to be able to have the user go to another window in your
> app
> while the modal (MessageBox) is up, this kindof violates the idea of a
> modal
> app
> window, as I mentioned before, and could cause more issues--This is why I
> mentioned
> the possibility of separate processes.
>
> If you roll your own "MessageBox", obviously you'll have access to the
> WM_ACTIVATE's that you so crave, so maybe you should seriously consider
> it.
> (Didn't you guys already do that at some point anyway?)
>
>
> Almon B. Strowger
> KOOK Pocket Software
>
>
>