Help beta test .9.7 "enhanced"

I found the reference to gesture.hwnd() the mouse buttons do not show in the dropdown. Why is that?

Next question :)
In the lua scripts there are references to plugins and function calls like :
"plugin.call("Utilities", "delay", "1")"
I suppose these call exported functions of the dlls in the plugins directory. Is there a way to call exported functions of other dlls directly, or it is only possible if they are included as a plugin? If so, then how do I create a plugin?
Simply putting the dll file into plugins directory does not work (well, I did not await it would anyway :) ) It complains about the plugin is lacking the Init and Quit functions. What do they have to contain to work properly? Is there anything that has to be explicitly initiated and finalized if my plugin/dll does nothing special require acquiring/releasing memory, etc.?

The file I get is StrokeIt_0.9.6-Full_Demo-140709.exe. No extra buttons, no gesture.hwnd() in example.lua.

I tried emptying my browser cache and re-downloading...

Okay, you guys were right :) I've got it all sorted out now and the "real" build is finally up there.

@gemisgo - you can see information on creating strokeit plugins [url=http://www.tcbmi.com/strokeit/develop.shtml]here[/url] Or you can use the alien lua plugin to call non-strokeit dlls directly. The example script demonstrates this usage and there are directions for installing alien earlier in this thread.

The crash issue refuses to die. :P http://www.pobox.com/~googer/tcb.zip - updated with a new crash dump once again. :)

On the plus side, the 4th and 5th mouse button support works great and is a feature I'd long awaited (and forgotten about even since I'd given up on it, lol). Now I just need to see how long retraining my muscle memory for gestures takes since I in theory do prefer to keep the primary mouse buttons completely free while having my gestures. :D

The extra mouse buttons are now available in the dropdown, alas, they do not work. The logitech driver might interfere somehow. I don't mind, I would not be able to use them anyway. Using it with RMB is way too deeply hardwired into my brain to change d:)

As for the plugins the SDK seems interesting though I would not say it is very simple for novices. So far I think I'll end up with alien calling dlls directly (even if alien is a bit "alien" at first sight :)
Making a plugin would take more time and I'm not in the mood for creating even a minimum GUI for it. My goal is very simple and I'm not planning (at the moment) to make it customizable. Maybe some time later...

Jeff, is there any way I could help you find out or find out myself why does StrokeIt "disable" the left doubleclick on the desktop? This is a feature I use (or rather used ) very often. Versions prior the enhanced beta (or 0.9.6) did not have this problem.

By the way, it would be nice if we could see the build number in the About window.

Hello Jeff,

I now have the problem to edit scripts.

http://rapidshare.com/files/258488211/Rec_13.wmv.html

I select Scott's volume script close StrokeIt and reenter Command Editor.
-> StrokeIt forgot the name of script instead cryptic characters.

By the way the new draw buttons works well :).

I found here
http://www.zeusedit.com/forum/viewtopic.php?t=2146
a few good lua scripts

why does my little script result in an error ?

do
local text = "test"
set_clipboard_text(text)
end

Thanks

-Leo

@Googer - I appreciate your persistent help with these crashes. What, exactly, are you doing that's crashing? Is it always when you run on of the built-in exec command? If so, which command? Does the 'explorer' command work (in the default configs, draw an E)? Can you successfully use the exec command to run other programs, like notepad? When it crashes, does the program it was supposed to be starting actually start?

@gemisigo - Your double-click issue still confuses me. There weren't any changes at all that would affect left-clicking (unless, obviously, you're holding down the right mouse button). When I get time I'll try installing that desktop manager to see if I can recreate the issue.

