| Author |
 Topic  |
|
|
ready300
8 Posts |
 Posted - 11/19/2013 : 11:35:26
|
Scrolling gestures stop working after a while. Other gestures work. I have to reload s+ to get scrolling actions to catch again.
Thank you for the help. |
|
|
Rob
USA
2615 Posts |
Posted - 11/19/2013 : 13:17:58
|
I'm able to create a scenario where certain aspects of the gesture are reset, thus causing the wrong set to be executed, but only if I scroll the mouse wheel very fast.
Although, I cannot get it to stop recognizing scroll gestures altogether, only for that set until I release the stroke button.
Is it easy for you to reproduce? If so, can you try to only scroll slowly, basically allowing each scroll tick to fully execute the action before another scroll tick occurs, and see if the problem still happens?
I'm still trying to figure out and fix the issue I mentioned above, but I'm wondering if it's somehow related or if your issue is completely separate. |
 |
|
|
ready300
8 Posts |
Posted - 11/20/2013 : 08:17:30
|
I think another program was conflicting -- I turned off the other program (AltDrag) and now it seems to catch the scroll more regularly.
BUT here is another problem:
when trying to scroll through open applications using the code on this site, sometimes the scroll only makes the taskbar buttons flash, and does not scroll the windows themselves. It gets stuck only causing the flash of the taskbar buttons and doesn't scroll the windows. How can I fix this?
Here is the local code I use for scrolling down:
--------------------------------------------------------
-- Scroll Down Action:
--------------------------------------------------------
if bTaskMode == 0 then
bTaskMode = 1
acGetAllWindows(1)
for num, handle in pairs(sp_all_windows) do
iTaskCount = iTaskCount + 1
end
end
local iStartingPosition = iTaskPosition
::top2::
iTaskPosition = iTaskPosition + 1
if iTaskPosition >= iTaskCount then
iTaskPosition = 0
end
--get the window class to test for excluded windows
local sClass = acGetClassName(sp_all_windows[iTaskPosition],0,0)
--exclude these windows
if sClass ~= "SearchPane" and sClass ~= "Shell_CharmWindow"
and sClass ~= "ImmersiveLauncher" and sClass ~= "Snapped Desktop"
and sClass ~= "ImmersiveBackgroundWindow"
and sClass ~= "NativeHWNDHost"
and sClass ~= "MetroGhostWindow" then
--if the window is minimized, restore it
if aIsIconic(sp_all_windows[iTaskPosition]) ~= 0 then
acRestoreWindow(sp_all_windows[iTaskPosition])
end
--activate the window
acActivateWindow(sp_all_windows[iTaskPosition])
else
--the line below ensures the script won't get
--stuck in a recursive loop
--if there are only excluded windows present
if iTaskPosition ~= iStartingPosition then
goto top2
end
end |
|
|
|
Rob
USA
2615 Posts |
Posted - 11/20/2013 : 09:02:14
|
I've dedicated a few posts about that behavior; it has less to do with S+ and more to do with the way Windows now operates (bringing windows to the foreground used to happen without flashing, but then rogue applications would abuse it, so MS changed the behavior).
One step which seems to work without error for me is to update your StrokesPlus.xml file and change the value below from 0 to 1:
<CheckForegroundTimeout>1</CheckForegroundTimeout>
Normally, S+ updates the setting automatically, however there's a trick to this behavior, the primary being that Windows likes the window asking to change the timeout setting (and request permission to change focus) to ideally be the foreground window to ensure that the user has actually seen the application and is aware of its existence (to thwart malware). Updating that setting simply causes S+ to check the setting and popup a message box asking if you want to update the setting. The fact that the message box pops up (and makes S+ the foreground window) seems to make the request more likely to succeed. However, it will almost always popup whenever you start S+, so it can annoy people, which is why I have it turned off in the default configuration; I always leave it on and I never have flashing taskbar buttons.
Here are two other posts where this overall behavior is discussed:
http://www.strokesplus.com/forum/topic/115/dyk-setting-focus-to-other-windows
http://www.strokesplus.com/forum/topic/646/flashing-taskbar
It's always worth a forum search, often times many people have encountered the same issue. I usually just provide the links and explain anyway as I don't want to be the "USE THE SEARCH!!1!" guy  |
|
|
|
ready300
8 Posts |
Posted - 11/20/2013 : 20:46:23
|
| Thanks, Rob. I didn't see the search function before. I appreciate it. |
|
|
|
ready300
8 Posts |
Posted - 11/21/2013 : 13:08:25
|
I tried changing the xml file, but I still have the same problem. In fact, scrolling works less well after changing. I have not been able to use the signed or installed version and tried the xml change a couple times. Any other thoughts? Thanks again, Rob.
quote:
Originally posted by Rob
I've dedicated a few posts about that behavior; it has less to do with S+ and more to do with the way Windows now operates (bringing windows to the foreground used to happen without flashing, but then rogue applications would abuse it, so MS changed the behavior).
One step which seems to work without error for me is to update your StrokesPlus.xml file and change the value below from 0 to 1:
<CheckForegroundTimeout>1</CheckForegroundTimeout>
Normally, S+ updates the setting automatically, however there's a trick to this behavior, the primary being that Windows likes the window asking to change the timeout setting (and request permission to change focus) to ideally be the foreground window to ensure that the user has actually seen the application and is aware of its existence (to thwart malware). Updating that setting simply causes S+ to check the setting and popup a message box asking if you want to update the setting. The fact that the message box pops up (and makes S+ the foreground window) seems to make the request more likely to succeed. However, it will almost always popup whenever you start S+, so it can annoy people, which is why I have it turned off in the default configuration; I always leave it on and I never have flashing taskbar buttons.
Here are two other posts where this overall behavior is discussed:
http://www.strokesplus.com/forum/topic/115/dyk-setting-focus-to-other-windows
http://www.strokesplus.com/forum/topic/646/flashing-taskbar
It's always worth a forum search, often times many people have encountered the same issue. I usually just provide the links and explain anyway as I don't want to be the "USE THE SEARCH!!1!" guy
|
|
|
|
Rob
USA
2615 Posts |
Posted - 11/21/2013 : 14:24:53
|
| Nothing else I can think of...make sure you've rebooted as well (leaving the setting on); I recall Windows (seemingly) remembering that S+ was spamming the focus calls without permission and wouldn't honor the calls to allow bringing windows to the foreground. |
|
|
| |
Topic |
|
|
|
scroll stops working after time
Forum Locked
