Nic, Последняя версия кодогенератора, пакета, среды, .NET, плагин синтаксического редактора, NT5.x x86.
Пытаясь написать простейшее приложение из нескольких элементов поймал семью тараканов и пару малозаметных плодовых мушек. Ниже только начало списка, остальные добавятся когда (если) будет свободное время.

Например, в текстовые свойства элементов нельзя записывать символы, используемые в синтаксисе целевого языка. После первых же двойных кавычек получается инъекция кода code_27861.txt Похоже, целесообразнее решить это сразу на уровне кодогенератора, настраивымими механизмами автоэкранирования строк в зависимости от целевого языка.

Плагин не может найти код в папке code, встаёт на первом же пробеле в пути (Could not find file 'C:\Program');

Окно редактора по CTRL+W не помнит старого положения и размера; ------------ Дoбавленo в 14.55:

Включен режим сохранения исходников. Складывается впечатление, что кодогенератор не очищает\удаляет файл исходного текста (буфер?) перед новой записью и, если убираем какие-либо элементы, сокращая тем самым исходный код, он пишется прямо поверх старого, оставляя "хвостик" из мусора от предыдущей компиляции с вытекающими. Сперва думал, что файл блокируется от удаления, скажем, плагином просмотра текста, но повторная попытка компиляции проходит успешно, т.е. мусора не остаётся, даже если открыт плагин со старым текстом. ------------ Дoбавленo в 15.02:

Путём по умолчанию (рабочей папкой) запущенное из конструктора приложение считает не папку со своим SHA, а корневую директорию HiAsm; ------------ Дoбавленo в 16.33:

---

Когда будут вводиться элементы кодирования строк в URI, есть идея НЕ использовать HttpUtility.UrlEncode, HttpUtility.UrlPathEncode и прочие Server.UrlEncode. Как это не редко бывает, у M$ некорректная реализация, нарушающая все RFC. То пробелы плюсами заменяют, то неправильно перекодируют или вообще не перекодируют знаки пунктуации, например, могут оставить в строке пробел или пару слипшихся процентов. В соответствии с RFC следует брать текст в UTF-8, фильтровать символы выражением [^a-zA-Z0-9\\.\\-_~], если код символа имеет старшую часть (больше 255), то вместо него конструируем строку из двух шестнадцатиричных представлений байт кода символа.

По поводу первого пункта - "це не баг, це фыча". Dilma где-то в ранних темах писал, что в кодах элементов не должно быть никаких проверок на валидность - все проврерки должен делать сам Разработчик.

iarspider, сомневаюсь, что он имел в виду именно этот (низкоуровневый) вид ошибок. Перебирая условные кубики, искать в чём проблема по логам компилятора, нашедшего ошибку в коде, созданном генератором на основе ещё одного кода - мазохизм для гуру, и полный идиотизм для конечного пользователя. Так целевой аудиторией навечно останутся крутые разработчики, которым конструктор - игрушка и повод потусоваться на форуме

Поправил



добавил



исправил на SVN



исправил на SVN

Nic, теперь проекты запускаются через проводник и дважды блокируются службой безопасности (как не доверенные и с неизвестным производителем), конструктор не может отслеживать и влиять на их работу. Схема может остаться скрыто работать, а конструктор будет показывать останов (проводник закрылся). При повторной попытке компиляции останется старый файл, который теперь будет запущен дважды.

Сужу по аналогии. В пакете Windows, при наличии папки с SHA, текущей будет именно она.

поправил на SVN

Веб-запросы, создаваемые в 33-й строке HTTP_Get:

blk.println('HttpWebRequest ', this.hr, ' = WebRequest.Create(', d("URI"), ') as HttpWebRequest;')

не доступны из контекста, скажем, обработчиков событий:

Add(HTTP_Get,13566987,105,84)
{
 URI="http://ya.ru"
}
Add(Button,14245245,63,91)
{
 Left=40
 Top=140
 ImageList=[]
 Point(onClick)
 link(onClick,13566987:doStop,[])
}
Add(Button,12774355,63,56)
{
 Left=40
 Top=140
 ImageList=[]
 Point(onClick)
 link(onClick,13566987:doDownload,[(100,62)(100,90)])
}

error CS0103: The name 'hr2' does not exist in the current context
А вот из своего контекста, естественно, без проблем:

Add(HTTP_Get,13566987,105,84)
{
 URI="http://ya.ru"
 link(onDownload,13566987:doStop,[(149,90)(149,94)(93,94)(93,97)])
}
Add(Button,12774355,56,84)
{
 Left=40
 Top=140
 ImageList=[]
 Point(onClick)
 link(onClick,13566987:doDownload,[])
}

fixed

HTTP_Get (да и не только ему) требуется зачаточный структурный обработчик исключений(с точкой onError?). Так, если сервер выдаёт ошибку HTTP (например, любимую всеми 404), приложение благополучно вылетает в штатный обработчик, предлагая отметить опечатку в адресе или безвременную кончину web-страницы аварийным завершением приложения. К сожалению, пока в целевом языке я - "минус один", могу ткнуть пальцем в небо, но может пока изобразить один обрабочик на всех, в виде элемента или точки основной формыконсолибиблиотеки, порождающих события, из которых можно будет понять где и какое исключение произошло Естественно, речь о тех элементах, которые не мирно возвращают свои состояния, а именно порождают исключения.

Try

Что-то теперь, после обновления с SVN (724), make_CNET.dll не запускает полученный exe под NT6.x x64 (вручную запускается). Меняю на старую (не скажу точно, какая ревизия SVN) - запускает. Я смотрю, у разработчиков в компиляторах лежит MiniGW, используемый при сборе кодогенераторов.

Не подтвердилось:

Nic, Глюк пропал после полной переустановки конструктора. Видимо, с чем-то был конфликт, кнопка запуска компилировала, но приложение не показывалось (то ли не стартовало, то ли сразу завершалось). Причём в шпионахмониторах никаких ошибок доступа к файлу приложения не наблюдалось. Стоило сменить библиотеку - начинало запускать. Ладно, практика дальнейших наблюдений покажет.
------------ Дoбавленo в 10.37:
NT5.x x86 HiAsm4 SVN724. Опять перестал работать запуск, вернее - сами приложения. Теперь ещё веселее. Перестал работать он во время игр с цветом фона формы. Сперва цвет устанавливался нормально (чёрный и разные виды серого). Но стоило поставить clWindow (у меня это - белый 0xFFFFFF), среда компилирует нормально, но получается самоубивающийся файл, причина, вероятно, вот в таком интересном "белом":

Возможно, это же было причиной проблем на NT6.x, но там у меня хотя бы вручную запускалось, тут же получаем абсолютно неработоспособные exe. Проверил на .NET 2, 3.5, 4
------------ Дoбавленo в 10.49:
При этом цвет clWhite = 0xFFFFFF (255,255,255) - работает, не работает именно clWindow (который, по идее, численно тот же). Вообще проблемы со всеми системными цветами, являющимися ссылками на цвета темы. Работают символьные имена цветов типа clRed, clBlack и т.п. Не работают имена цветовых констант темы типа clWindowFrame, clScrollBar.

Редактировалось 7 раз(а), последний 2025-01-20 14:13:52

Вечером поправлю.