У Вас есть возможность показать как надо делать. Не "через ..."
Хотя бы для того, что бы продемонстрировать, что к Вашим словам можно относиться серьезно.

И как можно удалять объект из самого себя.

Конкретно показать не могу, и даже просто проверить свои предположения, потому что это требует достаточно большой работы. Поэтому мои слова можно проигнорировать.
А как можно удалять объект из самого себя - да элементарно: вызвать свой метод Free.

И имеем премиленькую ошибочку после второго нажатия на кнопку.
code_33142.txt
------------ Дoбавленo в 15.23:
А хочется чтоб не иметь эту ошибочку. Я конечно держу запасной вариант выносного отдельного приложения конкретно для отправки письма с запуском и убиванием оного при необходимости. Но это ж не спортивно! Помогите сделать перезапуск отправки!

просто дллку сделай...

Если я не забыл свой опыт годичной давности, то DLL выполнялась в системном потоке. то есть тормозила систему отправкой почты. И пользы с нее я не получил. Использовать мультик с OnlyOnce
------------ Дoбавленo в 15.31:
Запутался в край. Что-то многовато проблем с этим SMTP
------------ Дoбавленo в 16.07:
Ну разве это нормально, что он зависает навсегда, если нет ответа сервера?

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

Метод Free, несмотря на название, общепринятым методом не является. Его код должен удовлетворять некоторым специальным условиям.
После освобождения памяти, нельзя обращаться к ней же (к полям объекта). Впрочем, после вызова Free - тоже нельзя.
И код этого метода писали люди, это понимающие. Которые отучились произносить "элементарно".

Вышеозначенным условиям удовлетворяет "внешнее" удаление. А "внутреннее" - не удовлетворяет. Хотя бы потому, что автор схемы, после "вызова своего метода Free", обязательно захочет сделать чего то еще. И, по большому счету -- будет прав, таковы правила создания схем.

Вот это является ЭЛЕМЕНТАРНЫМ, а не то, что Вы имели смелость произнести.


------------ Дoбавленo в 08.04:
Куда катится мир: элементарные вещи приходится разжевывать, класть в рот - и все равно глотать не хотят

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

Мне об этом известно. И на это, я считаю, есть очень простое решение (в связи с нереализованностью которого в текущих контейнерах я и высказался про "способ их реализации").
Как сейчас инициализируется контейнер:
1) Создаются вложенные компоненты (ElementXXX := ThiElement.Create)
2) Вызывается Init для визуальных компонентов (вроде)
3) Заполняются свойства компонентов, для организации связей между точками. После этого компоненты могут взаимодействовать между собой и с внешней схемой.

Как уничтожается контейнер:
1) Вызываются деструкторы внутренних компонентов (ElementXXX.Destroy)

Спрашивается, почему перед этим не обнуляются связи между внутренними компонентами? Естественно, внутри после ##clear автор схемы может вызвать ещё что-нибудь.

Если уничтожение сделать в виде:
1) Обнулить связи между компонентами
2) Вызываются деструкторы внутренних компонентов (ElementXXX.Destroy)

то уничтожение из себя должно работать вполне корректно.

Также нужно кардинально переработать базовые классы контейнеров и их внутренних схем, а также их кодогенерацию (это та большая работа, о которой я говорил выше) с целью того, чтобы контейнер создавался в родительском компоненте как и любой другой элемент через ContainerXXX := ThiContainerXXX.Create с последующим заполнением связей. А не как сейчас через какие-то глобальные функции (хотя я не настаиваю). И уничтожался через ContainerXXX.Destroy, в процессе которого контейнер для каждой дочерней схемы вызывает обнуление связей, и Destroy экземпляра, уже в котором уничтожаются собственные внутренние компоненты.

Не должно.
Таковые утверждения следует сопровождать более убедительными аргументами, чем просто декларациями. ИМХО.

Возьмем (к примеру) HUB. Верхняя связь которого подключена через десятое колено к самоуничтожению.
Мне совершенно непонятно, чем "обнуление связей" поможет (хотя бы!) от падения кода метода (вызвавшего верхнюю связь) при обращению ко второму, уже "обнуленному полю".
Этого второго поля уже тупо нет. Какой смысл обнулять то, чего тут же будет уничтожено.

Т.е., мне понятно, почему сначала не обнуляются связи

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

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

Так я, видимо, огорчу Вас своим мнением: если для Вас составление некого алгоритма является мучением - Вы занимаетесь не своим делом.

Про мусор: именно такие темы и являются "мусором".
Не ну давайте продолжим: "Можно ли добавить событие onerror или timeout в FileStream компонент?"
Богатая тема, в таком духе можно долго продолжать.

Galkov, может Вам велосипед нужно? Вот Печкину помогло )))
Я уже писал, что убить не получается. Даже схему выложил с примером демонстрации ошибки при попытке удаления. Не барское дело помогать с такой "мелюзгой"?

Согласен, свойства типа "array of THI_Event" я упустил из виду.
Но, тем менее, вот инициализация связей у хаба:
Предлагаемая деинициалиция:
После Free на первом событии хаб просто вхолостую пробежится по остальных событиях. Вот только в THIHub.doEvent есть обращение к полю FOutCount - в данном частном случае можно добавить сохранение этого поля в локальную переменную.
А, нет, поспешил с выводом - ведь и сам массив будет уничтожен. Ну, предусмотрит автор схемы, чтобы ##clear/##delete был последним внутри контейнера. Сейчас ведь тоже должен много чего городить, чтобы удалить текущую копию схемы.

Neo, там в SMTP используется упрощенная реализация соединения по TCP. Надо просто более тщательно проверить обработку ошибок. Или использовать в коде TCPClient.

Не увидел проблемы.
Увидел отсутствие понимания тех самых "высоких материй".
Полный же бред нарисован.

Т.е., по методу обезьяны: сначала притулил одно к другому, а уже потом начинаем разбираться что к чему.
А надо наоборот.

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


------------ Дoбавленo в 15.06:

Неправда Ваша.
Он даже не узнает, что эти события "холостые".
Потому что хаба уже больше нет.
Убили его. Нету его больше. Нету вместе с "холостыми связями".

Ладно, согласен, есть проблемы. Спасибо за наставления. Но, если проблема только в том, что после вызова ##delete из самого себя ничего больше не стоит вызывать, то думаю авторы схемы это осилят.

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