The current release is JavaMacros-0.0.3.10.3.exe
- JavaMacros-0.0.3.ETC. -WinXP.exe is a version that runs in Windows XP 32 bit systems. Do not use it
in 64 bit systems, as it is unable to read the name of 64 bit applications. Also, it requires to
sacrifice some features of JM to run smoothly... I created it because I still use some XP standalone
machines. Unfortunately I do not have WinXP machines any more, so I canot test JM on WinXP and thus
I will not update the XP versions any nore.
The file is a 7zip self-extractor.
Cautionary warnings: JavaMacros can act as a "keylistener" that streams on the local port
what keys you press on your "macros-only" devices.
That, unless you use the "LuaMacros Direct Code" action (which is less flexible than others,
but can work without communicating key events to the Java GUI, in which case only the IDs of the
attached devices will be streamed), or you select "Use Piping" in the options.
(Note that JM still needs Http communication to tell Luamacros to re-configure/rescan the system.)
In this second case, JM expects to read its event from a file in the local machine, written by
either LuaMacros or its "predecessor", HidMacros.
- Effectively, reduced purely to "LMDC", JM becomes a quite smart configuration-switcher for
LuaMacros, albeit one that does not requires to write Lua code unless one wants to.
Windows firewall will likely ask if you want to allow Luamacros and the Javamacros virtual
machine (just a copy of javaw.exe with a recognizable name) access to the local network.
Unfortunately, for JM to work with LuaMacros, you will have to accept it (with HidMacros, no).
As long as the macros are required to understand the semantics of what you do, it should be
reasonably safe (especially so if a button can launch some dozen different macros, depending
on the open application, window type, title or manually selected use case... also, chances
are that you already have some truly malicious key-loggers already lurking in your system, so
an innocent one only looking at a couple of game-pads or num-pads is not going to change things).
Extract JM in a "normal directory", not in a write-protected application directory, as the launcher
has stuff to write and sub-directories to create, and extracting it in the windows "applications"
directory entails that you would have to launch the launcher (the contained javamacros.exe) - the first time -
with administrative rights
(note that, if you launch JM "as administrator" the fist time , it will just copy javaw as
JavaMacrosW.exe in your JRE, without copying locally the whole JRE, which has - as always
- some pros [less wasted space] and cons [future java updates can break JM] ).
General notes:
A Java 8 runtime is required for JavaMacros to run.
Luamacros is - and Javamacros initially was - intended for 64 bit Windows systems.
Javamacros can be built and run on 32 bit systems, even on XP, but Luamacros may not start there.
(in fact, it does not start at all in Windows XP, which is why JavaMacros for XP uses HidMacros
as its events provider).
The UI library used to generate most of the interface was created initially just for "static"
configuration windows, and "leaks" memory a little bit during continuous use on dynamically
created data structure.
It is, hence, recommended to set JM as "starting minimized" and "minimizing to tray", and
only open (i.e. create; JM is designed to not have the full UI in standard operation)
the UI to set and manage macros.
- Also, when the GUI is created, it adds a "tail" to the execution path of the macros, so
launching JM as minimized on the tray makes it a tiny little bit faster).
Note that, as the JM virtual machine runs under the name of "JavaMacrosW.exe", you can easily
use the task manager to monitor its behavior.
The system tray Icon allows access to some "reduced" user interfaces, and to change the current
"manual use-case" when working on windows for which any has been defined.
It also shows JavaMacros "internal modifiers" status, so setting it as "always visible" in the
Windows tray area is highly advised.
If the options "grab new devices" and "ask names for new devices" are set, when you attach a
new device or - move a present one to a new USB port - it will reload LuaMacros, after 20seconds,
and ask for the "new" device name (if you just moved one to another port, it will likely propose the
previous name of it as first suggestion) when A Button is Pressed on it.
Note that, from the point of view of JM/LM, the same device moved to a new port is not distinguishable
by another device of the same vendor and model (in fact, I personally use two Numeric pads of the same
make and model, whom invoke completely different macros) - hence the necessity of a user choice in the
case (and the separation between "physical" devices and "logical" [i.e. names of] devices, the second
being groups of 0 - for macros linked to device names with no physical device attached - to N physical
devices).
--------------------------------------------------------------------------
Changes for version 0.0.3.10.0
- Some more bug fixes that I forgot about, but some bugs are still present (at times, JM loses track of the "title based" use cases associated to some macro, after an edit... Also, the "change locale" still needs revisiting, as it turns out that there is no need to change the target window keyboard layout - only the one of JM, but in a way all layers of Windows are aware of... grrr).
Features added:
- It is possible to do some editing actions interacting directly with the Tree panels (Devices, Applications, Macros) by using the right button of the mouse.
- I have added a counter for the executions of each macro. The purpose is to keep track of which macrosare used more often, eventually to re-decide the "buttons layout"
As an addendum to it, it is possible to select the order of the macros, depending on name/counter/type of action.
- It is possible to redirect an application to invoke macros defined for another (Example: GIMP-2.1.0 to use the ones defined for GIMP 2.8) in case there is no macro defined for the current button
- If one needs it, he or she may set up and use a "Virtualized keyboard", accessible through the direction
http://local_IP_of_your_machine:javamacros_port/virtual-keyboards
Said keyboard must be created using a phisical one (however, remember that if one changes the usb socket, LuaMacros
sees it as a "new" device, so it noot need to be a really a new pad) - to populate it with keys.
JMacros will open a pop-up with a password, on its computer, that will be need to be written in any device trying to connect to it. The password is a number that randomly is chosen by JM at each session, the first time you try to connect to his "back port" during its current run session. I find it useful for some functions I seldom use, like pressing print screen (my keyboard lacks that button) and to have a remote control for the "scan" function (my scanner is at some meters from my PC - I use my smartphone to get to the "scan" macro, so I do not have to go back and forth for very drawing need to scan).
- The Clipboard action has now the possibility of defining "multitexts" - a list of phrases separated by the sequence [next].
Depending on the selection policy chosen (sequential or random), at each successive invocation of the macro a different phrase will be selected and copy-pasted (in sequential order, or r random). JM remembers the last chosen phrase, when the mode selected is sequential.
- The Key alias action has gained the possibilty to invoke some simple Mouse events, like wheel up and wheel down (useful with some programs zoom function, for example, or to have a "center click" dealing with a browser).
- The compact display, now, always tries to resize itself to the smallest possible dimension, when it adds/loses the "manual usecase" selection window.
- it is possible to "anchor" the compact display - it will maintain the top-right-most corner position if docked on the right-of-center of its screen, the top-left otherwise
- As I use JM with a host of numeric pad with "00" buttons, I added the possibility of defining some policies to differentiate between these and the simple "0" buttons - they are a bit twitchy, but I am not sure how to address it; It is mostly a question of defning the timing of the events automately generated in the keypads.
These policies are shown by default when selecting as trigger for a macro either a "0" or an "Insert" button (in my pads, these are the 2nd function of 0, and that under 00 is double, too).
These policies are "Accept" (every keypress will launch a macro), "ignore completely" (JM expects for the time specified by "Rapid Typing Threshold" before invoking the macro, and will do so only if no subsequent button clicks are detected), "ignore first event" (JM invoke the macro only if two keystrokes are detected before the RTT is reached), and "ignore 2nd event" (JM will only act on the 3rd consecutive stroke).
(I may have to revise this)
- Added a disambiguation feature to the Applications panel: if an executable has the same namefile but is in a different location, a number is added to the label. I ran in the situation after trying to use two different versions of Firefox, one from mozilla and the other embedded in TOR Browser. Both are "Firefox" executables, but JM uses the full file path to recognize which is which.
- Added some contextual menus to the "Tree" panels, accessible by using the mouse right button
- Added the option to order the macro by name, counter, type - in ascending and descending order.
- Bug Fix: the thext editors nasty behavior when writing have been fixed, although there are still some mistakes in the syntax decorations for some actions.
- Bug Fix: When opening a macro whose previous version has been completely lost, JM hanged on and had to be killed. I fixed the bug that sent it into a loop, and added a signal that the previous history is been loaded (the background of "Show Previous Version" button glows Orange).
--------------------------------------------------------------------------
Changes for version 0.0.2.3
- Bug fix: fixed a bug in the Virtual modifier action, in toggle mode, that made it autoreversing automatically in 0.4 seconds
- Bug fix: fixed a bug in the "reverse letter case action", that made it not working outside debugging mode. Essentially, the "add to clipboard"
is [yet another exmple of inter-process, asynchronous effect]
- Bug fix: fixed a bug that had JM complain that it could not switch the active window keyboard layout when, in fact, it had.
Newly discovered, open bug:
- The "change locale" function manages to change the locale setting on JavaMacros itself, at the windows level (good),
but said change fails to be "seen" by the Java Runtime. As a result, the "send-keys" fails to send keys that are not present in the default kyeyboard.
However, if one pick one of JM windows and manually changes the keyboard layout to the one it need to use (note that JM may already appear to use said
locale, yet the manual switch will have to be done anyway), then it will work.
As a work-around this bug, till we figure a way to solve it (if there is any), we have reworked the "Compact" display so that it can be selected to use
a frame (the JM symbol appears among the open tasks) so that, when selected/picked, it can receive keyboard events and allows to switch JM localem as
it is done with all other windows. This led also to..
- The "Compact display" has now two "face" modes, a "normal" and a "minimal" mode, toggled clicking the button on its right-top corner, as well as two
window types. In "is a frame" it can receive events from keyboard, and thus used for actions such as
- Change the keyboard layout
- Open-close the main window (Ctrl O).
- Shut down JM (Ctrl Q)
Note: one of the libraries used by JM, sgi-util, has been modified, so it is a nice idea to remove the versions before 0.0.7 if they still are present
--------------------------------------------------------------------------
Changes for version 0.0.2.2
- The filters on macros now compose - select a device, or one of its keys/buttons, an application, or one of
its use cases, and the macros window will only show the macros defined for that combination of trigger
values
- Fixed the send-keys parser bug that made so that "^{Something} and the rest" became, in the Robot sends keys
action, "^({Something} and the rest)". Now the parser correctly "adds" the implicit parenthesis closure, so
that the kley events sequence produced is aligned to the ones produced by LuaMacros/Hidmacros, which is
"^({Something}) and the rest" - note the different position of the closing parenthesis.
- Added a {mouse x, y, buttons, repeats} escape. The syntax follows old HidMacros syntax, and the mouse returns to
the original position afterwards. Still a bit unsure about it
- Added an "Auto-Filter" and "Auto-Select" option to the UI - if enabled, once one selects a device-key, a filter
on the active window is automatically added.
- Added an "Compact Display", that shows the inner status of JM as well as the last event (device - key or
last executed Macro).
--------------------------------------------------------------------------
Fixes for version 0.0.2.1
- Fixed an awful bug that made JM crash when it was loaded on a new machine
(We know, we know...)
- Added a time-out to the initial "find-a xMacros.exe" function.
- Fixed a bug that allowed the JavaMAcros Action to "record" key sequences,
without storing them unless the user edited the sequence
- Added the option of completely ignoring trigger collisions (default)
- Set "piping" as the default events communication mode.
--------------------------------------------------------------------------
Fixes and changes for version 0.0.2.0:
- I confess a terrible fondness for the old Windows XP; However, Luamacros does not run at all in it.
As a "solution", I wrote a couple of functions and added to JavaMacros the ability to compose the
configuration files for HidMacros, so that this venerand software may communicate key (and Mouse! )
events to JM.
- Added "locale selectors" in three places: to the applications, as possible trigger filter and as
required-forced locale on the two actions that "stream keystrokes" from JM to the open window.
On applications, the selected locale is "imposed" by JM - to the application window - the first time
Javamacros comes across the application, in the current work session. Once JM has done this first language
swap, it further ignores the issue (but, o course, if it is stopped and relaunched, it will re-impose the
window preferred locale.
As a trigger filter: In some keyboard layouts, the same key codes may be produced by different physical buttons.
As a result, with a typical 104 keys keyboard, it is relatively simple to encounter confusing situations,
in which the actions seems to randomly migrate on the keyoards(s).
To ameliorate it, it is possible to impose a locale filter on a macro's trigger, so that it is not invoked
when the system uses the "wrong" keyboard layout (i.e. when the ,acro would be called from the wrong
physical key).
As a "forced locale" on the "JavaMacros send-keys", and "key Alias" actions. Some applications use
non-programmable short-cuts that require keys that are not available in a given keyboard layout.
Time and again, we have seen that the only way around that was to have BOTH the target window
and the "keys firing" macro generating software operating in the same, "correct" locale. Cue some
months of always switching from the en-US keyboard layout ( so that Photoshop Elements' U.S.A.
shortcuts can be invoked) to the Spanish layout of the keyboard, and viceversa, and the irritation
as the "Akt Shift" action becoame compulsive, every time the keyboard does not behave as expected.
- Trying to get JM to work in XP brought forth the possibility of choosing a different way, for JavaMacros, to
receive the events from LuasMacros.
In the "luamacros" panel in the general configuration settings ( or under the Option menu, in the main GUI frame),
now appears the toggle choice "Use piping".
Essentially, in this mode the library in LuaMacros (or the one in HidMacros) does not send the keyboard events
as http calls, but write the data in a small file that JM then reads and destroy.
On one side, this requires to write and read on disc, which feels a bit wasteful - more so on SSD drives, that have
limits on the read-write cycles.
On the other, the "piping" channel seems to be more tha a bit faster than http, more so on SSD - not to mention, with this
communication channel, eventual third parties are virtually impeeded from earsdropping on the user's actions.
- Adde some more feedback for when a Macro is not being invoked, either because the current "modifiers" or locale settings are
not acceptable.
--------------------------------------------------------------------------
Fixes and changes for version 0.0.1.4:
- Bug fix: Now the "Splash page" can be really de-activated (embarrassing bug, that one)
- BUg/Change: after a detected collision in a macro, said macro will avoid remarking that she is in collision
with others, until 60 seconds have passed (from the last collision-provoking modification).
- Fixed a bug in the propagation of property changes chain
- Change: The "Core Configuration" window is now a "tabs" panel.
- Change: When the UI is open, all the stack of "available" use-cases for an application is shown;
The ones that are "active" for the last event have "enabled" background color, the other disabled.
The "Any Application/Basic" use case (i.e. the default) has yellow background.
The useCase in which a macros was executed has a dark red/brown background;
The use-cases "below" the one where a macros is executed show washed-out colors. This is to remind that
macro defined for the key/device in those use-cases won't be accessible, if the executed use-case is active.
- Change: If the GUI is open, it shows the last executed macro at the top of the list, even when this is not inside
the current filter settings
- Change: If (and only if) a macro is to be invoked on a Numeric Pad "0", it now is possible to define one
of four "Rapid Keytype" policies
* accept the fast double (or triple! ) events,
* Ignore any "too-fast" key typing,
* invoke the macro on the second key type
* or on the third key-type.
This allows to use the "Multiple 0" keys -often present on numeric keypads - as if they were different buttons,
and not just one and one (or two) very fast-repeating "clone(s)" of the same.
The option is available for those macro actions that are executed only on a key "release".
Still open:
- Fixing the saving, and retrieval, of previous versions of the macros
- LuaMacros may sometimes become unresponsive, and need a user "force-restart" (it is one of the commands
in the tray icon context menu)
It is preferable to eliminate the precedent version(s) of the JavaMacros, before "installing" this one.
However, JM replaces old versions of the Lua library, when running above LUaMAcros, and dynamically re-creates
the Hidmacros configuration file when running with that.
--------------------------------------------------------------------------
Fixes for version 0.0.1.3 :
- Bug fix: there was a bug that "fixed" the duration of delays to 5 seconds;
fixed, and max allowed delay value is now set to 30 seconds (30000)
- Bug fix: added "closure" for the un-grouped modifiers in the Java Send Keys action.
Previously a sequence like "^a something" was equivalent to "^(a something" and it
left the modifier "pressed" at the end. Now all modifiers pressed inside a java send-keys
will be released at the end of the sequence (so, that sequence is now equivalent to "^(a something)").
Thus, only ways to press and let pressed a modifier are now using a "virtual modifier" in
toggle mode with "system-wide" scope, or the "key alias" action.
- Bug Fix / Design change:
The Virtual modifier action now allows the use of OSD reminders, with the caveat that its
"mode" influences the OSD behavior.
In "Press and Release", if the Macro uses the reminder, it ignores the value of "deferred OSD"
and shows the reminder on "key down".
In "toggle mode" it now behaves exactly as the other actions, and allows the user use deferred
OSD reminders and to forego the execution simply by keeping the key down more than 1.5 seconds.
The "Key-Alias" action remains "OSD-less", for the moment.
Changes:
- Added escape sequence {beep [num repeats][, hold <ms between repeats, minimum 200>} to the
list of available escapes. As the name suggests, {beep} does in fact produces a sound when
it is processed.
Note that 100ms is the minimum interval for the human ear to distinguish two different sounds;
In practice, anything below 200 ms tend to be read as an awkward trill.
Also, {beep} is asynchronous, as {delay} - when it encounters it, JM forks a new thread that
completes the execution of the of the macro, while the rest of JM goes back to standard business.
- Modified the "Key Alias" action, adding a "delay" parameter and replacing the "text" field for
"reading" the key from the main keyboard, with a drop-down box. Also, added a "beep" parameter.
--------------------------------------------------------------------------
Changes for version 0.0.1.2 :
- Slightly modified the policy used to decide if two Macros "collides", as the original was
too sensitive.
- Modified the mechanism by which the user choose what to do, in case of macros collision.
Now, the standard answer is to assign anyway the new trigger to the macro, and let "god"
decide which macro will be executed at run-time.
Personal recommendation: when a collision happens, it really means that one has to
think a moment about the hierarchy of macros that he is creating, and maybe change one
of the use-cases priority under the application.
- Modified the mechanism by which the trigger values are assigned to the macro with the
"Use This" button. Note that the change, at the moment, makes quite arduous to deduce which
setting led to a collision...
- Disambiguated the "Filter by this" button function, in a "Filter by key" (filters the
macros by the physical key/button they are associated with) and a "Filter by this"
(activated only when the user choses a usecase in the use-cases stack table) that
also uses the application and the usecase as filters.
(note that there may be as much as 16 macros under a key/application/usecase, if the
user used extensively the "virtual modifiers" feature).
- Added an "Edit key/button" dialog - navigate the devices tree to a button, click on it,
and it will open. The purpose it to allow rename a button, in the case the user has
placed stickers on it, or tilt the keyboard sideways (or borth - I do so).
- Fixed a bug that let a key "attached" to a macro, when the user changed the macro
device/key/button in the "trigger".
- Slightly modified the "Virtual Modifier" system, but the "system - wide" scope effects are
still a bit tricky to figure
- The "alt graph" is now unavailable when setting a virtual modifier with "system-wide" scope.
Apparently, Java Robot hates it...
- Added indicators of JM "modifiers mask" status on the system tray Icon
- Profoundly retooled the "launcher" jar, and thus javamacros.exe (which is just a Launch4j
wrapper for it).
The new version will try to use the jre it runs on, to create an internal copy of it
(a folder named jre) and its "specialized" java virtual machine, JavaMacrosW.exe.
- Cleaned up the folders structure:
Moved the log files generated launching the app to the sub-directory "logs"
Moved the javamacros main jar ( javamacros.0.0.1.2.jar ) to the sub directory "bin"
If you have downloaded the previous version, it is recommended to extract/install this in
a new folder (or to erase the previous version).
Settings will be preserved anyway, as they are stored in ".sgi\javaMacros\model", under the
user home dir (usually, "C:\Users\[Your User-Name]\.sgi\javaMacros\model").
Of course, extracting in the same folder may spare you one message from the Windows Firewall,
as Luamacros would be in the same place, but this version moved the JavaMacros vm to a more
generic "jre" subfolder and, hence, the Firewall will ask about JavaMacrosW anyway.
Open bugs for version 0.0.1.2:
- Fixing the saving, and retrieval, of previous versions of the macros
- LuaMacros may sometimes become unresponsive, and need a user "force-restart" (it is one of the commands
in the tray icon context menu)
- Virtual modifier action does not allow the use of OSD reminders
Download Latest Version
Examples of macros - drawing software, browsers.zip (11.6 kB)
