| Author |
 Topic  |
|
|
Rob
USA
2615 Posts |
 Posted - 07/01/2012 : 13:54:02
|
32-bit:
Portable/ZIP Download - Full Application:
http://www.strokesplus.com/files/StrokesPlus_2.1.2_x86.zip
Portable/ZIP Download - Changed Files Only:
http://www.strokesplus.com/files/StrokesPlus_2.1.2_x86_chg.zip
Setup Package Download:
http://www.strokesplus.com/files/StrokesPlus_2.1.2_x86.msi
(simple install; creates program group with shortcuts to StrokesPlus and Help page)
64-bit:
Portable/ZIP Download - Full Application:
http://www.strokesplus.com/files/StrokesPlus_2.1.2_x64.zip
Portable/ZIP Download - Changed Files Only:
http://www.strokesplus.com/files/StrokesPlus_2.1.2_x64_chg.zip
Setup Package Download:
http://www.strokesplus.com/files/StrokesPlus_2.1.2_x64.msi
(simple install; creates program group with shortcuts to StrokesPlus and Help page)
Change Log:
- Moved the clear vars check back to its original location as it didn't correct the issue I was hoping, and caused another problem where S+ stopped capturing modifiers or drawing
- Changed the way acDisplayText works, instead of creating and destroying a full screen window each time, one is created at startup and left in place, showing/hiding as necessary. This also allows a subsequent calls to acDisplayText to replace the displayed text. However, a new call to acDisplayText while one is already displays immediately replaces the existing text, regardless of the previous call's display duration. If you want to display a message, followed by another in the same action, you would need to add a call to acDelay(ms) to pause the action so the next call to acDisplayText doesn't replace the previous one until you'd like it to. Although, any other action that calls acDisplayText during this pause would still replace the text..this is about the best I'm willing to do with this at the moment..I can't imagine it would cause a problem for anyone, especially considering acDisplayText is more flexible now. Therefore, the Lua script immediately following the call to acDisplayText is no longer on hold until the text duration has passed, it executes immediately; so if you want the delay, you'll need to add a call to acDelay(ms). |
|
|
cyberalex4life
53 Posts |
Posted - 07/01/2012 : 14:48:36
|
the problem with acActivateWindow(nil, gsx, gsy), if there is a problem, is that on desktop it doesn't activate any window on any first gesture containing it. First, it sends the gesture to desktop window, then it selects the window on which I want to perform the gesture and after that, the second gesture performed on window works fine...
|
 |
|
|
Rob
USA
2615 Posts |
Posted - 07/01/2012 : 14:59:07
|
This release did not addressing anything with your complaint.
I simply cannot reproduce the problem. I have this action, and it works every time; whether the window is active or not.
acActivateWindow(nil,gsx, gsy)
acMaximizeOrRestoreWindow(nil,gsx, gsy)
If you try an older version, does it work fine? At what point did this stop working? |
|
|
|
cyberalex4life
53 Posts |
Posted - 07/01/2012 : 15:06:14
|
actualy my actions look like
acActivateWindow(nil, gsx, gsy)
acSendKeys("{BACKSPACE}")
and that happens mostly when I draw the gesture fast and/or small.
With the risk of saying something stupid your action works fine on my pc with just like this
acMaximizeOrRestoreWindow(nil, gsx, gsy)
no need for acActivateWindow(nil, gsx, gsy) with those predefined actions... |
|
|
|
Rob
USA
2615 Posts |
Posted - 07/01/2012 : 15:15:38
|
No, you don't need to activate the window to maximize it, but I prefer to have it activated in case my next gesture uses keys or something.
I tried your action:
acActivateWindow(nil, gsx, gsy)
acSendKeys("{BACKSPACE}")
..and it activates the window, then sends the Backspace key without a problem.
If you notice that the taskbar button for the application is flashing (instead of becoming activated), there's really nothing I can do about that other than say to logoff Windows and log back on. Bringing windows to the foreground is very touchy since Windows Vista, and I've done all the calls that I'm supposed to, but sometimes, Windows simply stops letting S+ bring windows to the foreground. If that happens, I have to logoff and log back in to reset Windows.
I spent a ridiculous amount of time trying to make that work perfectly, but it appears Windows sometimes behaves erratically regarding those calls. |
|
|
|
cyberalex4life
53 Posts |
Posted - 07/01/2012 : 15:51:32
|
Yeah, the thing that annoyes me most is when I sent Alt + F4, as acCloseApplication(nil, gsx, gsy)
is much too brutal for some applications.
I have another gesture for it too.
The thing that I am experiencing with
acActivateWindow(nil, gsx, gsy)
acSendKeys("%{F_4}")
is that the window above another window seems like having an aura, and despite the thing that I draw the gesture on window bellow, it still closes the window at foreground first if the gesture is very close to it, instead of the one I want to. But, like I said, I use a mouse click for selecting that window. It's very sharp this way |
|
|
|
Rob
USA
2615 Posts |
Posted - 07/04/2012 : 14:44:55
|
| Bump to fix version order. |
|
|
| |
Topic |
|
|
|
Version 2.1.2 (32-bit and 64-bit)
Forum Locked
Topic Locked
