Previously, when a script did something really wrong — something that would cause a normal “classic” application to crash — EyeAuras followed the same pattern. In other words, if there was an error in your script, the program would immediately crash, show an error report window, and offer to send that report to me. That made some sense at first, but over time I started receiving a LOT of error reports that I simply cannot fix, because the issue has to be fixed in the script itself.
In practice, there are 3 possible approaches:
a) leave everything as it is and keep telling people they need to use proper exception-handling practices, just like in normal applications
This does not work very well, especially with the growing number of new users. The more popular the program becomes, the more new users will try scripting, and the more of them will run into exceptions. It does not scale well.
b) run scripts in an isolated environment — essentially create small separate executables that communicate with the “main” program through some fast transport
This is the best option, but technically it is extremely difficult, especially because that “small” program would need to communicate with the main one with very low latency, otherwise it simply would not be usable in real scenarios. At some point this will become a goal, but I estimate the development cost at at least 3–4 months, which makes it one of the most expensive potential new features.
c) since EyeAuras fully controls the source code and the execution pipeline, try to make the entire scripting process as robust and fault-tolerant as possible
This is the option we are trying now. I built a test solution that tries to catch all errors coming from user scripts, and instead of crashing the application, it attempts to handle them, restore state where possible, and continue running. I will also start adding automatic code improvements that are applied to user code during compilation — for example, inserting proper exception handling where it is missing (such as button click handlers), or handling exceptions thrown by tasks.
We’ll see how it goes.
A few more fixes and improvements are also included in this release:
GetService<T> could accidentally dispose (in other words, “kill”) some important EyeAuras services...For several years, EyeAuras used a mechanism that checked the result of every mouse movement — it verified that the cursor had actually moved to the intended position.
Historically, the main reason for this was hardware input emulators such as Usb2Kbd and custom Arduino-based devices. In those cases it made sense, because they do not always perform the movement instantly. That means if you send two inputs in a row (MouseMove + Click), there is a chance the mouse will not yet be in the correct position when the click happens.
Now that input tools are much more powerful — SendSequence, BehaviorTrees, Scripts — this mechanism seems to cause more problems than it solves.
In test mode, this mechanism is now disabled for all input methods. In theory, this should not be very noticeable in most cases, but keep in mind that you may need to add some extra delays between mouse movement operations.
Full Ctrl+C/Ctrl+V support has been added. Previously, Ctrl+C behaved more like an export mechanism, which meant you could not simply copy an item and paste it into another folder because that would lead to conflicts.
Now you can copy and paste items anywhere, just like in Windows Explorer. The naming scheme for cloned items also now follows the Windows style. For example, if you copy Aura, the first clone will be named Aura - Copy, the second Aura - Copy(2), and so on.
Please note that copying and pasting items between multiple EyeAuras instances still does not work. For that, you still need to use Export and Import.