StrokesPlus Forum
                       
StrokesPlus Forum
Home | Profile | Register | Active Topics
Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 General Discussion
 You Know What Really Grinds My Gears?
 Actions occur to focused window
 New Topic  Reply to Topic
 Printer Friendly
Author  Topic Next Topic  

betty

3 Posts

Posted - 04/20/2012 :  18:10:34  Show Profile  Reply with Quote
Actions from gestures appear to happen to the currently focused window, not the one which the gesture was drawn on.

Rob

USA
2550 Posts

Posted - 04/20/2012 :  18:23:57  Show Profile  Visit Rob's Homepage  Reply with Quote
Can you give me a specific example? Including the actual Lua script and how you're experiencing the issue?

There are many ways to specify which window receives the action, but some things can require an extra action call to set focus to a background window. acSendKeys, for example, cannot send keystrokes to a window in the background as it simply tells Windows to type the keys specified. In that case, you would need to call acActivateWindow first to bring it to the foreground, then call acSendKeys.

Of course, this is just me rattling off some specific situations for others who may read this. Tell me about what exactly is happening for you? Please let me know where you're starting and ending the gesture as well. By default, most actions will send the commands to the window exactly under the mouse where the Stroke button was pressed. So if you started drawing just outside the window, but drew the entire gesture on the window you'd like to have the action performed against, it would still be directed at whichever window was under the mouse when the drawing started.
Go to Top of Page

betty

3 Posts

Posted - 04/20/2012 :  18:58:38  Show Profile  Reply with Quote
Specifically it's the action to close a tab in chrome (acSendKeys("^w")), but I notice a lot of the actions seem to have a similar issue.

I could go through and add acActivateWindow to every script, but I wonder if it should be the default. I imagine it doesn't effect that many users as they either maximize their windows or don't have multiple monitors.

For me, I have dual monitors so often find myself trying to close or perform another action on something on the other screen which isn't focused. It's a habbit I gained from many years of using strokeit, which I guess had a slightly different behaviour for its send key command.
Go to Top of Page

Rob

USA
2550 Posts

Posted - 04/20/2012 :  19:10:10  Show Profile  Visit Rob's Homepage  Reply with Quote
I can understand that. However, I designed to make S+ very granular and let the user decide what happens; I guess this is one of the instances where the downside of that presents itself. For instance, there are several actions I have which I do not want the target window brought to the foreground (I have a triple monitor setup).

Win some, lose some I suppose. But thank you for the feedback...whether it's something that is changed or not, I appreciate everyone's input. Sometimes one thing leads to a whole other tangent which gives me a really good idea on how to improve S+.
Go to Top of Page

Rob

USA
2550 Posts

Posted - 04/20/2012 :  19:25:46  Show Profile  Visit Rob's Homepage  Reply with Quote
I'll definitely poke around in the SendKeys stuff. To be honest, I just took the source from an existing CodeProject and stuck it in S+.

So yeah, to duplicate, you'd have to do something like:

local iHandle = acGetForegroundWindow()
acActivateWindow(nil, gsx, gsy)
acSendKeys("Rob sucks donkey balls for this lame send keys implementation!")
acActivateWindow(iHandle, nil, nil)

Go to Top of Page

betty

3 Posts

Posted - 04/20/2012 :  19:48:03  Show Profile  Reply with Quote
Cheers, I'll use that script for now and wait to see if you come up with anything.
Go to Top of Page

Mersine

22 Posts

Posted - 01/24/2013 :  10:18:27  Show Profile  Reply with Quote
I have triple monitors and I too would love the idea of having the action affect the application drawn on. There used to be a program that would focus and bring to front whatever window was scrolled on, but it conflicted with my ability to scroll in text boxes for some reason. It flowed better for me with one smooth gesture rather than having to click on the app. But anyway, as was said, it's a user preference.

For the most part Strokeplus already does this for me. But similar to what Betty stated, when I try a gesture to close tabs or switch between them in a browser, I have to be in the browser first.

Edited by - Mersine on 01/24/2013 10:21:26
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/24/2013 :  10:22:00  Show Profile  Visit Rob's Homepage  Reply with Quote
Don't forget you can utilize the sp_before_action function in Global Lua to always activate the window below where the gesture began:
function sp_before_action(gnm, gsx, gsy, gex, gey, gwd)
	acActivateWindow(nil, gsx, gsy)
end
It will fire before all actions (not those defined in the Hotkey tab, though)
Go to Top of Page

Mersine

22 Posts

