Несколько предложений по C# макросам

[famous1144]

Что легко реализовать:
project.Context словарь сейчас сделан как <string, object>, и в нем неудобно хранить лямбда-выражения. Т.е. сделать сразу project.Context["Logger"]("сообщение"); нельзя, придется сначала приводить объект к типа Action<string>;
Решение: поменять тип словаря с <string, object> на <string, dynamic>.

Что сделать сложнее, но можно:
1. Сделать IContext и ILocalVariables стандартными словарями, чтобы было удобнее их перебирать и т.д.
2. Было бы неплохо расширить класс ILocalVariable, добавив в него методы ToInt, ToDouble и т.д. для удобного получения данных из них.

Что сделать сложно, но очень желательно:
При отладке, если хоть в одном макросе на C# ошибка, проект выполняться не начинает. При этом очень сложно найти место ошибки, если перед последним запуском отладки редактировал несколько макросов. Думаю, стоит сделать какое-то выделение макроса, в котором было брошено исключение или ошибка синтаксиса.


В остальном, программа движется в правильном направлении, хоть и не быстро

 

[schnaps]

3. полностью за
2. тоже
1. что то я так и не попробовал эту фишку, но пусть тоже будет

 

[iDnx]

При этом очень сложно найти место ошибки, если перед последним запуском отладки редактировал несколько макросов.

Даже после нахождения ошибки и исправления, код перекомпилируется через одно выполнение (без запуска проекта сначала), что не очень удобно.

 

[darkdiver]

Что легко реализовать:
project.Context словарь сейчас сделан как <string, object>, и в нем неудобно хранить лямбда-выражения. Т.е. сделать сразу project.Context["Logger"]("сообщение"); нельзя, придется сначала приводить объект к типа Action<string>;
Решение: поменять тип словаря с <string, object> на <string, dynamic>.

Что сделать сложнее, но можно:
1. Сделать IContext и ILocalVariables стандартными словарями, чтобы было удобнее их перебирать и т.д.
2. Было бы неплохо расширить класс ILocalVariable, добавив в него методы ToInt, ToDouble и т.д. для удобного получения данных из них.

Что сделать сложно, но очень желательно:
При отладке, если хоть в одном макросе на C# ошибка, проект выполняться не начинает. При этом очень сложно найти место ошибки, если перед последним запуском отладки редактировал несколько макросов. Думаю, стоит сделать какое-то выделение макроса, в котором было брошено исключение или ошибка синтаксиса.


В остальном, программа движется в правильном направлении, хоть и не быстро

ok, добавил в TODO

Даже после нахождения ошибки и исправления, код перекомпилируется через одно выполнение (без запуска проекта сначала), что не очень удобно.

можно пошаговую инструкцию как воспроизвести?

 

[iDnx]

1. Пишем код с ошибкой.
2. Выполняем это действие.
3. Получаем ошибку о компиляции кода.
4. Исправляем ошибку.
5. Снова выполняем это действие.
6. Снова получаем ошибку о компиляции.
7. Выполняем это действие и получаем результат.

Можно выполнять проект сначала на 5-ом действие и все заработает, но тогда переменные будут иметь значение по-умолчанию, что неудобно при отлаживании больших проектов с большим количеством переменных.

 

[darkdiver]

спасибо воспроизвел, занес в багтрекер.

 

[darkdiver]

Что сделать сложно, но очень желательно:
При отладке, если хоть в одном макросе на C# ошибка, проект выполняться не начинает. При этом очень сложно найти место ошибки, если перед последним запуском отладки редактировал несколько макросов. Думаю, стоит сделать какое-то выделение макроса, в котором было брошено исключение или ошибка синтаксиса.

Дык Double click на записи в логе прекрасно работает, и переносит к тому действию, где ошибка компиляции.
Если ошибка произошла в каком-то действии, то по двойному клику в логе будет осуществлен переход к этому действию.
Вот видео записал http://screencast.com/t/uHJ5LOpAL
Более того после клика можно посмотреть в какой строке ошибка и перейти на нее нажав Ctrl+G

Еще вариант http://screencast.com/t/OIJQn5vKYZ4
Ткнуть правой кнопкой мышки на запись в логе, скопировать id действия, перейти к редактору, нажать Ctrl+F и найти по id действия.

 

[famous1144]

Дык Double click на записи в логе прекрасно работает, и переносит к тому действию, где ошибка компиляции.

Спасибо, одной проблемой меньше Может, есть еще какие-то удобные фичи, облегчающие жизнь?
Кстати, забыл в ОП-посте написать тоже по поводу макросов в проект-мейкере. Если есть цикл, который по каким-то причинам стал бесконечным(или просто много чего делает), то он не остановится при нажатии кнопки "стоп", при этом кнопки управления процессом выполнения будут неактивны.
Вариант решения в идеале: при нажатии кнопки стоп после небольшого таймаута(5-10сек) прибивать поток через .Abort();
Вариант решения быстрый: сделать флаг, типа project.IsStop и можно будет проверять(например while(!project.IsStop){...}).

 

[darkdiver]

project.IsStop - можно сделать, а вот обрывать поток реально проблемно, уже много раз возвращались к вопросу, пока нормального решения нет.

 

[famous1144]

project.IsStop - можно сделать, а вот обрывать поток реально проблемно, уже много раз возвращались к вопросу, пока нормального решения нет.

Мне казалось, что все действия компилятся в C# код и выполняются в одном потоке, последовательно. Почему нельзя хранить его как поле в классе и прибивать при необходимости? Но если будет project.IsStop - тоже очень неплохо, потому что сейчас нет даже этого. Сейчас у меня некоторые действия выполняются в специальной обертке, типа Executor.Run(Action Closure, int TimeOut = 3000). Когда время ожидания выходит, генерится исключение.

 

[MicroOriki]

Поддерживаю чтоб выделял макрос или хотяы какой именно блок C# глючит, иногда 2-3 блока одновременно приходится менять, потом два часа ищешь ошибку)

И конечно хотелось чтобы при нажатии на кнопку стоп ProjectMaker убивал процесс полностью. Например отправку капчи, ведь пока не придет капча то остальные кнопки неактивны, а иногда капчу жэдать приходится 30 секунд