Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upUnable to cancel SendMessage when switching apps in some cases #3825
Comments
This comment has been minimized.
This comment has been minimized.
|
Comment 2 by jteh on 2014-01-29 04:43 |
This comment has been minimized.
This comment has been minimized.
|
Comment 3 by James Teh <jamie@... on 2014-01-29 04:44
Changes:
|
This comment has been minimized.
This comment has been minimized.
|
Comment 4 by James Teh <jamie@... on 2014-01-31 08:02
|
This comment has been minimized.
This comment has been minimized.
|
Comment 5 by James Teh <jamie@... on 2014-02-03 10:39
|
This comment has been minimized.
This comment has been minimized.
|
Comment 6 by jteh on 2014-02-04 04:45 |
This comment has been minimized.
This comment has been minimized.
|
Comment 7 by James Teh <jamie@... on 2014-02-04 05:54
|
This comment has been minimized.
This comment has been minimized.
|
Comment 9 by James Teh <jamie@... on 2014-02-10 08:57
|
This comment has been minimized.
This comment has been minimized.
|
Comment 10 by James Teh <jamie@... on 2014-02-11 06:12
|
This comment has been minimized.
This comment has been minimized.
|
Comment 11 by James Teh <jamie@... on 2014-05-01 06:24
Changes:
|
This comment has been minimized.
This comment has been minimized.
|
Comment 12 by jteh on 2014-05-01 06:25 |
nvaccessAuto commentedJan 28, 2014
Reported by jteh on 2014-01-28 08:57
We hook SendMessage and SendMessageTimeout so that we can cancel them from watchdog. The hook uses SendMessageTimeout in a loop with a pretty short timeout. Unfortunately, it seems that SendMessageTimeout blocks until the window responds when switching apps in some cases, regardless of the timeout. SMTO_BLOCK fixes this, but it also breaks PowerPoint (#2900). I guess it gets stuck handling some sort of nonqueued message, but I can't see that in the stack.
Str:
Watchdog can't recover from this freeze, no matter how hard it tries.
We can get around this by running SendMessageTimeout in a background thread.
Blocked by #3801, #3859