Posted - 01/24/2013 :  10:23:57  Show Profile  Reply with Quote
My god what can't this app do. Thanks!
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/24/2013 :  10:26:14  Show Profile  Visit Rob's Homepage  Reply with Quote
Work with complex (Unicode, non-Latin) characters for strings, matching, acDisplayText unfortunately...it is the only real Achilles' heel due to my not understanding the internationalization issues when I started writing S+. To be honest, I never imagined this little project would become so popular and used around the world, lol.
Go to Top of Page

Mersine

22 Posts

Posted - 01/24/2013 :  10:28:07  Show Profile  Reply with Quote
It makes me feel like a wizard :D
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/24/2013 :  10:32:01  Show Profile  Visit Rob's Homepage  Reply with Quote
Heck, wait until you figure out that using the monitor action functions you could essentially write your own actions to duplicate what KHE Mover-Sizer is doing =)

Of course, not precisely in the sense of dragging windows, but you could make actions which do what you wanted to do with mover-sizer...Example script I use to send a window to another monitor. The possibilities are endless, really; but it's also quite a bit of script writing when mover-sizer is already meeting your needs.
Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/25/2013 :  12:18:21  Show Profile  Reply with Quote
Sometimes it won't make it active, with following code:
function sp_before_action(gnm, gsx, gsy, gex, gey, gwd, gapp, gact)
	acActivateWindow(nil, gsx, gsy,0)
end


It fires the actions on the active window and not the one that's drawn on.
Happens intermittently, not sure what's wrong.
Tried changing 0 to 1 and 2 as well.

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/25/2013 :  12:29:19  Show Profile  Visit Rob's Homepage  Reply with Quote
It can be tricky in some cases. If you happen to gesture over a control which isn't relaying the activate message up to the parent/owner or isn't a window (control) which is eligible to receive an activate message, this could happen. You may want to try something like:
acActivateWindow(acGetOwnerWindowByPoint(gsx, gsy),0,0)
This would activate the owner window, which will probably always work.

Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/25/2013 :  20:40:04  Show Profile  Reply with Quote
Still experiencing it to misfire. =/

Dragged it over Google Chrome while having mIRC active: Next tab = acSendKeys("^{TAB}")
The action caused mIRC to switch channel.


This should only fire in Google Chrome and other browsers as it's filtered with: File Name Pattern = Maxthon.exe|chrome.exe|iexplore.exe|firefox.exe
Also mirc.exe is in Ignored List.

I know it fires as it's executed over Google Chrome, like it should, but it should not take the action on mIRC. :)

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0

Edited by - Andreasvb on 01/25/2013 20:41:12
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/25/2013 :  20:43:10  Show Profile  Visit Rob's Homepage  Reply with Quote
What's the action script? So I can test.

Also, is the Chrome taskbar button flashing? As if S+ sent the focus change but Windows prevented it, only alerting you.
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/25/2013 :  20:43:52  Show Profile  Visit Rob's Homepage  Reply with Quote
Bah, I was too slow on my reply.
Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/25/2013 :  20:47:03  Show Profile  Reply with Quote
Tried some more, yes the Google Chrome button is flashing.

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/25/2013 :  20:50:19  Show Profile  Visit Rob's Homepage  Reply with Quote
Ah, yea that means Windows is denying S+ in the activate command. It's a huge pain in the ass and many others experience the issue in other programs. It's complicated and annoying. Sometimes exiting and restarting S+ can help, sometimes opening the settings window and interacting with it can help. Sometimes I've had to log off and back on. I'll have some other suggestions when I get home later.
Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/25/2013 :  21:05:32  Show Profile  Reply with Quote
Not sure if this is the same thing, but I'm using an AHK script to have the mouse scroll what's under it and not the active window, it always works.

http://www.autohotkey.com/board/topic/48426-accelerated-scrolling-script/?p=307266

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/25/2013 :  22:33:40  Show Profile  Visit Rob's Homepage  Reply with Quote
No, that's similar to StrokesPlus' Enable Mouse Wheel Relay feature, which is only forwarding mouse wheel messages to a window, not attempting to bring it to the foreground.

The issue lies with changes to Windows many years back which aimed to prevent applications from forcing another window to the foreground (think: malware continually spawning browser popup windows and bringing them to the top). Normally, this can be alleviated by calling AllowSetForegroundWindow (which S+ calls when it loads). However, there are certain restrictions which for some reason come into play sometimes, preventing S+ from being granted this privilege (see the restrictions in the link).

Because S+ is a background program which runs with a non-interactive main window (gesture draw window), sometimes Windows thinks that it's trying to gain this privilege without your knowledge/consent. For example, if I have S+ popup a message box when it starts, but before the call to AllowSetForegroundWindow, you will never experience the flashing. This is because Windows sees that you're aware this program is running and has been interacted with by you. So the subsequent call to AllowSetForegroundWindow is deemed valid and S+ is allowed to call SetForegroundWindow without any restrictions.

