Other Software > Announce Your Software/Service/Product

WinSendkeys: Latest version thread. Version 3.2.2.0, released 2018-11-04

<< < (3/6) > >>

Ath:
The original download zip-file has been updated, so now I can officially announce:

WinSendKeys 3.0.5 Download from the first message in this thread

What's new:

* Disabled left-over debug-messagebox :-[ (thanks jOc for reporting that)

Ath:
How to send keystrokes first to original program (to call the popup) and then to the newly popup-ed window.
-jOc (June 21, 2011, 08:24 AM)
--- End quote ---
I took this as a feature request, and added this to WinSendKeys.
It is now possible to specify a few commands in a strokesfile, --window, --exec and --delay, to switch Window/Exe (-w and -x/-xp parameter equivalents) or introduce a delay of some milliseconds. The details are in the readme file, that's just like the source and a compiled exe, included with the download.
I also introduced the -v parameter to enable %environment.var% and @macro@ expansion on keystrokes (default off to avoid compatibility issues). This variable-expansion is now always applied to the -x and -xp commandline-parameters.

So, without much fanfare, but still proud, I announce: WinSendKeys 3.1.0

If you might find any strange issues, or have a feature request or two, please don't hesitate to respond in this thread.

cranioscopical:
@Ath Has this one been covered?

Is there now a way, or what is the best way to send a series of key strokes, then a delay, then another series? Or a series, then wait for an event, then another series?

I tried a couple of ways but obviously haven't understood the correct method.
I want to: -send [CLASS:win] key key… <delay here> key…
in this case would <delay here> be -xd 1000, or can't it be inline like that?

With -f, is it possible to have more than one .stro file by simply using a different name for each?

cranioscopical:
Ath,

I have a friend whom I'd like to set up with a MIMO and the fruits of your labour.

I'm thinking that will need either a couple of days of setup, while we figure out habits and needs, or some kind of Procrustean utility that can auto-generate a fixed screenful of buttons then loop through each one, requesting:
application contextfilepatha captionforced formattextan imageforced formatfilepathexecutablefilepathparamskeystrokeskeysthe problem with the latter being subsequent editing for omissions, errors etc.

Does that approach make sense to you?

Ath:
@Chris and all interested,

I've added some scripting facilities to the [-f strokesfile] feature, so it's now technically possible  to implement your request.
Using such script (an example is included) you can:
- Wait for a window (or title, or exename) to open (--winwait <windowname> [timeout])
- Wait for a window (idem) to close, both with a timeout (--winclose <windowname> [timeout])
- On timeout of the above, either quit or goto a labeled line in the script (--error quit and --error goto <label>)
- Jump to a specific label in the script (--goto <label>)
- Call a subroutine with optional parameters (--gosub <label> [parameter text])
- Return from the subroutine (--return)
- Quit the script (--quit)
- Display a message with optional timeout and parameters support (--msg [timeout,]message text [$params$])

But the difficult part of your request is to interact with the user, Windows and it's applications to determine what to send when and where, and what to wait for, to get the desired 'workflow'.
At least the techy-geek baseline is here :)

Release is available at the first message in this thread, so, tada:

WinSendKeys 3.2.0

Navigation

[0] Message Index

[#] Next page

[*] Previous page