Previously, whenever script did something really wrong, which for usual "classic" program would lead to crash, EyeAuras followed that same pattern. Meaning that if you made some mistake in the script - the whole program will crash as soon as this happens, bringing up Error Report window. This kinda made sense, but at this point I started getting A LOT of error reports which I can't really fix as they must be fixed on the script side.
Basically, I have 3 options:
a) keep everything as-is and keep informing people that they must incorporate exception handling practices just like usual apps do
Does not work very well, especially considering in-flow of new users. Meaning that the more popular the program will get, the more new users will try scripting and the more of them will have to deal with exceptions. Kinda not scalable.
b) make scripts run in an isolated environment, basically small separate executables which interact with the "main" program via some fancy transport
Best option, but from a technical perspective extremely challenging, especially considering that this "small" program will have to communicate with the main one with extremely low-latencies, otherwise it just won't work. At some point this will be my goal, but I am estimating the cost of this feature to be around 3-4 months of work at the very least, meaning that it is amongst the most expensive potential new features
c) given EyeAuras has full control over the source code and it controls how it runs, try to make the overall process around scripting as bullet- and fool-proof as possible
This is the option we'll try for now. I developed a test solution which will try to intercept all errors coming from user scripts and, instead of crashing the app, try to consume them, restore the state (if possible) and continue operating. Also I'll start writing automated code-improvements which will be applied to user code during compilation time - e.g. adding proper exception handling where it is missing (e.g. button click handlers) or handling exceptions throw by Tasks.
We will see how it goes.
Few other fixes and improvements in this release:
GetService<T> could occasionally dispose(aka kill) some important services of EyeAuras as well...For a few years, EyeAuras was using a mechanism which validated results of each and every mouse movement - it made sure that cursor has actually been moved to desired location.
Historically the main reason for this were hardware input emulators like Usb2Kbd and custom Arduino-powered devices. This made sense for them as they do not really perform the movement instantly, meaning that if you have two inputs in a row (MouseMove + Click) there is a chance that mouse won't be at desired position when Click will be performed.
Now, the tooling around sending inputs became much more powerful - SendSequence, BehaviorTrees, Scripts, this mechanism seems to bring in more troubles than its worth.
In test mode, this mechanism is now disabled across all input methods. In theory, this should not be very noticeable in most cases, but keep in mind, that you may have to throw-in some extra delays in-between mouse movement operations.
Added full Ctrl+C/Ctrl+V support - previously Ctrl+C was kinda similar to Export mechanism, meaning you could not just copy some item and paste it into a different folder as it would lead to conflicts. Now you can copy and paste items all around just like you do in Windows explorer. Also the naming scheme for cloned items tries to follow the one used in Windows, e.g. if you're copying "Aura", the first copy will be named "Aura - Copy", the second one "Aura - Copy(2)" and so forth.
Note that copy-pasting items across multiple instances of EyeAuras won't work! You have to use Export and Import for this(for now).