Believe me, you have no idea the amount of countless hours I spent trying to mitigate this annoying issue. Most of the time it's fine, but every now and then something just doesn't sit right with Windows and it determines that S+ isn't allowed to bring other windows to the foreground.

It's a very frustrating web of rules and conditions which are not always applied consistently; meaning S+ isn't doing anything differently, but Windows has simply decided it doesn't want S+ to have the ability to set the foreground window. When it happens to me, from time to time, I usually open up the S+ settings window, click OK, click another window, draw a gesture on it and everything's ok again. It doesn't happen often for me (maybe once per month), but I'm not really sure what else to try at this point...other than having a splash screen which pops up when S+ loads, so the call to AllowSetForegroundWindow occurs after you've interacted with S+. Maybe it's something I could make optional, either way it's just annoying.
Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/26/2013 :  00:34:24  Show Profile  Reply with Quote
Would it be possible to use acPostMessage instead?
A bit like:
MouseGetPos x, y, WinID, Ctrl
 PostMessage, 0x20A, WheelPace * WheelSteps * WheelDir, y << 16 | (x & 0xFFFF), %Ctrl%, ahk_id %WinID%


http://www.autohotkey.com/docs/commands/MouseGetPos.htm
http://www.autohotkey.com/docs/commands/PostMessage.htm

I've also noticed that if you right click normal on a window, not having S+ running (or on a window that's in Ignore List when it's running), it activates the window directly.

Stupid Windows. :D

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/26/2013 :  11:35:50  Show Profile  Visit Rob's Homepage  Reply with Quote
quote:
Originally posted by Andreasvb

Would it be possible to use acPostMessage instead?
A bit like:
MouseGetPos x, y, WinID, Ctrl
 PostMessage, 0x20A, WheelPace * WheelSteps * WheelDir, y << 16 | (x & 0xFFFF), %Ctrl%, ahk_id %WinID%



To do exactly what; send mouse wheel messages?
An adaptation of this for something else?
Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/26/2013 :  11:40:10  Show Profile  Reply with Quote
Yes, tried some but couldn't get it to work.

WM_ACTIVATE = 0x06
WM_MOUSEACTIVATE = 0x21
WM_LBUTTONDOWN = 0x201

Can't be that impossible. :)

What about make it active on mouse down instead of mouse up, as it is now?
Is it your invisible layer that prevents that?

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0

Edited by - Andreasvb on 01/26/2013 11:42:04
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/26/2013 :  11:45:00  Show Profile  Visit Rob's Homepage  Reply with Quote
Oh yeah, those are not fun to try and accomplish. Technically possible, but it's a big pain and often different for every app in regards to exactly which window handle is responsible for handling the message. If you use Spy++, you can certainly craft your own message by emulating the messages in the message hook...but like I said, it's pretty tedious.

Besides, even if you sent the WM_ACTIVATE message properly to the correct window handle, since S+ is the sender, it still would cause the taskbar flash if Windows has decided S+ doesn't have the privilege to bring a window to the foreground.
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/26/2013 :  11:46:26  Show Profile  Visit Rob's Homepage  Reply with Quote
I'm thinking of adding the AllowSetForegroundWindow call to occur when you click Reload Config and Lua engine from the tray icon. It might correct it since S+ will have active focus and be the last app to receive input from the user (you).
Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/26/2013 :  11:48:59  Show Profile  Reply with Quote
I never use that, but maybe have it call in sp_before_action each time, would that take too much of the processing? :P

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/26/2013 :  11:50:48  Show Profile  Visit Rob's Homepage  Reply with Quote
No, that's a Windows API call, not something available to call in a Lua script. You could technically use Alien and bind to it, but I wouldn't recommend it. Windows will probably think S+ is trying to spam the call and may treat it the same.
Go to Top of Page

Mersine

22 Posts

Posted - 01/26/2013 :  11:51:36  Show Profile  Reply with Quote
Could someone please give me a script that activates and brings to the front whatever window is under the mouse when scrolling, that would be splendid :D

The link didn't work:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632668%20v=vs.85%20.aspx
Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/26/2013 :  11:51:39  Show Profile  Reply with Quote
I meant the reload thing.

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0
Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/26/2013 :  11:53:38  Show Profile  Reply with Quote
quote:
Originally posted by Mersine
The link didn't work:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632668%20v=vs.85%20.aspx


It removed ( ).

Try this one.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632668

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0
Go to Top of Page

Mersine

22 Posts