@leo - set_clipboard_text is not a built-in lua command. The zeusedit programmers wrote that function and added it to their lua interpreter. I'm not planning to add any functions like that to this lua interpreter because I think it's better to keep the base as "pure" as possible and use [url=http://lua-users.org/wiki/LibrariesAndBindings]modules[/url] and plugins to add special functions. That way everyone can contribute and we can use all of the existing lua addons.

@jeff - I can just launch StrokeIt fresh and immediately try executing the launch actions and it'll usually crash / freeze in one of three ways in very short order upon completing the command. If not on the first execution of said gesture, it'll almost certainly within another couple executions of it. The three different ways StrokeIt fails are:

1. Application Error dialog pops up about an unhandled exception (0xc0000005), which I know means a memory access violation. I've looked for Dr Watson logs on my system after this occurs but none is generated. :(

2. StrokeIt simply disappears / stops running. This is when I (usually) get a crash dump that I've been able to send you. I say usually because sometimes the .dmp is empty.

3. StrokeIt freezes and does a nice job of bringing the Windows UI to a halt along with it. Manually killing the StrokeIt process (my method being "taskkill /f /im strokeit.exe" from a Command Prompt that I make sure is running before doing these tests) will bring the system back to life. Obviously no crash log is generated in this instance either.

I've now done some more testing with some related commands I generated and have found that it's not just the built-in 'launch' commands but it is anything that spawns a new process. For example, in addition to the built-in run commands that come from the exec plugin, the Run Program gesture triggers this very easily as well. The default Run Explorer gesture does it, as does a custom command I added to open my downloads folder (i.e., Run - Run Program with File: set to D:\Downloads\ with no start dir or arguments set). In all cases, the command successfully (i.e., Explorer launches, the Downloads folder opens, a new web browser opens, etc., correctly) but I've now also noticed something that's perhaps telling - in the occasional instances where StrokeIt *doesn't* crash, I've noticed that the newly-launched program seems to not have its mouse actions hooked by StrokeIt at all. Activate a different window and sure enough, StrokeIt is clearly active, but go back to the new window and clearly StrokeIt isn't hooking the mouse in it.

One other problem I've now noticed in testing other parts of StrokeIt out I don't normally use - the strictly mouse-based gestures aren't working for me (i.e., any of the mouse click or wheel gestures). The instant I click another mouse button or scroll the wheel while holding down my gesture button, the gesture recognition engine doesn't recognize the gesture or even properly terminate the gesture recognition for the current gesture - the StrokeIt icon remains blue and I can't draw any more gestures unless I temporarily disable and re-enable gestures (done by right-clicking on StrokeIt's system tray icon twice).

There's a new build with (another) overhaul of the exec plugin and some minor bugfixes. With any luck, this will fix the crashing.

As always, be sure to use the key on the website, it can change from build to build.

@Leo - the new build fixes the problem you reported when using volume.lua

@Googer - I'm seeing the same mouse issue; I may have broken that when I added the 4/5 button support.

@jeff,

Good news! I think the crash bug is solved. :D I did have a single freeze when I was really abusing it with one gesture after another after another after another in very rapid succession but I haven't been able reproduce it. I can't say authoritatively if that's indeed even the same as the prior crash bug or not. The actual crash variations of StrokeIt dying, however, are almost certainly fixed now though - I haven't triggered one of them yet with the current build. :)

As for the other issue I thought I'd noticed with opened apps not having their mouse gestures hooked, I was probably mistaken. Instead what I'm seeing with the current version is just that all my IE (as well as Command Prompt) windows are behaving as if StrokeIt is disabled in them even though it shouldn't be. This is noticeable in testing the launch web browser gesture because it opens up an IE window instead of Firefox that I'm normally using (which probably just doesn't have all its associations set correctly on my 64-bit Vista box - I'll have to double-check this).

In any case, it's certainly looking better. :)

There's a new Plugin SDK and developer documentation available [url=http://www.tcbmi.com/strokeit/develop.shtml]here[/url]. If anyone is interested in writing StrokeIt Plugins, please take a look. I'll be more than happy to help walk you through writing your first plugin.

There's also a new build up. The "run browser" and "run email" commands should now accurately detect your default browser/email client in Vista and Windows 7.

I re-factored the code in the plugins to bring them up-to-date with the latest SDK; there shouldn't be any noticeable changes but be on the lookout for any regressions.

@Googer - Vista handles command prompt windows differently than other OSes so the mouse hook doesn't capture events over them. It works in XP and it works in Windows 7, just not Vista. However, it should be able to capture mouse events in IE without any problems. I've tested it on my Vista64 box in both IE32 and IE64 in both protected and un-protected modes. Let me know if you find anything more out about this.

-- Jeff

I can't download the new build - on the license key page, the actual link to download the the installer doesn't work. I get the following message in 10 languages when I try:

Please come back later



Edited 1 time(s). Last edit at 07/27/2009 09:50PM by Googer.

I forgot to upload the file. It's working now.

That's better - at least I can test it. :)

What's not better is that I have serious regression in the exec plugin - not only does it not actually successfully launch anything (absolutely verified when I created a new action to open Notepad and it never starts when I draw the gesture associated w/ it, and I further verified StrokeIt is supposedly executing it w/ an OSD action I also associated with the gesture), but it also crashes on the Run E-Mail Client action. The New E-Mail message action doesn't caush a crash - it just does nothing like all the other launch / run actions. ;)

