How to find if Application has Focus

[=?ISO-8859-15?Q?Albe_V=B0?=]

In my Application, I need to make a certain graphical refresh,
interrogating SqlServer, only if Application has focus (i.e. the title
bar is blue).

Interrogating .Focused property of various forms of the project is not
the way (maybe, enumerting forms and checking if at least one of them
has focus may work, but I don't think this to be the most beautiful
solution).

Any idea?

Thanks in advance

Alberto

--
Georges Pompidou: Un uomo di stato è un politico che dona se stesso al
servizio della nazione. Un politico è un uomo di stato che pone la
nazione al suo servizio.

[=?Utf-8?B?RmFtaWx5IFRyZWUgTWlrZQ==?=]

RE: How to find if Application has Focus

For your definition of the application having focus, testing (Form.ActiveFor m
!= null) should work.

"Albe V°" wrote:

In my Application, I need to make a certain graphical refresh,
interrogating SqlServer, only if Application has focus (i.e. the title
bar is blue).
>
Interrogating .Focused property of various forms of the project is not
the way (maybe, enumerting forms and checking if at least one of them
has focus may work, but I don't think this to be the most beautiful
solution).
>
Any idea?
>
Thanks in advance
>
Alberto
>
--
Georges Pompidou: Un uomo di stato è un politico che dona se stesso al
servizio della nazione. Un politico è un uomo di stato che pone la
nazione al suo servizio.
>
>
>

[Ignacio Machin ( .NET/ C# MVP )]

Re: How to find if Application has Focus

On May 14, 5:59 am, Albe V° <vaccariTO...@h otmail.comwrote :

In my Application, I need to make a certain graphical refresh,
interrogating SqlServer, only if Application has focus (i.e. the title
bar is blue).

From where you do the refresh?

I think that you need to check not if a form is focused but if the
form where you are painting is active.
are y ou painting from a worker thread?
In any case you use Form.ActiveForm to get the active form of the app

[=?ISO-8859-15?Q?Albe_V=B0?=]

Re: How to find if Application has Focus

Ignacio Machin ( .NET/ C# MVP ), grazie al ripristinarsi del
collegamento fra i due neuroni, mercoledì ha scritto:

On May 14, 5:59 am, Albe V° <vaccariTO...@h otmail.comwrote :

>In my Application, I need to make a certain graphical refresh,
>interrogatin g SqlServer, only if Application has focus (i.e. the title
>bar is blue).

>
From where you do the refresh?

One of the form of the solution has a timer, and the timer calls a
refresh procedure.
Unfortunately, there is a .Net documented bug that makes the app crash
if graphical refreshes are frequently called when the app itself is in
background ina terminal server session.
Now, a customer is in this unlucky situation: the operators use then
client in each own terminal server session, the client makes a
graphical layout refresh according to some SqlServer data, but if the
operator opens another application, and puts my client application in
background or minimized, the app itself crashes.
At the present, MS does not provide any solution, so the only thing I
can do is to try to avoid this refresh.

But: How can I determine if the app is in background?

>
I think that you need to check not if a form is focused but if the
form where you are painting is active.

No, the form has to be repainted if the app has the focus.
If the app has the focus, but the operator clicked on a menu or on a
treeview menu, the form itself is active, but with no focus. If the app
is minimized, the form is anyway active, with no focus, but this causes
the crash.

are y ou painting from a worker thread?

I don't exactly know what a worker thread is...

In any case you use Form.ActiveForm to get the active form of the app

But the app has always an active form, even if the app is in
background.
I also tried enumerating and testing on Application.Ope nforms, but if I
click on a treeview menu (by example), I don't find any form with
..Focused property True.


Bye

Alberto

--
La forza di volontà è guardare negli occhi una ragazza in topless.

[Peter Duniho]

Re: How to find if Application has Focus

On Wed, 14 May 2008 07:42:27 -0700, Albe V° <vaccariTOGLI@h otmail.com>
wrote:

One of the form of the solution has a timer, and the timer calls a
refresh procedure.
Unfortunately, there is a .Net documented bug that makes the app crash
if graphical refreshes are frequently called when the app itself is in
background ina terminal server session.
Now, a customer is in this unlucky situation: the operators use then
client in each own terminal server session, the client makes a graphical
layout refresh according to some SqlServer data, but if the operator
opens another application, and puts my client application in background
or minimized, the app itself crashes.
At the present, MS does not provide any solution, so the only thing I
can do is to try to avoid this refresh.
>
But: How can I determine if the app is in background?

That's an unfortunate bug.

My first thought is to wonder whether "refreshes are frequently called" is
so frequent that it wouldn't matter to the user to simply slow them down
all the time. At what frequency does a graphical update result in a
crash? Would it be feasible to simply reduce your visual refresh
frequency to some rate below this critical rate?

Barring that, I don't believe what you want is possible using only the
..NET Framework. I haven't noticed anything like this available directly
in the framework. However, Windows certainly provides that information
and you can get at it through various means. I'd guess the most direct
way would be to use the Application.Add MessageFilter() to watch for
WM_ACTIVATEAPP messages. Your application will receive one with it
changes state from foreground to background or vice a versa.

If that doesn't do it, you might submit a support request to Microsoft via
their web site. They provide two free support requests per product, and
my experience has been that a) they extend this to development questions,
and b) if the support request is a consequence of some bug in their
products, they credit back the request to your product ID. I've had about
a 50% success rate getting actual solutions for bugs in Windows this way,
and have always at least received a courteous effort to try to solve the
problem.

Granted, my sample size is low (maybe a half-dozen at most over the last
ten years or so), but it's worth a try if the above doesn't help. The bug
you're dealing with is fairly serious and seems clearly specific to a
particular Microsoft product; I would expect them to be reasonably
proactive in trying to help you deal with it.

Pete