Posted - 01/26/2013 :  11:58:01  Show Profile  Reply with Quote
Thanks. A program that does what I'm looking for: http://vb.mvps.org/tools/Wheeler/
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/26/2013 :  11:58:30  Show Profile  Visit Rob's Homepage  Reply with Quote
I have to rebuild S+ with that code and release it. I'm out for the day, will do later.
Go to Top of Page

Andreasvb

Sweden
46 Posts

Posted - 01/26/2013 :  11:59:37  Show Profile  Reply with Quote
Thanks for trying, Rob. ^^

Windows 8.1u3 Pro x64 Media Center / Portable StrokesPlus 2.8.2.0
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/26/2013 :  13:28:44  Show Profile  Visit Rob's Homepage  Reply with Quote
Mersine, that code is built into the mouse hook, so there's no script that can be fired for the mouse wheel relay functionality. I'll look at the code and maybe add something which can be set to activate the owner window (if not active) on mouse wheel forwarding events.
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/26/2013 :  22:43:11  Show Profile  Visit Rob's Homepage  Reply with Quote
Ok, 2.5.8 has an undocumented action function which allows you to tell S+ to always activate the window below the mouse cursor when Enable Mouse Wheel Relay is active. It's undocumented for now because I'm not sure if it will work well or not, so do let me know.

Basically, add this to your Global Lua to turn the setting on when you start S+ or click Apply/OK in the Settings window:
function sp_init()
	acActivateWindowUnderMouseWheel(1)
end
This will set that option as ON; call with 0 to turn that feature off:
acActivateWindowUnderMouseWheel(0)
Of course, that action can be called from any gesture/hotkey script as well, if you wanted to define actions to turn the feature on or off.

Also, when you click Reload Config and Lua Engine from the tray icon menu, S+ will call the AllowSetForegroundWindow Windows API function. This will hopefully correct a situation when Windows isn't allowing S+ to bring other windows to the foreground (the taskbar flashes instead of activating the window). This may or may not have any effect, but won't harm anything.
Go to Top of Page

Mersine

22 Posts

Posted - 01/29/2013 :  10:10:15  Show Profile  Reply with Quote
Hi Rob, is there a way to disable the taskbar flash?
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/29/2013 :  10:13:18  Show Profile  Visit Rob's Homepage  Reply with Quote
That's not StrokesPlus' doing, it's Windows deciding that S+ doesn't have the privilege to activate other windows (see above for my detailed explanation).

Try clicking Reload Config and Lua Engine from the tray menu and let me know if it fixes anything. As I said before, it's really quite an annoying issue since it's Windows who is deciding it doesn't want to let S+ activate other windows, even though S+ makes the appropriate API call..
Go to Top of Page

Mersine

22 Posts

Posted - 01/29/2013 :  10:14:12  Show Profile  Reply with Quote
Gotcha, thanks. I got a little confused up there hehe.
Go to Top of Page

Rob

USA
2550 Posts