Also, I tested a bit more with the Internet Explorer issue with the mouse not being properly hooked in it. This is affecting the 32-bit version only; the 64-bit version of IE is fine, even running them side-by-side, I can use gestures fine in the 64-bit version but StrokeIt acts as if it's disabled in the 32-bit IE window, even when I completely emptied out all Application Identifiers in Disabled Apps (to verify it wasn't somehow being matched to one of them). ;)

Oh yeah, new crash dump uploaded for you for the crash on e-mail client launch issue: http://www.pobox.com/~googer/tcb.zip

@Googer

There's a new build that should handle your reported issues more gracefully.

It sounds like your system is missing some registry keys that I (incorrectly, perhaps) assumed would be there. Can you verify that the following keys exist:

HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice

HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\mailto\UserChoice

Each key should have a "Progid" string value that tells it the name of the program to run (I use mozilla software, so on my system these values are FirefoxURL and Thunderbird.Url.mailto).

Once you find those values, verify that the following keys exist:

HKEY_CLASSES_ROOT\<ProgramID>\shell\open\command

where <ProgramID> is the value you found before (FirefoxURL, etc)


Thanks,

Jeff



Edited 1 time(s). Last edit at 07/28/2009 11:21AM by jeff.

@jeff,

It looks like my registry entries are defined as you assumed, so I don't think that's the problem. With the new build, the launch e-mail client and new e-mail actions work, but the web ones don't. I decided to watch what's going on with Process Monitor in action and see what's going wrong with the launch actions. :) You're trimming off the first and last characters. ;)

For example: The web browser is trimmed from:

C:\Applications\Firefox\FirefoxPortable.exe (as obtained from the registry)

to:

:\Applications\Firefox\FirefoxPortable.ex, which is then actually run as:

C:\Program Files (x86)\TCB Networks\StrokeIt\:\Applications\Firefox\FirefoxPortable.ex

- which obviously fails. Similarly, the launch explorer action fails since it tries to run:

C:\Program Files (x86)\TCB Networks\StrokeIt\xplorer.ex

and my custom Notepad action fails since it tries to run:

C:\Program Files (x86)\TCB Networks\StrokeIt\:\Windows\notepad.ex

This problem does not occur with the e-mail actions, so without looking at the source (which I suppose I can at this point ;) ), I'm guessing you use a slightly different launching mechanism for it.

Edit:

Actually I just looked in my registry again and I don't have a mailto association on my user tree but it looks like you ultimately find what it's set to when accessing

HKCR\Wow6432Node\mailto\shell\open\command\(Default) as a fallback. Not only the program name quoted in this registry key, you appear to not be trimming the first & last characters from it when you run it, so the process you attempt to create (succesfully) on my system is

"C:\PROGRA~2\MICROS~1\Office12\OUTLOOK.EXE"

- without any parameters if just launching the client, and with parameters if doing a mailto.


Edit 2:

I manually edited my ...\URL\shell\open\command\{default} entry to quote the full pathname to the executable and sure enough, it now works. Similarly, in my custom action, using a full quoted pathname to an executable works - i.e., "C:\Windows\notepad.exe" instead of just C:\Windows\notepad.exe. Quoting an executable name without the full path still doesn't work though since it tries to run that with full pathname-specified from StrokeIt's directory instead of letting the system path take over - i.e., "notepad.exe" tries to execute C:\Program Files (x86)\TCB Networks\StrokeIt\notepad.exe instead of just notepad.exe.

Edit 3:

I found your main bug. :D In Exec.cpp - Run() - your if check to see if szFile is quoted will always return true since you need == instead of = in it. :p There still seems to be more in regards to full pathname vs. letting the system path find an executable, and start dir stuff that I haven't fully figured out yet but hey, it's a start. :)

Edit 4:

