Не совсем понял про "явную" и "неявную" типизацию в среде. Мне лично не хватает в ini задавать явные названия типов данных, выдаваемых точкой, хотя это все равно не решило бы многих проблем. Но в данном пакете эта проблема достаточно приемлемо решена: точки выдают специальную структуру, которая хранит тип данных и сами данные. Компоненты, считывающие эти данные, всегда могут проверить тот ли им тип поступил или нет. Примитивные типы данных и их автоматическая конвертация на этапе кодогенерации реализованы вполне хорошо.
Сейчас есть два варианта: сгенерировать код на основе известного типа данных и преобразовать/считать нужный тип в runtime. Первое - вполне хорошее решение и получаемый код ничем не отличается от написанного от руки. Второе нужно, когда типов данных может поступить несколько. Как такое реализовать в конечном коде другими способами - я пока не придумал. Поэтому каких-то пожеланий к среде у меня нет.

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

Это и имелось ввиду
Т.е. ставим преобразователь в виде элемента, который явно будет преобразовывать данные из одного типа в другой, иначе среда не позволит подключить float/real/double к integer и т.д.
Зато сколько опасных и неопределённых ситуаций можно было бы избежать.
Новички намного меньше на грабли будут наступать, да и не только новички
В общем, нужно перенимать опыт разных ЯП в этом плане.


Ну так и изменять свойства/точки динамически.
А так да, должна быть возможность из свойств или на основе свойств элемента изменять/создавать точки данного элемента.
Неважно как, это уже вопрос к реализации.

С этим не согласен: это загромождает схему. Когда есть возможность преобразовать из одного типа в другой - это нужно делать автоматически. Это сильно упрощает создание схемы, позволяя пользователю думать над алгоритмом, а не над правильностью соединений. А вот когда автоматическое преобразование невозможно, или неоднозначно, тогда можно не давать соединять точку и выводить над точкой сообщение почему именно нельзя и подсказку, как можно сделать правильно.

Это тоже зависит от реализации
Можно и так сделать:

или цветом выделять линию/точки, но пользователь должен явно видеть все места, в которых происходит преобразование и тут нужно быть очень осторожным.
А вообще, если приходится использовать преобразование для работы с элементом, значит элемент плохо продуман.
В случае если все элементы будут хорошо продуманы, методы элементов для работы с необходимыми типами данными реализованы, а среда на основе информации о типах точек/данных сама выберет наиболее подходящий вариант, то проблем вообще не должно быть.
Только в редких случаях придётся использовать преобразование данных.

Подскажите пожалуйста по схеме, ничего не пойму
Если выключаю отправку данных, то сообщения с командой от каждой кнопки появляются
Если включаю отправку, то появляется сообщение и отправляется только команда от первой кнопки
Laurent_2.zip

Ну, схема большая, подробно разобраться не могу. Попробуй нарисовать схему попроще: пару кнопок, TCPClient, сообщение.

ну видимо дело как раз в большом размере схемы, чтобы увидеть в чем проблема скомпилируй схему с включенной и выключенной галочкой Check

Обрати внимание на сообщения в панели Отладка при включенном флажке.
------------ Дoбавленo в 13.01:
Я так понимаю, это связано с порядком инициализации компонентов. Это когда инициализируется один компонент, он вызвает событие, которое соединено с методом Хаба и эта цепочка вызывает инициализацию другого компонента, который тоже вызывает метод этого Хаба.
Из-за большой схемы более конкретно выявить эту цепочку сложно. Но причиной в данном случае есть Хаб, который стоит перед Math и FormatStr, идущими на doSend. Поставь у него свойство Optimization=Size.

у меня почему то нет Optimization=Size

Еще вопрос, хочу чтобы кнопка пропала и через 1.5 сек появилась обратно, я что то делаю неправильно или это ошибка компонента?
code_36498.txt

На SVN есть.
Не знаю. Сейчас нет возможности проверить. Поэкспериментируй с параметрами кнопки, макета компоновки, параметрами анимации. Попробуй сначала одну анимацию, потом вторую, потом обе вместе.

по отдельности обе анимации работают как надо, где то в AnimationSet косяк наверно

Скорее всего в комбинации параметров. Так как в AnimationSet делается только добавление анимаций, а затем визуальный компонент просто воспроизводит их.

для работы с БД (mysql) пока нет компонентов?

Netspirit, а событие onTouch точно работает правильно? У меня только 0 выдает.
Смотрю была правка от 27.02.2015 по устранению ошибки в выдачи индекса в onTouch.

Это с указанной правкой не работает? Предполагается, что должно выдать 0 при нажатии, 1 при перемещении, 2 при отпускании.
Там особой обработки не производится, оно выдаёт только то, что приходит от системы. Может, от визуального компонента зависит.