можно и одну, елси вставить определение доступности очереди в компонент. Как уже было напиасно выше вариант с подсчетом ссылок не срабатывает при активации удаления изнутри. Вариант же с синхронным сообщением не сработает в приложениях без очереди.

[size=-2]------ Добавлено в 10:28
к ранее предложенному дополнения в точках Work, можно дописать такое дополнение к точкам Event:

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

Пардон, но писались же в DOS-е интерфейсные программы без многопоточности и очереди сообщений.
И пусть в той DOS-овской интерфейсной программе мне приспичило уничтожить, а в этом конкретном месте - НИЗЯ.
Как бы я поступил: да сделал бы заказ на уничтожение, и в цикл обработки входных событий (мыша, клава, порты) добавил бы обработку этого заказа.
А вовсе не писал бы претензии дяденьке Борману (вроде тогда у меня был bc3.1), что они с динамическими объектами работают неправильно.
И что-то кажется мне, что именно такие действия были бы правильными...



Ну нельзя быть умнее папы римского
На уровне автора схемы, все просто - делаешь развязку в нужном месте. И точно знаешь, что она нужна, и нужна именно она.
Можно вообще этот NewTimer ставить вместо сегодняшней мессаги-предупреждения, БЕЗ заморочек со счетчиками ссылок - дешево и сердито.

Вот только какова причина сего проявления интеллекта
Вижу пока одну: есть желание УГАДАТЬ чего хотел, но не понимал, что так нельзя - пользователь

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

Понимание - во много раз важнее одной работающей (при этом - не факт, что правильно) программы. После этого все работать будут правильно, а не только эта одна.

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

И придумывать тут ничего не надо и угадывать тоже - в скриптах и managed коде существует отдельный механизм, который называется Garbage Collector. Примерно тоже самое, что я написал со ссылками.

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

Это - стиль.

Galkov, думаю не просто так народ предпочитает заниматься WEB программированием например на PHP или Java, а не на С++ через интерфейс CGI. А там за пользователя виртуальная машина принимает решение начиная от способа размешения и типа переменной, кончая временем и местом удаления неиспользуемых объектов. И наиболее популярными становятся как раз те из них, чьи разработчики нашли таки баланс между простой, удобством, скоростью разработки и эффективностью, количеством сделаных за пользователя работ. Видимо изначальная постановка задачи - обеспечение ф-ала, покрывающего большинство типовых задач, является более удачной, чем предоставление пользователю возможности подумать самому.

Не аргумент.
Оси вообще начинались со встроенного BASIC-а. И не просто так народ от этого отказался.
И все эти скриптовые языки предназначены для т.н. быстрого программирования
Имеет аналогом - макетирование изделия у себя на столе. Цель - чтобы заработало.
Когда ставится цель, чтобы работало ВСЕГДА (постановка в серию) - это совсем другая работа
Вообще-то - ОЧЕНЬ другая.

Область программирования довольно молодая область, и там полно лохов, не знающих АЗЫ в Технологии Создания Нового.
Это как техника безопасности - написана кровью...
После этого появляются заявления, что сделать надежный софт - просто невозможно. Могу привести цитату, скажем из Кладова.
Если бы я сообщил такое при создании embeded системы - на меня посмотрели бы как на идиота.
И кстати, не закладывать решения без 100% уверенности в безальтернативности первопричин - один из этих азов.
Угадать (что пользователь хотел этого) - не годится. Годятся Знания, что он именно этого хотел - тогда совсем другой разговор, конечно же.


Никогда не соглашусь с тем, что пользователю не следует думать о том, что самого себя удалять нельзя.
И что выбор способа принятия отложенного решения (например для проги, где отсутствует очередь сообщений) - это зона ответственности системы, а не пользователя.

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

[size=-2]------ Добавлено в 14:31
В принципе, то что я излагал - это Философия

Вот пример, как эта разница в философии отражается в кодинге:

есть системный контрол, который дает нотификации паренту

в KOL принято вешать для этого аттач к этому паренту, устанавливая одно из полей (Tag, CustomData, CustomObj) указателем на нужный нам объект.

этот аттач, определивши нужную мессагу, ПЫТАЕТСЯ привести соответствующее поле контрола к нужному типу.
А этого делать НЕЛЬЗЯ, если хочешь чтобы это работало ВСЕГДА
Вот тут и прочувствуйте разницу