OK the other part of the problem is that CreateProcess (which I'm guessing you switched to using recently from another mechanism to launch processes) doesn't search the system path, so unless you enter a full pathname for the executable, it will assume current path for where to try launching from. This means you should change your default Run Explorer action to %windir%\explorer.exe instead of just explorer.exe. It shouldn't really affect custom-defined run actions so long as the user uses the file selector instead of just typing in a name, figuring it'll run since it's in the path. ;) The other caveat is you can't "launch" a non-executable file and let Windows' file associations take over to figure out what to do as I believe you previously could do.



Edited 8 time(s). Last edit at 07/28/2009 02:18PM by Googer.

There's a new build up (7/28 C)

- this should fix the exec "trimming bug"
- this also fixes a bug with the scriping plugin
- there's a new lua plugin called "clipboard.dll"

The new lua clipboard plugin will be installed in INSTALLDIR\Scripts\lib and can be included in your scripts using "require [[clipboard]]" This plugin allows you to manipulate the windows clipboard. See the "Clipboard test" command in example.lua for details. Remember that the newest example.lua is in INSTALLDIR\Default\Scripts

Full source for the lua clipboard plugin is available at the [url=http://websvn.tcbmi.com]source repository[/url] and also available for download on the [url=http://www.tcbmi.com/strokeit/develop.shtml]developers page[/url].

If you're comfortable with C, take a look at the source code for the clipboard plugin. It's very easy to write your own lua plugins and the clipboard plugin source should get you up and running pretty quickly.

-- Jeff



Edited 2 time(s). Last edit at 07/28/2009 03:11PM by jeff.

I found something weird. I don't know if it is intentional or a bug but it is definitely strange.

There are some settings/data that are stored in the "C:\Users\whoeveritis\AppData\Roaming\TCB Networks\StrokeIt" directory. At least under Vista they are stored there. I found there the CrashRpt and Scripts directories. This is not the place where I would like my scripts stored, why is it there? I installed my copy of StrokeIt into "I:\Programs\StrokeItEnhanced" and the scripts should be in "I:\Programs\StrokeItEnhanced\Scripts".
I created a new command, selected it to be a lua script and clicked on "..." to select the script file. I selected one of the script files. in "I:\Programs\StrokeItEnhanced\Scripts" and became confused. It did not do what it should. I clicked the "E" to edit and saw that it is not the one I wanted to have.

And now the naughty part. Iff a script file with the same name in "C:\Users\whoeveritis\AppData\Roaming\TCB Networks\StrokeIt\Scripts" directory exists then that script file will be selected/loaded instead of the one I selected in the OpenDialog window. If it does not exist it works normally.

Why is StrokeIt so eager load scripts from that directory? Is there a way to override this behavior?

EDIT: and one more thing. If the EditBox for the script is empty and I click on "E" to edit the script, the editor opens all the lua script files in "C:\Users\whoeveritis\AppData\Roaming\TCB Networks\StrokeIt\Scripts".
By the way, the EditBox is marked to be the "Script path" but it shows the file name only, the path is hidden.

EDIT2: It still tends to forget that it should draw the line.

ETIT3: Well, it does not quite forget. It draws the line on my second display while it does not on the primary.

EDIT4: It has completely gone haywire. I made the following simple function to test:
function test_clipboard()
require [[clipboard]]
local message = clipboard.get()
local params = string.format([["%s" "%s"]], message, "Scripting Demo")
plugin.call("Utilities", "MessageBox", params)
end

After successfully completing its task, it suddenly stopped. Now it only does do anything if StrokeIt command window is open and the lua script command is selected. As soon as something gets focus in the configuration part (dropdown, scripth path, script option dropdowns or the buttons) it fails to work.

EDIT5: It seems that you have reintroduced a long lost and forgotten bug :) The Height and Width attributes in Windows - Resize command are transposed.



Edited 7 time(s). Last edit at 07/29/2009 09:43AM by gemisigo.

@jeff, this build looks good for running everything now. :) The caveats I noted in my last edit on my prior post of course still apply though about needing to use full pathname to executable, etc. - which isn't a big deal once you're aware of them; it's just that as I said, it is a change in behavior from previous versions. ;)

@gemisigo

