Ранее, когда скрипт делал что-то действительно не так, что для обычной "классической" программы привело бы к крашу, глаз следовал той же схеме. То есть, если вы допустили ошибку в скрипте, программа сразу же вылетала, показывая окно отчета об ошибке и предлагая ее отправить мне. Это вроде как имело смысл, но в какой-то момент я начал получать ОЧЕНЬ много отчетов об ошибках, которые я никак не могу исправить, так как их нужно фиксить на стороне скрипта.
В принципе, у меня есть 3 варианта:
a) оставить все как есть и продолжать информировать людей, что они должны внедрять практики обработки исключений, точно так же как в обычных приложениях
Работает не очень хорошо, особенно учитывая приток новых пользователей. Это значит, что чем более популярна будет программа, тем больше новых пользователей будут пробовать скриптинг, и тем больше из них придется иметь дело с исключениями. Плохо масштабируется.
b) запускать скрипты в изолированной среде, по сути, создавать маленькие отдельные исполняемые файлы, которые взаимодействуют с "главной" программой через какой-то шустрый транспорт
Лучший вариант, но с технической точки зрения чрезвычайно сложный, особенно учитывая, что эта "маленькая" программа должна будет общаться с главной с очень низкими задержками, иначе это просто не будет работать для реальных применений. В какой-то момент это станет моей целью, но я оцениваю стоимость разработки в 3-4 месяца как минимум, что делает ее одной из самых дорогих потенциальных новых функций.
c) учитывая, что EyeAuras полностью контролирует исходный код и управление процессом выполнения, попытаться сделать весь процесс скриптинга максимально надежным и защищенным от ошибок
Это вариант, который мы попробуем сейчас. Я разработал тестовое решение, которое пытается перехватить все ошибки, возникающие в пользовательских скриптах, и вместо того, чтобы крашить приложение, пытается их обрабатывать, восстанавливать состояние (если возможно) и продолжать работу. Также я начну писать автоматические улучшения кода, которые будут применяться к пользовательскому коду во время компиляции - например, добавление правильной обработки исключений там, где это отсутствует (например, обработчики нажатий кнопок) или обработка исключений, выбрасываемых задачами.
Посмотрим, как это пойдет.
Еще несколько исправлений и улучшений в этом релизе:
GetService<T>, могла случайно освободить (то есть "убить") некоторые важные службы EyeAuras...В течение нескольких лет EyeAuras использовал механизм, который проверял результаты каждого перемещения мыши - он удостоверялся, что курсор действительно переместился в нужное место.
Исторически основной причиной для этого были аппаратные эмуляторы ввода, такие как Usb2Kbd и пользовательские устройства на базе Arduino. Для них это имело смысл, так как они не всегда мгновенно выполняют перемещение, что означает, что если у вас два ввода подряд (MouseMove + Click), есть шанс, что мышь не будет в нужной позиции, когда будет выполнен клик.
Теперь инструменты для отправки вводов стали гораздо мощнее - SendSequence, BehaviorTrees, Scripts, и этот механизм кажется приносит больше проблем, чем пользы.
В тестовом режиме этот механизм теперь отключен для всех методов ввода. В теории, это не должно быть сильно заметно в большинстве случаев, но имейте в виду, что вам, возможно, придется добавить некоторые дополнительные задержки между операциями перемещения мыши.
Добавлена полная поддержка Ctrl+C/Ctrl+V - ранее Ctrl+C был чем-то вроде механизма экспорта, что означало, что вы не могли просто скопировать элемент и вставить его в другую папку, так как это приводило к конфликтам. Теперь вы можете копировать и вставлять элементы повсюду так же, как вы это делаете в проводнике Windows. Также схема именования для клонированных элементов теперь следует той, что используется в Windows, например, если вы копируете "Aura", первый клон будет назван "Aura - Copy", второй "Aura - Copy(2)" и так далее.
Обратите внимание, что копирование-вставка элементов между несколькими экземплярами EyeAuras не работает! Для этого пока нужно использовать Export и Import.