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:
PyWin32 - How to Bring a Window to Front - Mouse Vs Python
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?
ยทยทยท
-----Original Message-----
From: wxpython-users@googlegroups.com <wxpython-
users@googlegroups.com> On Behalf Of Anders Munch
Sent: 12 October 2018 09:53
To: wxpython-users@googlegroups.com
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:
> PyWin32 - How to Bring a Window to Front - Mouse Vs Python
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