The APPDATA directory (C:\Users\whoeveritis\AppData\Roaming\TCB Networks\StrokeIt" on your machine) is where user data is supposed to be stored. As you've discovered, the user files in this directory take precedence over the system files.

If you would like to force StrokeIt to keep all of its data in the installation directory, you can turn on portable mode by creating a strokeit.ini file in the installation directory.

Thanks for all the other bug reports, I think most of them should be easy fixes.

@jeff

Yes, I thought taking precedence was not by accident, I just wasn't sure. The only thing I disagree with MS is that user data MUST NOT be stored on system partition so the "C:\Users\whoeveritis\AppData\...etc..." is not the place where they should be. System partition is the most susceptible to be corrupted somehow and if I'm forced to reinstall system, backing up user data from it before formatting and reinstalling is not my favorite thing to do. If I could store them on a separate (data) partition that is not affected by this issue and where they can reside safe and sound, why would I not do that to ease my pain in case of a disaster?

What is this portable mode thing and what should that ini file contain?

There's a new build that should address the following:

- crash with hotkeys command
- win resize width/height reversed

Note: While the win resize command should work from now on, any existing resize commands will need to be updated because the saved "height" and "width" parameters will be reversed.

@ gemisigo - let me know if you can still reproduce your problem with the scripting plugin. Also, is the line drawing always broken, or sometimes broken? When it is broken, does the line draw when your mouse is on your second monitor, but not when it is on your first monitor. Or, does the line always draw on your second monitor, even if your mouse is on your first monitor?

@jeff - I use a second monitor at my workplace so I've got no way to reproduce that right now but I'll try to explain it in details.

The drawing is not always broken, but it can be said to be regular, at least once a day. Suddenly it stops drawing the line on my primary display. It keeps working on the second one and if I start a stroke on the secondary display and move the cursor to the primary it stops drawing at the boundary. The line already drawn is still shown on the second one. And if I return the cursor to the second one the line continues to draw where and as soon as the cursor reaches it.
Pretty much the same, when starting the stroke on primary it does not show until cursor reaches secondary. Still the strokes work as they should, commands are executed even if the line is not drawn.

Otherwise, when it is normal, the line is drawn exactly on the same display where the cursor is. I'm not sure it is relevant but the two displays are not set to the same resolution, primary is 1280x800, secondary is 1400x900.
After going crazy it does not restore until I disable and enable line drawing in Preferences or restart StrokeIt completely. Disabling and enabling StrokeIt only does not help.

I'll "torture" the scripting plugin tomorrow to see what exactly does it do.

EDIT: did some testing. Here are the results. The luathing did not change. After the first successful execution (putting up a dialogbox with ok button and whatever there was on the clipboard) it stops working normally and puts up the dialogbox only if the command editor is shown and the lua command (named "New Command" - very original :) ) has focus. Even if I click inside to configure the command it does not work anymore until I restore focus on "New Command".

As for the line drawing I experienced another anomaly although it might have been in the first case too. It does draw the line but on the desktop, that is, under any open windows there might be, no matter what kind of window it was. At first I did not notice because the color of my desktop is dark blue. Not exactly the same as the line StrokeIt draws but it can easily slip ones attention if one is careless enough :( So it seems to draw the line on a layer between the desktop and the open windows/forms/application/whatever. What's funny is that it only happens to my primary screen and never on the secondary. When I do not have a secondary monitor attached I cannot reproduce the malfunction.



Edited 2 time(s). Last edit at 08/04/2009 07:27AM by gemisigo.

I'd love to donate or buy, but I don't know how to do so in China :+
Would it support Alipay (an online e-payment system which is the most famous in China), that'll be convenient.

@jeff,

I can confirm that the hotkeys commands seem fine in the current build.

A previous issue I'd mentioned still exists, but I don't think you mentioned that you fixed it yet. That issue is the issue of mouse button & wheel gestures causing StrokeIt to no longer accept gestures until you manually disable and re-enable gestures. When executing such a gesture, StrokeIt's icon turns blue and any associated action is appropriately executed, but StrokeIt doesn't do the final bit of resetting itself to take further input. ;)

@jeff
I have the same anomalies with Activate Window as some other people had with other commands (i.e. Send Hotkey forgetting the entered hotkey).

I did some experiments with some of my actions that include Activate Window. So far it seem that it "scrolls the settings out". I have an action with series of commands that:

1. shows the Command Window.
2. activates it
3. moves it to a certain location on primary screen
4. makes it always on top

Now the 2nd one has the Caption set to "StrokeIt - Command Editor". When I first opened that action and selected the command, that string was in Caption editbox. At the second time it "scrolled up" to be the Class and at the third opening it vanished completely, leaving two empty editboxes. It seems as if there was some misindexing in an array or something. Please, take a look at it. It might be the same problem at Send Hotkey too. Thx.



Edited 1 time(s). Last edit at 08/11/2009 02:46AM by gemisigo.

Any chance someone could post a few screens that show the new features not available in the un-enhanced version? This might entice more people (and me) to buy the enhanced version, as the differences (aside from lua scripting) don't seem too obvious.

There's a new build that fixes the Activate Window command and (hopefully) fixes the Hotkeys commands.

@gemisigo: I'm still not able to replicate the problem you're having with the scripts. I created a script called test.lua with the following contents (per your earlier post)

------- test.lua -------
function test_clipboard()
require [[clipboard]]
local message = clipboard.get()
local params = string.format([["%s" "%s"]], message, "Scripting Demo")
plugin.call("Utilities", "MessageBox", params)
end

test_clipboard()
--------------------------

I can assign this to a command at it works just fine for me no matter that control is focused. Can you give me step-by-step instructions to try to replicate your error?

Thanks,

Jeff

Download link still downloads StrokeIt_0.9.7-Full_Demo-030809.exe