Posted - 01/29/2013 :  10:31:16  Show Profile  Visit Rob's Homepage  Reply with Quote
Also, open your StrokesPlus.XML file and change:
<CheckForegroundTimeout>0</CheckForegroundTimeout>
To:
<CheckForegroundTimeout>1</CheckForegroundTimeout>
I had some code to update Windows' setting for foreground timeout (which applies to this issue) but haven't had that value turned on in the default configuration since I didn't want to override users' settings. But you can give it a try and see if it works (you'll have to exit S+ completely, change the setting, and re-open).

Let me know.

Note that it changes the setting system-wide, so other apps would be able to bring windows to the foreground (which is why I didn't want to leave it on by default); I completely forgot that setting even existed =)
Go to Top of Page

Mersine

22 Posts

Posted - 01/29/2013 :  10:42:19  Show Profile  Reply with Quote
Thanks I'll give it a try.
Go to Top of Page

anjan_oleti

22 Posts

Posted - 04/06/2016 :  03:07:10  Show Profile  Reply with Quote
quote:
Originally posted by Rob

Don't forget you can utilize the sp_before_action function in Global Lua to always activate the window below where the gesture began:
function sp_before_action(gnm, gsx, gsy, gex, gey, gwd)
	acActivateWindow(nil, gsx, gsy)
end
It will fire before all actions (not those defined in the Hotkey tab, though)


This worked, but unfortunately broke something else.
This code added, does not let S+ work in dialog boxes of apps. For instance, the gesture to 'Paste' does not work in the text field in the 'Save As' dialog of Notepad. With this option removed it works fine.

Is there any workaround?
Fwiw, there was no such problem in StrokeIt.

Edited by - anjan_oleti on 04/06/2016 06:04:59
Go to Top of Page

Rob

USA
2550 Posts

Posted - 04/06/2016 :  07:57:31  Show Profile  Visit Rob's Homepage  Reply with Quote
I'm pretty sure it's because, if you don't pass in a window handle (using gsx, gsy coordinates instead), acAcivateWindow internally calls GetAncestor using the GA_ROOTOWNER flag. Which tells Windows to get the top-most ultimate owner of the window and calls SetForegroundWindow().

Now that's fine when a program uses something like ShowDialog() which makes a new popup window modal and forces focus to it. However, Windows dialogs like Open/Save/Print/Color Picker are a little different in that they don't actually belong to the application, but to Explorer.exe.

So acActivateWindow finds the main Notepad window and activates it instead of the Save As dialog, because it kind of bypasses the Windows dialog that is technically modal for the app.

You can try something like this and see how it works for you, though it may not be perfect. I tried it on my machine and if the Save As dialog for Notepad was open and active, it worked fine. It also worked to activate the Save As dialog if another app had focus and I drew the gesture over the Save As window. The class "#32770" commonly represents desktop/explorer style dialogs/windows.
local className = acGetClassName(acGetParentWindowByPoint(gsx, gsy), nil, nil)
if className == "#32770" then
	acActivateWindow(acGetParentWindowByPoint(gsx, gsy), nil, nil)
else
	acActivateWindow(nil, gsx, gsy)
end
Go to Top of Page

anjan_oleti

22 Posts

Posted - 04/06/2016 :  10:54:13  Show Profile  Reply with Quote
Great. It works now. Thanks Rob :)
I am experiencing the same issue discussed above.. the intermittent flashing and misfiring thing.
What is the workaround for that? ..couldn't figure it out properly from the discussion.

I don't mind a splash screen. I checked the preferences and found no option to enable it.

Edited by - anjan_oleti on 04/06/2016 11:07:02
Go to Top of Page

Rob

USA
2550 Posts

Posted - 04/06/2016 :  23:41:50  Show Profile  Visit Rob's Homepage  Reply with Quote
I'll be putting some extra effort into addressing that in the new version. For reference of how ridiculously difficult and cryptic it is, do a Google search for something like "SetForegroundWindow isn't working", add in "flashing". There are countless threads about it, ever since the days of Windows 95 and the annoying apps/popups of the 1990's that would continually make themselves the top window, trapping you, Microsoft understandably made it far more challenging.
Go to Top of Page

anjan_oleti

22 Posts

Posted - 04/07/2016 :  00:15:28  Show Profile  Reply with Quote
But, is there some other way of implementing it, because Strokeit works that way out of the box. There was never any issue. May be, there is some other trick to get it to work. Just guessing :)

Edited by - anjan_oleti on 04/07/2016 00:27:40
Go to Top of Page

Rob

USA
2550 Posts

Posted - 04/07/2016 :  00:18:42  Show Profile  Visit Rob's Homepage  Reply with Quote
I had times where StrokeIt would cause flashing Taskbar buttons instead of existing the window, but not often and was a long time ago!
Go to Top of Page

anjan_oleti

22 Posts

Posted - 04/07/2016 :  00:28:21  Show Profile  Reply with Quote
Oh.. okay
Go to Top of Page

anjan_oleti

22 Posts

Posted - 04/19/2016 :  02:05:48  Show Profile  Reply with Quote
Following is a solution for this issue, posted in AHK forum..
quote:
So for those having a similar "driving me crazy" problem, this may help you as it did me:

My amended code:

IfWinExist, ahk_class <Obtained_via_WindowSpy>
{
WinGet, hWnd, ID, ahk_class <Obtained_via_WindowSpy>
DllCall("SetForegroundWindow", UInt, hWnd)

;WinActivate
Send {Tab}
Sleep 5000
}
Link: https://autohotkey.com/board/topic/63227-winactivate-why-so-flakey/

I've been trying to trigger a AHK script in the global lua, with the window handle as parameter.
This is the best I could come up with
function sp_before_action(gnm, gsx, gsy, gex, gey, gwd, gapp, gact, gbl, gbt, gbr, gbb)
local winact = acGetWindowByPoint(gsx, gsy)
acShellExecute("open", "E:\\Zata\\Axem\\StrokesPlus\\Activate.ahk", "winact", "", 1)
End
It is incorrect. Pls help me amend it :)

Edited by - anjan_oleti on 04/19/2016 02:14:40
Go to Top of Page
   Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
StrokesPlus Forum © 2011-2018 Rob Yapchanyk Go To Top Of Page
Snitz Forums 2000