10 seconds to deselect

All graphical and user interfaces problems

10 seconds to deselect

Postby DGDanforth » Wed Feb 15, 2017 6:46 am

I am running Windows 10.

If I start a selection and very slowly move the mouse then after 10 seconds
the deselection disengages. What I mean by that is the screen does a brief flicker
and continuing to move the mouse no longer causes the text to be selected.

Has anyone else seen that behavior?

-Doug Danforth
User avatar
DGDanforth
 
Posts: 46
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, CA, U.S.A.

Re: 10 seconds to deselect

Postby Josef Templ » Wed Feb 15, 2017 10:03 am

I can reproduce this behavior if the remote debugger is running,
both under Win 10 and Vista.

Did you do any experiments with RemDebug?

- Josef
Josef Templ
 
Posts: 188
Joined: Tue Sep 17, 2013 6:50 am

Re: 10 seconds to deselect

Postby DGDanforth » Fri Feb 17, 2017 10:13 am

Josef Templ wrote:I can reproduce this behavior if the remote debugger is running,
both under Win 10 and Vista.

Did you do any experiments with RemDebug?

- Josef

Josef,
I don't know anything about a "remote debugger" or "RemDebug".
What is that?
I don't find any reference to those in the documentation.
-Doug
User avatar
DGDanforth
 
Posts: 46
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, CA, U.S.A.

Re: 10 seconds to deselect

Postby Josef Templ » Fri Feb 17, 2017 10:39 am

If you don't know RemDebug than you probably have not done any experiments with it.
It is interesting that the same behavior as you observed shows up when I use the remote debugger,
and only if I use the remote debugger.
If the observed behavior shows up in a plain vanilla installation of BlackBox, then I have no explanation.
If it shows up in you particular setting only, it may be some effect that has the same cause
as when using the remote debugger. Windows thinks that the process is not responding
(because it is in a modal mouse tracking loop) and generates some special event that causes the
observed behavior.

If you are interested in RemDebug, see the discussion on https://community.blackboxframework.org/viewtopic.php?f=32&t=150.

- Josef
Josef Templ
 
Posts: 188
Joined: Tue Sep 17, 2013 6:50 am

Re: 10 seconds to deselect

Postby Zinn » Sun Feb 19, 2017 7:06 am

It is a typical Windows 10 problem. When another program is running parallel and this program wants some inputs or attentions then the focus and selection in BlackBox is lost.
This problem does not happens with all windows programs. Some programs do and some programs don't disturb my work .
In Windows 7 the icon of the other programs blinks yellow in the task bar and don't disturb me, but in Windows 10 the program get the focus.
I have this kind of problem, when someone rings at the door.
- Helmut
Zinn
 
Posts: 57
Joined: Mon Nov 24, 2014 10:47 am

Re: 10 seconds to deselect

Postby DGDanforth » Mon Feb 20, 2017 5:51 am

Thank you Helmut.
User avatar
DGDanforth
 
Posts: 46
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, CA, U.S.A.

Re: 10 seconds to deselect

Postby Josef Templ » Mon Feb 20, 2017 10:56 am

With multiple instances of BlackBox started I can reproduce this behavior
under Win 10 and sometimes even under Vista.
No RemDebug required.

The good news: it is the same under BB 1.6, so it is not related to any change in 1.7.
The bad news: this is hard to debug because it needs a good understanding of
both the Windows Api and BB.

- Josef
Josef Templ
 
Posts: 188
Joined: Tue Sep 17, 2013 6:50 am

Re: 10 seconds to deselect

Postby Josef Templ » Tue Feb 21, 2017 1:29 pm

When Windows detects that an application is not responding it
turns the application window into a ghost window and sends a WM_CANCELMODE
message to the application and stops mouse input among other things.
Under Vista the application window title then gets the suffix "(not responding)" or similar,
I have a german Vista.
Under Win 10 I cannot see such a title suffix but the behavior is much the same.
Under Vista I can reproduce the observed behavior only when I first
set the focus to another application, e.g. the Windows explorer,
and then do the long lasting text selection.
Under Win 10 the observed behavior is easier to reproduce. It does not need to
set the focus (or active window or whatever the rule is) to another application first.
The speed of the mouse movement is not relevant, by the way, it is only the
time spent inside the mouse tracking loop, which is a modal loop in BlackBox, i.e.
it does not return until the mouse is released (same for texts and for forms).
This causes Windows to think that the application is not responding.
It is the same if a command takes a long time to finish.
Try with an endless loop for example.

I have not seen any information on how to modify this behavior.
One option would be to turn the modal mouse tracking into a
non-modal mouse tracking loop but this is a heavy change in the framework.

It is surprising that Windows thinks that the application is not responding because
inside a modal mouse tracking loop there is a lot of processing of Windows messages
by recursively calling the window's handler procedure in WinApi.PeekMessageW.

- Josef
Josef Templ
 
Posts: 188
Joined: Tue Sep 17, 2013 6:50 am

Re: 10 seconds to deselect

Postby DGDanforth » Sun Feb 26, 2017 6:30 am

Sub Styler

Windows 7 Ultimate x64
727 posts
UK



There are several keys that are responsible for the handling of unresponsive apps:

HKEY_CURRENT_USER\Control Panel\Desktop\HungAppTimeOut
HKEY_CURRENT_USER\Control Panel\Desktop\WaitToKillAppTimeOut
HKEY_CURRENT_USER\Control Panel\Desktop\WaitToKillServiceTimeOut
for your account
and
HKEY_USERS\.DEFAULT\Control Panel\Desktop\HungAppTimeOut
HKEY_USERS\.DEFAULT\Control Panel\Desktop\WaitToKillAppTimeOut
for the default account (will apply to new user accounts)

Hope this helps

EDIT: Just read about you only getting kill info, the top key should be the one your looking for.

Not sure yet if that is true for Windows 10.
User avatar
DGDanforth
 
Posts: 46
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, CA, U.S.A.

Re: 10 seconds to deselect

Postby DGDanforth » Sun Feb 26, 2017 6:44 am

When user processes (tasks) do not end (close) automatically (AutoEndTasks) at sign out, restart, or shutdown, the system waits until the process ends on it's own. If the process hasn't ended by the set HungAppTimeout value, the End Task dialog box appears, stating that the processes are not responding to the End Task request and prompts the user to either force sign out/restart/shut down and force close (end task) the non-responding processes OR to cancel sign out/shut down to return to Windows.

The HungAppTimeout value also specifies how long the system waits for user processes to end after the user clicks the End task button in Task Manager to determine whether or not the process is hung. If this HungAppTimeout threshold is exceeded, the End Task dialog box appears, stating that the process did not respond.

The HungAppTimeout value also controls the timeout for ghosting/frosting to occur.


So, that is NOT what we want.
User avatar
DGDanforth
 
Posts: 46
Joined: Tue Sep 17, 2013 1:16 am
Location: Palo Alto, CA, U.S.A.

Next

Return to GUI problems

Who is online

Users browsing this forum: No registered users and 1 guest

cron