| Author |
 Topic  |
|
|
fug
USA
11 Posts |
 Posted - 01/13/2012 : 11:01:52
|
Rob,
It's not working as expected, at least not as I expected it to...
I added
<MouseWheelFocus>1</MouseWheelFocus>
to config.settings, and reloaded the config. I opened an explorer window, found a folder with lots of subfolders, clicked on the desktop background to remove the focus from the explorer window, and when I hovered over the explorer window and rolled the scroll wheel, -occasionally- the window would receive focus, but the contents would not scroll, at least not reliably. Yes, I did kill the other utility first.
I removed the line from config...
The 64 bit install went where it should, in the Program Files directory.
Thanks for this.... The gestures part works flawlessly.
fug |
|
|
Rob
USA
2615 Posts |
Posted - 01/13/2012 : 11:57:02
|
Ah, yea this would only work within the active window, not activate the owner window first. I wasn't sure exactly what you were looking for. However, in looking into this more, I've figured out what I was doing wrong before.
Download 1.2.5 and let me know how it works for you. I must say, I like the functionality quite a bit =) |
 |
|
|
Rob
USA
2615 Posts |
Posted - 01/14/2012 : 03:45:17
|
| I can't believe I've made it this far in life without having this scroll inactive panes/windows functionality, heh. |
|
|
|
fug
USA
11 Posts |
Posted - 01/14/2012 : 07:03:37
|
Good job, Rob!
(so much for version 1.23, eh?)
I uninstalled WizMouse, the utility I had been using to control the scroll.
S+ is turning into an indispensable utility.
I will continue testing, but so far, so good!
Maybe you should change the name to StrokeScrollPlus. ;-)
Thanks.
|
|
|
|
fug
USA
11 Posts |
Posted - 01/14/2012 : 07:23:15
|
Seems to work well in an XP VM, too.
Awesome.
|
|
|
|
Rob
USA
2615 Posts |
Posted - 01/14/2012 : 07:35:48
|
| I aims to please! |
|
|
|
fug
USA
11 Posts |
Posted - 01/14/2012 : 08:08:31
|
Not to be greedy or anything..... and maybe this isn't even possible and I'm showing my ignorance by even asking....
Most apps scroll jerkily, many three lines at a time. This is not at all a function of S+, but simply the way most windows apps scroll by default. For some apps, (Firefox and Thunderbird come to mind) you can download plugins that will greatly smooth out mousewheel scrolling, making it easier on the eyes.
Is it possible to implement in S+ some sort of global scroll control to smooth out scrolling in general?
Hey, if you don't ask, you'll never know. |
|
|
|
Rob
USA
2615 Posts |
Posted - 01/14/2012 : 09:08:35
|
Not sure about that one, I think they hook into the view control and handle the scrolling directly where I'm just forwarding a wheel message.
Of course, I'll see if there's anything I can find out; always up for a challenge! |
|
|
|
Rob
USA
2615 Posts |
Posted - 01/14/2012 : 11:47:24
|
| No luck on that one, it will somewhat work for some controls, be ignored by others entirely, or just scroll the same as normal. It's all up to the application in how it handles the messages, I tried sending smaller delta values (even 1) in a loop to the incoming delta. Very inconsistent behavior, sometimes Windows would get fed up with my spamming mousewheel and stop S+ from broadcasting it, LOL. |
|
|
|
fug
USA
11 Posts |
Posted - 01/14/2012 : 11:59:05
|
I about figured as much, but thanks for trying. I wonder why MS made the default scroll jerky? Seems like it should be a built in customization option, like animated menus, etc.
|
|
|
|
Rob
USA
2615 Posts |
Posted - 01/14/2012 : 12:06:20
|
Apparently, and I've read it numerous times, they intentionally made the mouse wheel delta ticks to be 120/per to allow for more granular control by future hardware, however, the responsibility lies in the application to handle the delta how it sees fit. But to your point, you'd think that if nothing else Windows Explorer would handle it in a smoothing fashion. But nope, when I sent < 120 delta ticks to the left pane (drives, etc) of Explorer, it disregarded the message entirely.
However, to play devil's advocate, I'd defend Microsoft's decision to move in large sections instantly for performance reasons; it's very CPU-intensive to scroll/update the window dozens of times for one tick of the wheel...and let's face it, they've historically had plenty of complaints in the speed and responsiveness department. |
|
|
|
peterallcdn
4 Posts |
Posted - 06/04/2014 : 13:45:42
|
First off, thanks for the great software! I've been using mouse gestures in firefox for ages, can't believe it took me this long to think of googling mouse gestures for windows. Life's about to get a little sweeter... and a lot simpler! :)
So, like a previous poster, I too have been using WizMouse to scroll inactive windows. Not sure how anyone does serious work on a computer without this feature!!! So needless to say, I was quite happy to see that StrokesPlus offered similar functionality. However, whenever I scroll over a window, 99% of the time I want to actually work in that window. I don't think I saw the option for this in StrokesPlus preferences, but could we please get the option to activate/bring-to-foreground whichever window we're scrolling over, rather than leaving that window inactive? If StrokesPlus offered this, I could then remove WizMouse and have one less utility running in the background. :D
Thanks again! |
|
|
|
Rob
USA
2615 Posts |
Posted - 06/04/2014 : 14:41:37
|
If you uncheck Enable Mouse Wheel Relay* and enable the Allow Mouse Wheel Tick Script* option, you can use this script in Global Lua to essentially do what you're looking for:function sp_wheel_tick(control, wParam, lParam, x, y, delta)
local exe = acGetExecutableName(control, nil, nil) --get the name of the EXE which owns the control the mouse is above
local owner = acGetOwnerWindowByPoint(x, y) --get the owner window of the control
local foreground = acGetForegroundWindow() --get the handle to the foreground window
if foreground ~= owner and --Foreground window is not the owner
(
acGetExecutableName(foreground) ~= exe --If the EXE for the control and foreground do not match
or ( --or the mouse is outside the window [when there are two instances of an EXE running]
x > acGetWindowRight(foreground)
or x < acGetWindowLeft(foreground)
or y < acGetWindowTop(foreground)
or y > acGetWindowBottom(foreground)
)
)
then
acActivateWindow(owner) --activate the window below the mouse
end
--pass mouse wheel message to the control
acPostMessage(control, 0x020A, wParam, lParam)
end The whole double-checking the EXE in addition to the foreground vs. owner window logic is simply to mitigate some odd behavior with popup lists in Chrome (and likely other applications). Essentially, a popup menu/dropdown list/etc. technically becomes the foreground window when it's active, so it doesn't actually match the window handle of the owner, so without that check, you can't scroll a dropdown list because the script would keep activating the main application window, which causes the dropdown list to lose focus and disappear. It's kind of a difficult problem...so this handles that scenario. However, since it's checking the EXE name, there's the additional check of coordinates so if the mouse is outside of the bounds of the foreground window, but the EXE is the same name, there must be another instance of the EXE running which the mouse is over, so activate the other window.
I know, it's rather complicated and very annoying to build scripts to account for all of this nonsense!  |
|
|
|
peterallcdn
4 Posts |
Posted - 06/04/2014 : 16:39:43
|
I think that did the trick, fantastic! :) Complicated is correct. haha I certainly would never have been able to put that together myself so thanks for sharing all the code required.
That makes me think. I read on here that you were looking for ideas for v3.0 of your software. Since I'm assuming the current version can already do almost everything you want it to, maybe you could focus on making v3.0 more approachable and easier for newbies? For example...
- Turning as many scripts as you can, like the one you just shared, into options people can turn off and on in preferences. (Ooo, like an option to apply gestures to any window beneath the mouse by default. Right now I'm adding "acActivateWindow(nil, gsx, gsy)" to almost all my actions which seems repetitive.)
- Maybe introduce some wizards that users can walk through to create actions and in turn code the user can learn from. That's how I first learned HTML, from a WYSIWYG editor's outputted code.
- I didn't know any of the special characters to represent CTRL, ALT, SHIFT etc, so maybe you could provide a field(part of a wizard?) where the user can actually type the keyboard shortcut they want and have it translated into the proper Lua/StrokesPlus code.
- Maybe divide StrokesPlus into 2 sections, Basic and Advanced. Basic, possibly a wizard, would focus on likely the most common use(s)... Which Keyboard Shortcut -> Which Gesture -> Which App/Window.(I know that'd cover 95% of my intended use of StrokesPlus) Advanced section would be anything beyond that.
I know you must get a lot of your job satisfaction from people actually using your software, so the easier it is to use the more likely people are to use it. :)
Just a thought. :) I've only been using your software for 24 hours, so my viewpoint is likely that of someone facing a learning curve. haha
Thanks again!!
Peter |
|
|
|
Rob
USA
2615 Posts |
Posted - 06/04/2014 : 16:55:40
|
(Ooo, like an option to apply gestures to any window beneath the mouse by default. Right now I'm adding "acActivateWindow(nil, gsx, gsy)" to almost all my actions which seems repetitive.)
You can leverage the sp_before_action function (in Global Lua)to do this for all actions:
function sp_before_action(gnm, gsx, gsy, gex, gey, gwd, gapp, gact)
-- this code is fired before each action (excluding hotkey actions)
acActivateWindow(nil, gsx, gsy)
end
Additionally, you can create your own functions in Global Lua which can always be called from Actions, to eliminate repetition.
--
Yes, the learning curve is rather steep, I wrote S+ as a power user with other power users in mind.
Usability is oft requested and I completely understand, even agree. However, to make things very user-friendly is simply extremely time-consuming for what is, in reality, very little gain. Bear in mind that I developed S+ on my own time and I don't exactly have a lot of it to spare. Couple that with the fact that S+ is written in C/C++ without any fancy frameworks (to keep S+ lightweight/fast/small footprint) to make pretty interfaces and it further increases the amount of development effort required for doing seemingly simple things.
Yea, I know it sounds like a cop-out, and I'm sure to a degree that's true. In the end, I've spent an inordinate amount of personal time developing S+ to where it is today, and not really made very much money to justify spending twice that time making it pretty and full of nice features. Sure, I could charge for it, but I don't really want to be on the hook to have to provide support, etc. to paying customers; sometimes I don't do anything with S+ for months at a time and I don't feel guilty because it's free.
As I said, I completely hear where you're coming from and generally agree with these suggestions, but like anything, the devil is in the details...and making a very user-friendly and intuitive program is very time-consuming. So I choose function over form as the most productive use of my limited personal time devoted to S+.
|
|
|
|
peterallcdn
4 Posts |
Posted - 06/04/2014 : 17:33:47
|
That's not a cop-out at all, your software is free so you don't owe anyone anything. :)
I was just throwing that stuff out there from a newbies perspective, completely understand that you don't have the time or that you believe your time is better spent elsewhere. Thanks to the gestures that were included and the good documentation, I've already learned how to get StrokePlus to do what I need, so I should be good. haha And the one or two things I've had trouble with, you and this forum took care of those. So thanks!
Oh, one last thought that popped into my head while I have you on the line... What about an overlay or audio clip that is triggered on a per-action basis to confirm to the user which action was recognized? So for example, the user could assign a different audio clip for each action which would be played whenever that action has been attempted/identified? Also, when attempting a gesture, what if a small box briefly appeared in a corner of the screen/app that displayed the name of the action and keyboard shortcut if any? Sometimes it could be helpful for the user to get such feedback should they get confused on which gesture does what and wonder why something's not happening. Again, not urgent, just something if you're bored on a rainy day. :D |
|
|
|
Rob
USA
2615 Posts |
Posted - 06/05/2014 : 00:24:42
|
| You could certainly use the sp_after_action script (Allow After Script..or something like that) and set up some case statements to play certain sounds based on the name of the action/app passed in. You could also popup a balloon in the tray with the name of the action. On my Chromebook, so I can't try anything to give as a sample =) |
|
|
| |
Topic |
|
|
|
MouseWheelFocus
Forum Locked