Утверждаю, что нет никаких гарантий, что это пришло сообщение для нашего контрола. Даже если мы не нашли в MSDN никаких упоминаний о таком сообщении для других системных контролов - не факт, что таковые не появятся завтра.
Нет гарантий - нельзя писать такой код. Это тоже один из азов вышеупомянутой философии.
И то, что оно вот сейчас у меня работает - НЕ АРГУМЕНТ, абсолютно.

А вот Кладов считает, что так делать можно.
Но он не прав, вот и все

На этом уже попались в UpDowne и TrackBare. Там как раз были схожие обработчики и мессаги.

Galkov, о разных вещах говорим однако. HiAsm это уровень пользователя далекого от кода и его заморочек. И именно в таком ключе хочется думать и дальше. Отчего-то мне кажется что большинству по барабану можно себя убить или нет. Это та же самая проблема, что и с кольцеванием. По хорошему наша задача решить их обе, а не вбивать в голову пользователя, что хорошо, а что плохо и что можно делать и что нельзя. Думаю если хочется со всем этим заморачиваться, то стоит делать отдельный пакет и не лепить там ничего лишнего. Однако когда мы уже за пользователя решили, как строить элементы, как передавать данные в потоке, когда и чего в этот поток помещать и еще кучу всего, то подобные споры мне видятся лишенными смысла совершенно.

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

PS: в примере ниже объект удаляет сам себя. Есть желание доказать, что так делать нельзя

code_1865.txt

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

Вот сделали один раз св-во ShowModal. Типа облегчили ему понимание. А на самом деле - надурили - нет такого св-ва.
И получили (хоть и очень не сразу) претензию от того же пользователя 2-го уровня - старинный глюк в HiAsm, потеря св-ва модальности...
Ну и что, что это один из 100 Неправда - она и в Африке неправда.
То же самое и здесь: на самом деле напрямую удалять НИЗЯ, а мы пытаемся сделать вид, что можно.
И не надо пытаться, надо правду говорить.


Ответ: потому-что ты знаешь свой код
А я - нет, потому-что не знаю кода написанного пользователем, а функционирование от него будет зависеть.
У меня нет желания доказывать, что нет случаев возможности самоудаления
У меня есть желания выслушать доказательства того, что НЕЧТО возможно ВСЕГДА, и лишь после этого заносить в код
Именно доказательства, и именно всегда, примеры возможного - негодятся совершенно
Именно в этом философия состоит

Ну что ты упёрся? Ну можно себя уничтожить. В тех же Сях-плюсях никто не запрещает писать delete this; просто после этого не надо обращаться к полям объекта. Можешь даже какой-нибудь не виртуальный метод этого объекта вызвать, если тот не обращается к полям объекта (статический, например).
Просто в нашем случае сложно гарантировать отсутствие обращения к полям объектов.

постом выше привел пример сего действа из Delphi

Как верно было отмечено: убить себя очень даже можно. А вот к полям обращаться нельзя. И именно в стандартном Delphi пакете мы как раз таки гарантию дать можем поскольку вся информация о выполнение программы у нас всегда есть. Это в FTCG такие вещи всегда будут действительно чреваты.

Я знаю
Точно так же, как я знаю, что в электронике контакты без тока - работают.
Но НИКОГДА я не сделаю (и не делал) это в Изделии.
Потому-что я не радиолюбитель, а профессионал. И не только радио
А это не просто слова, это предполагает некоторую логику и философию. Которые, как отмечал выше - написаны "кровью"

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

[size=-2]------ Добавлено в 20:16
Блин, а обратных косых-то - и нету

Galkov, ну так и мы знаем, что можно-то можно, но делать так не стоит. В коде. А вот в схему такую ф-ность внести стоит. И реализовать в коде через очередь, ссылки или еше как-то. Впрочем может оказаться, что данная фишка не стоит тех затрат производительности, которые непременно возникнут у всех, кому она не нужна.

Именно так.
Отдельный элемент - это отсутствие затрат у тех кто его не ставил.

В этом плане про другое подумать следует: два режима кодирования - safe и release
В правильно работающей программе и тратиться не следует на проверки на глупость...

Естественно, safe в default-е

Может всё-таки как-нибудь стандартно обозвать: debug и release ?