Да, вот только что тогда сделает bd.LoadFromBitmap? Что ему загружать, если ничего не было сохранено? Надо тогда хотя бы 1х1 картинку сделать, или пометку <пусто> какую-нибудь

А там тоже должна быть проверка на nil

Assasin, в компоненте Type_Load исправь точки . OnLoad и onGet а точнее комментарии о том кто что содержит в потоке и при каких методах.

Assasin, я бы на твоем месте переименовал "Работа с типами" на просто "Типы". Твоя вкладка единственная, которая выделется на общем фоне

в догонку:

так писать не надо. Достаточно в хинте указать нечто вроде "Формат выходного пока", назвать св-во StreamFormat и сделать два значения вида StreamPack и INI. Все остальное в справку. Так же разделение методов на сохранение в файл и выдачу в поток тоже надо убрать и сделать по аналогии с HTTP_Get. Это касается обоих элементов.

PS: так же следует избегать в описаниях фраз типа "Описание этого св-ва смотри там-то" - от того, что текст будет продублирован хуже никому не станет, а пользователю не придется лишний раз бегать по ссылкам

Dilma, как я понял, пока компоненты достаточно новые, их конфиги можно свободно изменять? А то ведь сборка с типами в комплекте уже была (b184), а значит речь пойдет о совместимости...
P.S: вспоминая случай с nesco тоже про совместимость, не хотелось бы наступить на те же грабли

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

Ясно, спасибо.

То есть, ты про то, что шеф компоненты, которые никогда не будут востребованы, не включит в пакетсборку?

Не очень понял, что значит "выделяется на общем фоне", в каком смысле? Одна в этой области?

---

А теперь вопрос, получается PList при использовании метода PList.Clear каким-то образом вызывает деструкторы всех помещенных в него объектов? А я думал, что эти помещенные объекты надо удалять самому

Ты че, опять кальяном балуешься, ну где я написал про компоненты, которые не будут добавляться в пакет Я уточнил про изменения имен, в ответ на твои стенания про совместимость

И где там написано про невключение элементов в пакет

Ну нет у нас больше вкладок с название "Работа с...". Просто "Типы" напиши и все -- коротко и ясно

Есть!

Да какой там кальян - хуже!!! Я наконец смастерил загрузкусохранение переменных типа, в которых содержится МТ! Вот и у меня пока что все в радужном свете Теперь надо воплотить совет [b]Dilm[/]-ы про методы и комментарии, твой про вкладку и... и все вроде бы

Есть один вопрос. На данный момент в Share.pas ID типов данных идут вот так:
Раньше было так:
Не помню, зачем я это менял, но мне думается, что из-за этого при использовании отладочного режима схемы (с брейкпоинтами) среда принимает id data__type за data_break, и в результате дальнейшая отладка прекращается, вот тут это хорошо видно: code_21362.txt. Запустите отладочный режим и используйте трассировку, затем после ошибки уберите первый брейкпоинт и запустите на отладку снова, и как оказывается ошибка вовсе не в элементах Type, а в PNG. Вот на это я попался, когда искал ошибку в Type_Load.
Теперь сам вопрос: поменять ID data__type с data_break местами обратно?

А хрен тебя знает, но трогать стандартные идентификаторы не стоило бы, вот теперь и пожинаешь плоды

В PNG нет ошибки, а есть неправильное использование компонента, а если кто-то пытается считать нулевые данные, то это его проблемы

Да, я знаю, я имел ввиду что исключительную ситуацию вызывает элемент PNG, а не то, что в его коде есть ошибка.

Все-таки я лучше поменяю, большую часть времени была старая конфигурация, а значит менять ее нежелательно. Да, и кстати, проверил свою теорию на практике: замена id на старые не помогла, все-равно отладка проскакивает, однако виноват уже, по-видимому, не я.

нумерацию типов менять не стоит

Выложил обновления на svn