По моему никак ! ... Стоп, что-тo там погрызенное в углу есть..
Но видно слабо и только на не отмеченном элементе.

Вообще ХайАсмм страдает некоторой ... Гм! "не интуитивностью" что-ли
- многое есть но попробуй догадайся как это сделать ..

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



В 3.6 148b FASM мыши погрызли наверное ... – хотя в какой-то из
прошлых версий кажется был. (Или его где-то еще искать надо?)

У меня тлько какой-то Fort -исходник на диске валяется.

FASM.F32
Smal32 assembler extension
Writen by Matway Burkov
....

Нашол тут
http://si-tech.ru/hiasm/down/reg.php?cmd=view&fname=./FASM
Но почему-то не качается! То есть качает но только все называет
reg.php...

AlexKir, умение воевать с виндой - это искусство
http://si-tech.ru/hiasm/forum/viewtopic.php?p=12916&#12916
http://si-tech.ru/hiasm/forum/viewtopic.php?p=12673&#12673

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

А можно подробнее?


Скрипшот По идее все элементы рисуются на основе текущей цветовой схемы Windows и не может быть чтобы его видно не было.


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


пакет FASM - это просто пример генерации кода на Ассемблере в HiAsm. Делать из него отдельный проект и развивать его нет ни времени, ни желания. Если кто-то заинтересуется думаю скачают.

А чего там еще подробнее !
Тыкаю в майнформ командую "КС"
Вставка и привет ...
List index out of Bоunds
Сйечас почемуто 73
Потом начтнает сыпать эти Bоunds с чистатой примеро раз в десять
секунд. начинаешь их закрывать через десять секунд
выпадает Acsses vilation at adress... Write of adress ..
Закрываешь через десять секунд снова. И дальше вроде тишина
но лучше схему закрыть .. (Разумется ничего не копирует.)

Ага вот только не у всех " баклажаны " - у меня так "классиик".
(Только фон черный что-бы буквы на дескопе в режиме
"непрозрачногсти"(опция "закрепить веб элементы") лучше было
читать.)
Скрипшот вот
(Даже скрин_кут)
http://www.alexkir.narod.ru/SC/SCR_Cut.jpg
"Народ" тормоз но быстрый фтпшник опять проглючило ..

Увидел. Исправлено.


У меня не "баклажаны", а собственная цветовая гамма. И то что изображено на скриншоте не является темой "Классик" да еще и оттенки рельефных элементов умышленно поменены местами - потому и схема отображается так "необычно" и претензии тут не умесны.

Вот чего хотелось бы....
Чтобы осталось пару дней на подумать до нового релиза. Ну чтобы успеть с некоторыми, возможно гениальными, замечаниями

Galkov, я думаю TCodeGenTools еще не один месяц будет дополнятся и дорабатываться. Так что в любом случае не стоит беспокоится.

Ну да, если бы народ дружною гурьбою кинулся реализовывать новые платформы (один - Forth, второй - C++, третий - Fasm), дело бы пошло веселее

Однако и на эту тему есть маленькое соображение:
1) Классификация - это конечно хорошо, но для соместимости "старых" кодогенераторов с будущими возможными интерфейсмыми нововведениями, хорошо бы ссылки на новые методы добавлять в конец структуры......
2) Интерфейсные фичи можно добавить и раньше самих фич...
Например, метод, сообщающий про состояние поля INIT в INI-файле элемента
И даже, наверное, можно продумать интерфейс (пока только его ) сообщающий о линковке свойства (не элементов ) элемента со св-м какого-то другого элемента.

1) Совершенно верно. Пока еще в стремление к красоте и порядку можно классифицировать. Потом конечно в конец.
2) Init и все прочее хотелось бы организовать по другому. Во-первых, нужен новый формат ini, в котором скажем будет специальное поля для флагом каждой точки(чтобы избавится от собак и плюсиков) ну и св-тв заодно(хотя пока это нигде не нужно). Затем ввести новую секцию скажем [User] все поля которой пойдут в кодогенератор(что избавит от расширений типа tpl и fast, которые нужны при генерации шаблонным методом). Очевидно что в этом случае сделать Init не составит никаких проблем.
а вот линковка св-тв это отдельная тема. Я представляю себе это как возвращение одного и того же идентификатора методом elGetPt для всех слинкованных св-тв. Т.е. кодогенератор даже не будет ни о чем знать.

Ну наверное. Тем более что вводить такую характеристику св-в, как "Only internal purpose" надо бы. Типа св-во в среде есть, и пользователь его исправно заполняет, но на коде это никак не отражается. Есть такие....
Тогда свойства для мультика, могли бы смотреться как залинкованные св-ва с каким-то из св-в элемента внутри схемы, но с флажком "Only internal purpose" снаружи мультика, и без него изнутри....

И вот еще, про то, "что генератор и знать не будет".
А кто будет разбираться, что картинку, например, в ресурс уже запихали, и больше не надо

По юольшому счету среда сама должна(либо кодогенератор) вылавливать такие моменты и сохранять в ресурсах только одну копию. Кроме того тоже самое нужно уметь делать не только для слинкованных св-тв, а для всех ресурсов вообще. Однако предусмотреть ф-ции propLinkIs и propLinkMain никто тем неменее не мешает

'
Схема "Классик" - честно !
Насчет рельефа ( я даже не сразу понял про что речь)
действительно в твикере ХП сделал "плоский виндовс" - но как
оно может влиять на ХайАсм ума не приложу...
(На ярлыки в виндовс никак не влияет ....)

Можешь кинуть картинку как это должно быть ?