Detecting (lack of) input focus

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Detecting (lack of) input focus

Anders Munch

Hi,

 

I have an Windows application that is launched from a different program, in a way that for some reason makes Windows decide not to give my program input focus.

So first thing the program puts up a login dialogue, users see it and start typing, but nothing happens.

 

I tried wx.Dialog.Raise, but it makes no difference.

 

I’ve made my peace with Windows not giving my program focus, but I’d like to give my users stronger visual feedback to indicate that they can’t start typing just yet, they have to click on the window first. The title bar has grey text, but that is very easy to overlook. Also, the application icon is blinking, but users aren’t looking at that, they’re looking at the dialogue that just popped up.

 

Now here’s my problem: I can’t find a test that will tell me if my login dialogue has keyboard focus. Everything I query tells me that it’s active and focused and everything:

-        wx.GetApp().IsActive() returns True.

-        event.GetActive() for the latest wx.EVT_ACTIVATE event on the dialogue return True.

-        The TextCtrl has received a wx.EVT_SET_FOCUS event with no wx.EVT_KILL_FOCUS to follow.

And yet, the title bar remains grey.

 

If I click on the dialogue and click away, both active-flags change to False just as I would expect, and from then on works fine, but that’s a little late, I need to know the state on startup.

 

Any ideas? Is there yet another event or state flag I could check?

Perhaps it’s a wxWidgets bug, but I hope not, because creating a reproducing sample won’t be easy.  When I launch my app from the start menu this doesn’t happen.

 

Versions: '4.0.3 msw (phoenix) wxWidgets 3.0.5', Python 3.6.6, .exe-built with cx_Freeze.

 

regards, Anders

 

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Detecting (lack of) input focus

Anders Munch
Rolf wrote:
> Does self.SetWindowStyle(wx.STAY_ON_TOP) help at all?

No.  I'm already setting STAY_ON_TOP.

regards, Anders

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Detecting (lack of) input focus

Vlastimil Brom
In reply to this post by Anders Munch
2018-10-10 13:33 GMT-22:00, Anders Munch <[hidden email]>:

> Hi,
>
> I have an Windows application that is launched from a different program, in
> a way that for some reason makes Windows decide not to give my program input
> focus.
> So first thing the program puts up a login dialogue, users see it and start
> typing, but nothing happens.
>
> I tried wx.Dialog.Raise, but it makes no difference.
>
> I've made my peace with Windows not giving my program focus, but I'd like to
> give my users stronger visual feedback to indicate that they can't start
> typing just yet, they have to click on the window first. The title bar has
> grey text, but that is very easy to overlook. Also, the application icon is
> blinking, but users aren't looking at that, they're looking at the dialogue
> that just popped up.
>
> Now here's my problem: I can't find a test that will tell me if my login
> dialogue has keyboard focus. Everything I query tells me that it's active
> and focused and everything:
>
> -        wx.GetApp().IsActive() returns True.
>
> -        event.GetActive() for the latest wx.EVT_ACTIVATE event on the
> dialogue return True.
>
> -        The TextCtrl has received a wx.EVT_SET_FOCUS event with no
> wx.EVT_KILL_FOCUS to follow.
> And yet, the title bar remains grey.
>
> If I click on the dialogue and click away, both active-flags change to False
> just as I would expect, and from then on works fine, but that's a little
> late, I need to know the state on startup.
>
> Any ideas? Is there yet another event or state flag I could check?
> Perhaps it's a wxWidgets bug, but I hope not, because creating a reproducing
> sample won't be easy.  When I launch my app from the start menu this doesn't
> happen.
>
> Versions: '4.0.3 msw (phoenix) wxWidgets 3.0.5', Python 3.6.6, .exe-built
> with cx_Freeze.
>
> regards, Anders
>
> --
Hi,
it is rather difficult to identify the problem without a runnable
sample - in my brief experiments the mentioned function .IsActive()
seems to work as expected - when called on a specific Frame; the same
is true for Raise() - this works if the program itself is activated
within a desktop managment (otherwise the icon of the program in the
taskbar only starts blinking, requiring attention).

I might be possible to mess with activating running apps e.g. via
pywin, e.g. like:
https://www.blog.pythonlibrary.org/2014/10/20/pywin32-how-to-bring-a-window-to-front/
 but I am not sure about the compatibility with recent versions of
Python, wxPython, Windows...

I'd probably suggest a rather dirty solution - just imply the missing
focus on first displaying the dialog (even without checking) and show
an appropriare visible instruction "Click here to enter login data..."
- this hint/warning can be removed, once the dialog has been
positively clicked at.

