Набор(6 шт) компонентов для работы с типами, описание:
Type_Create - создает новый тип
Type_Add - добавляет переменные в существующий тип
Type_Set - устанавливает значение существующих переменных
Type_MultiMem - извлекает значения выбранных переменных
Type_Delete - Удаляет переменные из типа
Type_Array - позволяет работать с типом как с массивом
Более подробное описание в схеме, хелп я рисовал(именно рисовал) впервые, так что не пинать
В архиве есть иконка type.ico для вкладки Type, ее можно положить в ElementsDelphi abs
Скачать последнюю версию(лучше всего пользоваться последней версией с SVN)

Assasin, пинать не буду если скажешь где взять ShareMyType.pas .

где взять? Fatal: File not found: 'ShareMyType.dcu'
------------ Дoбавленo в 23.48:
будем пинать если не дашь нам ентот файл...

подход конечно интересный. Думаю такие элементы давно бы уже появились, если бы не слишком большой процент попадания DesignTime информации в конечное приложение. Поэтому МТ явилось некой альтернативой между удобством и эффективностью.

Замечания же после беглого осмотра можно сделать какие:
1) по onError мы давно уже выдаем коды ошибок, а тексты приводим в справке - это более универсально
2) в именах свойств лучше не использовать знак _
3) не совсем ясна полезность св-ва GType_Enabled

Я по этой причине почему-то проснулся ночью, проснулся и вспомнил "забыл в архив добавить ShareMyType.pas!"
Вот он заветный файл для уже скачавших архив выше, архив также перезалил
ShareMyType
Dilma,
1) хорошо, это поправлю, но только справку то я нарисую, а посмотреть ее никто не сможет, если только ее при установке компонентов не скопировать в Help
2) Исправил
3) Это свойство полезно в следующем code_15822.txt
------------ Дoбавленo в 08.35:
Да, кстати, я еще добавил имени не быть чувствительным к регистру, так что лучше заново скачать архив из первого поста
------------ Дoбавленo в 08.44:

Поподробнее, что еще за DesingTime?
------------ Дoбавленo в 11.30:
Еще раз перезалил архив:
Исправлен баг : Type_Create - невозможно очистить тип методом doClear
Для тех кто скачал:
Заменить файл ElementsDelphicodeType_Create.pas на этот

Это время проектирования прогрммы, то есть сборка в среде. RunTime - это уже время запущенной программы.

Зачем нужна верхняя точка GType, если в почти каждом компоненте есть параметр Name, где указыватся имя типа? Можно сделать его как менеджер, чтобы не было никаких точек GType и FType.
------------ Дoбавленo в 15.48:
И ещё: мне непонятна суть компонентов, т.е. для чего они могут быть использованы. Ведь новый тип переменной обычно отличается действительно новым типом хранимых данных (типа "картинка", "текст").

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


с точки зрения разработчика схемы предложенные элементы представляют улучшенный вариант МТ:
- каждое звено имеет имя
- и как следствие не привязано к строго определенному место в цепи(т.е. при считывании не нужно знать, где именно находится переменная)
ну и очевидно, что назначение такое же как у МТ. Однако за счет наличия имен можно придумать и более интересные решения.


------------ Дoбавленo в 16.05:
так же стоит добавить, что такой вариант МТ оптимальным образом переносится на пакеты класса FTCG и является гораздо более предпочтительнее классического решения - там проблем с избыточной информацией в RunTime нет.

То есть, это что-то типа записей в Pascal, где каждое поле имеет своё имя и может иметь любой тип.

3042, ну Assasin в туториале именно так и описывал

Dilma, а кто мешал в структуре TData ввести поле Name, тогда каждые переданные данные могли бы быть именованы. В структуре MT-потока, в таком случае, можно было бы именовать каждую цепь. Или это -- не так

nesco, тормознутости текущей реализации пакета стало мало?

Гы. Тормознутости хватает, но не думаю, что предложенная выше реализация (Type) будет работать быстрее
И как может лишнее поле сильно влиять на быстродействие, если мы передаем указатель на структуру, а не саму структуру, если только не копируем их, как при MT

речь идет не о реализации Type - речь идет о работе схем, в которых это вообще не используется


рассмотрим простой код из Share.pas
казалось бы две строчки кода, к которым добавление нового поля ну никаким боком не относится. Однако вспоминаем, что тип string это тот же самый класс, для правильной работы которого нужно вызывать конструктор и деструктор (в С и С++ это можно было бы увидеть воочию открыв исходник класса), а точнее в Delphi вызывается InitArray для каждого строкового и массивного поля из общего метода InitRecord. Отсюда получаем, что добавление <field>:string в структуре TData приведет как минимум к вызову одной лишней подпрограммы во всех методах, в которых есть локальные переменные TData вне зависимости от того, как где и когда они используются. На самом деле добавление поля sdata это уже было неверным решением, хоть и дающем в последствии некоторую простоту обращения с типом.

Да, все правильно, для локальных структур это существенно влияет на быстродействие, все верно ты написал. У меня совсем вылетело из головы, что под локальные переменные выделяется память, которая при уничтожении экземпляра, должна быть возвращена

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