Home Download Screenshots Wiki Plugins Translations Developers Donate Forums/Help Contact Us |
StrokeIt
Help beta test .9.7 "enhanced"Posted by jeff
@jeff:
using your version with the explicit function call seems to work correctly > ------- test.lua ------- > function test_clipboard() > require [] > local message = clipboard.get() > local params = string.format([["%s" "%s"]], > message, "Scripting Demo") > plugin.call("Utilities", "MessageBox", params) > end > > test_clipboard() > -------------------------- But when I try to use a file with a collection of different functions, like this one below, it goes nuts: --!SI:Test clipboard:test_clipboard() ... function test_clipboard() local abcd = 1234 ... end Setting the lua script command to use the file containing this function (and several others) and closing the command editor the config file sometimes shows normal: _Test [ Right ] { gesture = Right New Command = lua5.1, script "new" "PandaFunctions2.lua" "Test clipboard" "" } and sometimes part of it is a complete nonsense like this: _Test [ Right ] { gesture = Right New Command = lua5.1, script "new" "PandaFunctions2.lua" "Pbj" "123123" } and then again, sometimes it does not reflect any changes at all. I set it to use the third function but when I reopen the command editor it shows that it is still set to first/second/whatever it was previously set to. Sometimes calling the function with a gesture says that an "attempt to call a string value" was made. If the commander is not open or the focus is not on the lua command in the command editor while doing the gesture over Notepad++ window (the application to which the gesture is assigned) it does not do anything at all. It behaves unpredictably.
There's a new build with some tweaks to the keystrokes plugin, please put this through the paces. I know some testers here have had strange issues with otherwise very minor changes to this plugin. I'm looking at you, MKairys :)
Is everyone pretty happy with the enhanced version? I'd like to release this soon, so please speak up if I've not yet fixed an issue that you've reported. Thanks, Jeff
None besides that my desktop doubleclick still does not work when StrokeIt is active. But I can live with that, I got used to it :)
Oh, and one of my friend told me that he purchased a license for StrokeIt, he received a receipt after the transaction but not any kind of license information. Could you check that, please? Thanks. ps. which word did force anti-spam software to consider my message to be spam? Purchase perhaps? Or license?
@jeff,
I'd like to test the current version but my license key when I log in is blank and the license from the last version I installed is clearly not valid with this version based on the garbage it displays for the licensed user when I try it. ;) I specifically want to test to see if you ever fixed the issue using any of the mouse button or wheel gestures leaving StrokeIt in a state of flux (i.e., never resetting itself to accept more gestures afterwards until you manually disable and re-enable gesture input) since you never mentioned fixing this and as of the version I'm using (10/31/2009 build) this problem still exists.
I see I have a license key now so that's good. :) I've installed the 11/15 RC version and it appears the button / wheel gesture issue I mention is fixed; however there's another problem. ;) It appears that it doesn't matter what button you have set to activate the gesture engine and that it always uses the right mouse button. In case it matters, this is on Win7 x64 with a MS Intellimouse 3.0 (with the current IntelliPoint software installed since Windows Update was yelling at me to install it).
Sometimes StrokeIt gets stubborn and does not allow itself to be disabled. If I right-click on the icon in the systray it turns red but StrokeIt stays enabled. When I do a stroke the icon turns blue, the line is drawn, the gesture is executed and icon turns white. Now if I right-click on the icon again it remains (or turns again?) white and a second right-click is necessary to make it red again which is of no use of course, since it does not get disabled.
Disabling using a stroke has the same results except that the systray icon does not turn red at all. EDIT: So far it seems that the Disable command triggers this bug. I can disable/enable w/ right-click and it works correctly before I use the gesture to disable it. It behaves as described above and after that even the right-click method does not work anymore. Edited 1 time(s). Last edit at 11/18/2009 02:14PM by gemisigo.
Thanks, that was quick. I tried minimizing a few things. No changes so far, everything works perfectly with regular applications.
Allen mentioned something called 2nd speech something. Well, I don't have that but I tried to minimize Window's own built-in speech recognition. It was an utter failure :) It went down to the taskbar but when I clicked on it it did not restore completely. Only a small portion of the window was visible, including the closing icon. I restarted it and clicked on it on the taskbar. It did not minimize at all so I've come to conclusion that we should just accept that there are application windows that are not meant to be minimized. They just do not allow. By the way, I successfully minimized my desktop :D Now that's some crazy feature :) The background remained the same but all the icons went hiding into a small grey box that had caption. Doubleclicking it restored the desktop. I'm not sure that worked with the previous version. Never tried.
With the most recent update, StrokeIt has stopped working for me. Win 7 Ultimate RC 1 and OEM, one machine with Logitech SetPoint, the other without. I can't perform gestures and get the default OS right click + drag behavior. The tray icon doesn't change to indicate that it's picked up the mouse hook, and mhook is still there. I've tried a complete uninstall and reinstall, and no joy. Thoughts?
EDIT: This basically makes my machines unusable. I don't know yet if that's a good thing or a bad thing. :) Edited 1 time(s). Last edit at 12/01/2009 06:19AM by Scott.
There's a new build up with a couple of changes:
1) The 'alien' plugin is now included in the installer. It installs just a little bit differently than the manual instructions I posted long ago and because if this, when using it in a script you should now do: require [[alien]] instead of require [[alien\alien]] I think this should make things easier for newcomers. You may want to update any existing scripts to use the new require line. 2) The scripting language now includes a "hwnd_child" command which will return the hwnd of the child window from the point the gesture is triggered. Using this, you can use alien to call GetClassName to get the child class and then use that that class name to trigger different actions per child window. -- Jeff Edited 1 time(s). Last edit at 12/14/2009 11:00AM by jeff.
Sorry, you can't reply to this topic. It has been closed.
|