hth,
   vbr

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Detecting (lack of) input focus

Anders Munch
In reply to this post by Anders Munch
Vlastimil Brom wrote:
> it is rather difficult to identify the problem without a runnable sample

I know. The minimum requirements for reproducing include
- a  program that pops up a dialogue as the first thing
- built into an .exe; I'm currently using cx_Freeze and Python 3, but older py2exe/Python 2 builds have the same behaviour.
- started by a launcher program, which is a C program calling CreateProcess to start the cx_Freeze .exe.
- the launcher program situated on a network share
Between the time it would take me to make a decent reproducing sample, and the time it would impose on someone else to set it up and run it, I'm not sure it's worth it for a very minor problem.

> (otherwise the icon of the program in the taskbar only starts blinking,
> requiring attention).

This is exactly the situation I'm trying to detect.  IsActive() returns True, but Windows does not let keypresses through.

> I might be possible to mess with activating running apps e.g. via pywin, e.g. like:
> https://www.blog.pythonlibrary.org/2014/10/20/pywin32-how-to-bring-a-window-to-front/
>  but I am not sure about the compatibility with recent versions of Python, wxPython, Windows...

I tried it and SetForegroundWindow raised the exception pywintypes.error code 0: "No error message is available".

I don't think it will work anyway - once Windows has put the app into needs-attention mode, I don't think you can force it to make it fully active.  By that time Windows has already made a judgment call to half-ignore the Raise to protect the user from sending keypresses to the wrong program, and it's not going to change its mind just because you call Raise again in a roundabout way.

> I'd probably suggest a rather dirty solution - just imply the missing focus on
> first displaying the dialog (even without checking) and show an appropriare
> visible instruction "Click here to enter login data..."
> - this hint/warning can be removed, once the dialog has been positively clicked at.

Nice idea. I'm not sure it's a worthwhile improvement over the current state of affairs though.

Thanks for your input.

regards, Anders

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

RE: Detecting (lack of) input focus

GadgetSteve


> -----Original Message-----
> From: [hidden email] <wxpython-
> [hidden email]> On Behalf Of Anders Munch
> Sent: 12 October 2018 09:53
> To: [hidden email]
> Subject: Re: [wxPython-users] Detecting (lack of) input focus
>
> Vlastimil Brom wrote:
> > it is rather difficult to identify the problem without a runnable
> > sample
>
> I know. The minimum requirements for reproducing include
> - a  program that pops up a dialogue as the first thing
> - built into an .exe; I'm currently using cx_Freeze and Python 3, but older
> py2exe/Python 2 builds have the same behaviour.
> - started by a launcher program, which is a C program calling CreateProcess to
> start the cx_Freeze .exe.
> - the launcher program situated on a network share Between the time it
> would take me to make a decent reproducing sample, and the time it would
> impose on someone else to set it up and run it, I'm not sure it's worth it for a
> very minor problem.
>
> > (otherwise the icon of the program in the taskbar only starts
> > blinking, requiring attention).
>
> This is exactly the situation I'm trying to detect.  IsActive() returns True, but
> Windows does not let keypresses through.
>
> > I might be possible to mess with activating running apps e.g. via pywin, e.g.
> like:
> > https://www.blog.pythonlibrary.org/2014/10/20/pywin32-how-to-bring-a-
> w
> > indow-to-front/  but I am not sure about the compatibility with recent
> > versions of Python, wxPython, Windows...
>
> I tried it and SetForegroundWindow raised the exception pywintypes.error
> code 0: "No error message is available".
>
> I don't think it will work anyway - once Windows has put the app into needs-
> attention mode, I don't think you can force it to make it fully active.  By that
> time Windows has already made a judgment call to half-ignore the Raise to
> protect the user from sending keypresses to the wrong program, and it's not
> going to change its mind just because you call Raise again in a roundabout
> way.
>
> > I'd probably suggest a rather dirty solution - just imply the missing
> > focus on first displaying the dialog (even without checking) and show
> > an appropriare visible instruction "Click here to enter login data..."
> > - this hint/warning can be removed, once the dialog has been positively
> clicked at.
>
> Nice idea. I'm not sure it's a worthwhile improvement over the current state
> of affairs though.
>
> Thanks for your input.
>
> regards, Anders
>
How about starting with a button with "Click Here To Log In" or just "START" then the user will not be tempted to start typing?

--
You received this message because you are subscribed to the Google Groups "wxPython-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.