"Так вот, система не находится в ожидании действий пользователя. Объект перемещается – все значения пересчитываются. Пересчитываться должны и параметры, это определено в программе, получена и отработана команда - VALUES "tx" RANGE (STW(ePOSy)/1000 * GLOB_SCALE,]"
- находится. постоянно.с момента нажатия на кнопку Power(не, ну может быть пара секунд проходит в "свободном полете", до приглашения зайти в биос). В любом уважающем себя пакете есь функция OnIdle() - т.е "на простой" - базы данных в это время проверяют структуру, оптимизируют данные и протча, арч делает примерно тоже, А ИНАЧЕ ГРЕЕТСЯ ПРОЦ на холостых оборотах, но как только поступает сообщение OnMouseMove() вся закулисная работа уходит на задний план. Таким образом система всегда ждет нашего участия. Alakk говорил об этом.
Скрипт GDL "работает" - а точнее - компилируется - только "один раз" - в момент загрузки объекта в библиотеку, при создании проекта, или добавлении объекта к загруженным библиотекам, после этого вся "получаемая от объекта" информация минуя GDL-скрипт как таковой, обрабатывается функциями *.dll-s размещенными по дороге
C:\Program Files\Graphisoft\ArchiCAD 12, с учетом изменения Environment Variables связанных с работой объекта, с Run Time Type Information, если ближе к теме.
Терь, что касается темы:
Глючит в данном случае не интерпретатор GDL. Такова его работа, таковы его задачи. Это не ООП!
Дело в том что на момент первой компиляции GDL объекта(загрузка объекта в пространство имен текущего проекта) - компиляция происходит с дефолотовыми значениями,
если возникают неувязки выдается ошибка и объект не подгружается и выглядит черной точкой.
Но когда происходит интерактивное редактирование, то компилятор(скажем так, хотя на самом деле это уже работа одной из функций одной из длл арчикада) не может предполагать какой шрифт(или стиль текста - Define Style) окажется "выбранным" в объекте, точнее его это не интересует ибо шрифты везде разные, а еще точнее у него и нет задачи вернуть значение "вовремя" (вот в этом и парадокс! GDL<>ООП!), эта функция всего лишь запишет возвращаемое любой функцией типа RunTime(в данном случае речь о STW()) в массив RTTI (Run Time Type Info) , сделав соответсвующий запрос к Винде, что для "статичных" объектов вполне сносно работает(!) - напишите изменение стиля через параметр ГДЛ объекта - проблемы с STW в скрипте не будет!
Но другое дело когда одна функция типа RunTime зависит от другой функции типа Runtime, в данном случае HotSpot2 и STW. Надо понимать, что при перемещении Hotspot2 работает не ГДЛ скрипт, а его давно скомпилированный код, а написать взаимоувязанную работу двух Runtime функций, это вам не хухры! Со всеми исключениями времени исполнения! Это отдельный глубокий предмет! Называется SEH - Structured Exception Handling, да и не стояло такой задачи!
Проще сказать разработчики подумали примерно так - проблема будет решена на стороне клиента(или не будет возникать совсем - для статичных объектов) - например как показал Valery W, или как решили ее Вы в вашем объекте отметка - суть одна - чтобы ширина строки была возвращена корректно нужно "запрашивать" свежую RTTI, что и происходит по строчке:
unit2=tx-stw(fixVal_Y)/ 1000 * GLOB_SCALE
if unit2>0 then unit2=0,
проходит еще один вызов stw(), и теперь для данной части скрипта "дефолтовым" значением становится измененное значение возвращенное STW().
Вот такой вот DDE-механизм(Do Data Exchanging) путем GDL-трюков...
Не самый надо сказать педальный конь из педальных коней.