Если попытаться добавить в MT поток целочисленное значение нуль первым в цепочке, то, с сожалению, это не происходит:
code_14123.txt
Компонент MT_Add

в данном случае проблема не с МТ, а вот с такой записью
что делает кодогенератор, когда программист просит его сравнить _data='' ? он берет и приводит второй аргумент к типу первого после чего производит сравнение. Пустая строка конвертируется в целое число как нуль, т.е. получаем сравнение 0 = 0, что есть истина.

Чтобы этого избежать, нужно вставить проверку на тип данных

если бы не объявленный макрос NULL_TO_STR, то достаточно бы было сделать одну проверку типа
------------ Дoбавленo в 22.34:
еще один совет небольшой. Вот так:
лучше не делать. Лучше делать так

Что надо делать для InputMT=SendUp?

есть сомнения в том, что этим режимом кто-то когда-то пользовался. Я к примеру из описания к свойству ничего не понял о его назначении. Судя по коду в этом режиме данные передаются наверх и могут быть использованы только совместно с EventFromData. Если очень хочется поддержать этот режим, то необходимо пользоваться конструкцией вида

Даже заморачиваться с выкладыванием других схем не буду: на скриншоте элемент EventFromData видите ???
Он сначала делает ##Select (там "все" его делают, естественно), а потом принимает данные из другого экземпляра массива мультиков
Угадайте с 3-х раз, откуда берется индекс для этого ##Select
У меня есть варианты и передачи MT (в смысле - более одного вагончика с данными) наверх с последующим возвратом результата

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

Не уверен, что это правильно, но принятие данных сверху работает при любых значениях InputMT
code_14127.txt
Если есть соображения как это должно работать, то просьба объяснить "на пальцах"

Galkov, скриншот это замечательно, но понятнее из него ничего не стало. Вот три примера
code_14128.txt

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

Может быть добавить функцию, которая проверяла бы поток на наличие в нём данных?

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

Схемные изыски во многих случаях являются излишними.
Утверждения, что схемными изысками следует пользоваться всегда - не было
Было утверждение, что существуют случаи, когда эти изыски являются наиболее рациональным решением, если не единственным
Таковыми условиями являются:

"верхний" объект имеет много использующих его клиентов, и эти клиенты хотят передать ему некие данные (в общем случае - MT), и в ответ получить некие результаты (аналогично, в общем случае - MT)

по неким объективным причинам это не может быть копия или линк объекта - результаты его работы зависят от предыстории использования, и именно это является постановкой задачи.
Поскольку, существенным является слово "много", очень уж простой пример, да еще и обладающий неким смыслом - не получается
Но он может выглядеть так: code_14134.txt
Предполагаем здесь, что положение модальной формы, ее Caption - и есть те самые "параметры предыстории", которые обязаны воспроизводиться при любых запусках. Надумано, возможно, но на то он и тест

Не надумано - это рабочая схема
В ней "красно-восклицающий" мультик - это и есть мой "элемент", имеющий достаточное количество клиентов
Метод doData - просто предварительная накачка данных для последующей протокольной команды. Результатов после нее еще нет.
А вот после doCMD "выплевывается" весь пакет (начиная с самой команды), и принимается какое-то количество байт
В принципе, в протоколе у меня есть и очень "многобайтные ответы", но в данном тесте они не используются, ограничился 4 байтами и упаковал их в одно целое.
Приглядитесь, ничего надуманного...

Да, на всякий случай, способу возврата данных через глобальную переменную меня учить не надо - с этого начинал....
И потом учил iarspider-а "вертикальному программированию". Кстати, можете тоже оценить разницу (хотя данные наверх он и не передавал) http://hiasm.com/forum.html?q=3&p=89388#p89388

Вообще-то, "вертикальное программирование" заслуживает отдельной темы с предоставлением определенного количества примеров для понимания пользователями, тк такой возможностью пользуются единицы, а это -- весьма перспективное направление

Galkov, ок, пример демонстрирует удобство использования элемента в данном случае. НО каким боком он относится к "Добавление элемента в многомерный поток" Этот режим и Nul надо было выносить в отдельный инструмент (DoDataMT к примеру). Теперь же в погоне за совместимостью эта неоправданная экономия места еще и в другие пакеты полезет...

А был у нас отдельный элемент. Назывался Array, и это был не MT-вариант
MT-вариант - в MT-элемент и попал
Можно было вообще MT_Add разбить на 4 элемента.... Мне такое не очень нравилось
И есть у меня сомнения, что это начнет "кочевать". Будут проблемы. А совместимость, так это св-во - последнее, между прочим

Но вот что хочу добавить - это все безобразие я не считаю перспективным направлением.
Схемотехническим приемом - считаю.
Все это безобразие заменяет Pointer-элемент, и со значительно большей эффективностью.
Посмотрите "рабочую схему"...
Почти всякая команда является серией вызовов метода doData, и обязательно заканчивается вызовом метода doCMD
Т.е., я обязательно тяну от всех клиентов ДВА "жгута". А ведь их могло быть и три, и пять, да и 10 - не беспредел вовсе
А с Pointer-элементом - ОДИН, при любом раскладе.
И выходные данные не "паковал" бы - с этого магического элемента событие возникало бы столько раз, сколько мне надо, и в нужное мне место.
И Slave (физический адрес девайса, на который уйдет пакет данных) с Read (количество байт для чтения после окончания пакета) в глобальных переменных не передавал бы - верхние точки магического элемента спрашивали бы эти данные с нужного мне места.
И было БЫ все это очень правильно

Думаю, что такое качество данная схема демонстрирует в большей степени, чем SendUp

да никто и не спорит. Но в том, что есть сейчас расклад именно таков, как описано выше и он плох, по причинам выше так же изложенным.

Если причины выше и излагались, то таким образом, что остались недоступны моему пониманию.
В моем понимании, причин влияющих на раскладку в базовом пакете - НЕТ.