Как-то нелогично ведет себя сравнение - по идее, число должно проходить на выход только если оно МЕНЬШЕ отрицательного значения -100, а оно проходит в любом случае. Или я неправильно использую сравнение?

code_30831.txt
------------ Дoбавленo в 01.24:
Все, разобрался. Надо просто было конвертер добавить Str2Real. На вход подавался текст а не дробное число, отсюда такое интересное поведение.

Aziz, не внимательно читали чужие посты в теме "Идеи по развитию HiAsm-а"

Каюсь.. Тема уже огромная. Но, догадываюсь, это то что можно улучшить - чтоб среда не позволяла сравнивать разные типы данных, выдавая ошибку типа "Incompatible types". Хотя, странно что автоматическое приведение типов данных работает в элементе Memory - там не надо настраивать string, integer или real, просто оставляешь null в свойствах..

Все, нах. Меня, за мои идеи, уже тапками закидали в той теме. А одна из этих идей была как раз автоматизция типизации данных

В пакетах на основе кодогенератора RTCG также есть подобный механизм, определяемый разработчиком пакета в файле hiSys.hws и поддерживаемый вызовами из кодогенератора.

Ну-ну. Продолжайте дальше, в том же духе

Aziz, просто нужно помнить, что в IF_else сравнение происходит по типу данных оператора Op1.

Ясно, спасибо.. nesco, если доработаете автотипизацию, будет здорово.. Если не слишком трудоемко это. А так - Бог с ним, все равно 4-ка уходит в небытие с каждым днем, можно попользоваться конвертором..

Интересно "как", я вообще не занимаюсь 5-й версией, а последних исходников 4-й у меня нет

Ясно, я думал это в codegen'e 4-ки подправить можно.. Но видимо либо нельзя, либо нет исходников и на кодогенератор.

а её разве нет.
Пальчиком покажи, где она нужна.

Кстати, nesco, а какие-то (непоследние) исходники значит есть? Это уж новость.))
------------ Дoбавленo в 23.43:
Tad, см выше пример. "Автотипизация" в его контексте. А вообще спросите nesco, он лучше расскажет, за что его тапками забрасывали.))
------------ Дoбавленo в 23.48:
Ну если мое объяснение вас устроит - вот я домохозяйка к примеру, на кухне решила создать утилиту управления кухонным комбайном.)) И забыла вставить конвертор на пути текстовой переменной. В итоге, комбайн не выключился вовремя, двигатель его задымился и спалил всю квартиру.. А вы говорите автотипизация не нужна...

Aziz, Возмем компонент Math. Что ему на вход или верхние точки не подавай - он всё хавает как REAL.
И так любой компонент - преобразовывает тип под себя.
Вот я и спросил: А какой компонент так не делает ?

Исходники кодогенератора лежат на SVN
------------ Дoбавленo в 00.14:

Если бы она не была нужна, то никто не придумывал бы тип TData, который содержит аж целую структуру и не было бы тогда этих тормозов. Но вот нафиг нам парсить структуру на предмет вытягивания нужного типа, если нам дают этот тип из другого компонента, те нафиг нам определять тип каждый раз, когда достаточно определить конкретный конвертор там, где он нужен, а там, где не нужен использовать входные переменные напрямую
Или зачем читать верхнюю точку, когда данные идут из потока, и наоборот
------------ Дoбавленo в 00.18:
RTCG, вроде, позволяет типизировать данные, но это надо делать вручную. А хорошо бы это дело было автоматизировать, чтобы пользователь не заморачивался с типами вообще. Прицепил String к Integer -- получи конвертер в связи, прицепил String к String -- связь осталась чистой, используюй напрямую. Все эти телодвижения с конверторами должны быть хоть как-то визуализированы. ИМХО.
А может лучше бы было пойти по пути метода API dll. Каждая точка -- это какая-то функция или метод, никаких верхних точек, для их использования ставится специальный компонент перед точкой вызова с загоном верхних точек переменных в вызывающий метод. Тогда для каждой точки методов компонента могут быть определены только свои переменные и всегда типизированные. ИМХО

Вот и я про то же. И автоматизировано и пользователь не заморачивается. Потеря в скорости ?
За всё надо платить.
И за то, что "каждая кухарка..." тоже.