Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#16: 2014-02-22 14:58:22 ЛС | профиль | цитата
Netspirit писал(а):
сделано все как-то через ...

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

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

0
Ответов: 4476
Рейтинг: 716
#17: 2014-02-22 15:15:50 ЛС | профиль | цитата
Конкретно показать не могу, и даже просто проверить свои предположения, потому что это требует достаточно большой работы. Поэтому мои слова можно проигнорировать.
А как можно удалять объект из самого себя - да элементарно: вызвать свой метод Free.
карма: 26

0
Ответов: 704
Рейтинг: 7
#18: 2014-02-22 15:23:12 ЛС | профиль | цитата
И имеем премиленькую ошибочку после второго нажатия на кнопку.
code_33142.txt
------------ Дoбавленo в 15.23:
А хочется чтоб не иметь эту ошибочку. Я конечно держу запасной вариант выносного отдельного приложения конкретно для отправки письма с запуском и убиванием оного при необходимости. Но это ж не спортивно! Помогите сделать перезапуск отправки!
карма: 0

0
файлы: 1code_33142.txt [1.1KB] [291]
Ответов: 1307
Рейтинг: 29
#19: 2014-02-22 15:25:22 ЛС | профиль | цитата
Neo писал(а):
выносного отдельного приложения


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

0
Ответов: 704
Рейтинг: 7
#20: 2014-02-22 16:07:40 ЛС | профиль | цитата
Если я не забыл свой опыт годичной давности, то DLL выполнялась в системном потоке. то есть тормозила систему отправкой почты. И пользы с нее я не получил. Использовать мультик с OnlyOnce
------------ Дoбавленo в 15.31:
Запутался в край. Что-то многовато проблем с этим SMTP
------------ Дoбавленo в 16.07:
Ну разве это нормально, что он зависает навсегда, если нет ответа сервера?
карма: 0

0
Ответов: 9906
Рейтинг: 351
#21: 2014-02-23 08:04:12 ЛС | профиль | цитата
Netspirit писал(а):
- да элементарно: вызвать свой метод Free

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

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

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

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


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

0
Ответов: 4476
Рейтинг: 716
#22: 2014-02-23 12:27:10 ЛС | профиль | цитата
Да, именно элементарным является понятие что после Free нельзя обращаться к своим полям.
Но "внешнее" удаление тоже не всегда может удовлетворить этим условиям, если "внутри", например, работает параллельный поток. Поток перед этим нужно будет остановить.

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

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

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

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

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

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

0
Ответов: 9906
Рейтинг: 351
#23: 2014-02-23 13:52:22 ЛС | профиль | цитата
Netspirit писал(а):
то уничтожение из себя должно работать вполне корректно.

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

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

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

карма: 9

0
Ответов: 704
Рейтинг: 7
#24: 2014-02-23 13:59:21 ЛС | профиль | цитата
Я конечно понимаю, что такие высокие материи важнее непоняток с SMTP, но было бы хорошо если бы все-же уже указали однозначно направление решения оной проблемы. Ведь не я тему начал значит не один мучаюсь этим вопросом. А если лень разжёвывать, так не мусорите тему
карма: 0

0
Ответов: 9906
Рейтинг: 351
#25: 2014-02-23 14:13:31 ЛС | профиль | цитата
А у Вас, что проблема убить контейнер по тайм-ауту
Надо обязательно, чтобы кто-то это сделал за Вас в виде скрипта

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

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

0
Ответов: 704
Рейтинг: 7
#26: 2014-02-23 14:31:23 ЛС | профиль | цитата
Galkov, может Вам велосипед нужно? Вот Печкину помогло )))
Я уже писал, что убить не получается. Даже схему выложил с примером демонстрации ошибки при попытке удаления. Не барское дело помогать с такой "мелюзгой"?
карма: 0

0
Ответов: 4476
Рейтинг: 716
#27: 2014-02-23 14:55:28 ЛС | профиль | цитата
Galkov писал(а):
Возьмем (к примеру) HUB
Согласен, свойства типа "array of THI_Event" я упустил из виду.
Но, тем менее, вот инициализация связей у хаба:

Hub_18FAAA0.onEvent[0]                   := _DoEvent(Label_30F9760._work_doText,0);
Hub_18FAAA0.onEvent[1] := _DoEvent(Label_30F99E0._work_doText,0);
Hub_18FAAA0.onEvent[2] := _DoEvent(Label_30F9A80._work_doText,0);
Предлагаемая деинициалиция:

Hub_18FAAA0.onEvent[2].Event := nil;
Hub_18FAAA0.onEvent[1].Event := nil;
Hub_18FAAA0.onEvent[0].Event := nil;
После Free на первом событии хаб просто вхолостую пробежится по остальных событиях. Вот только в THIHub.doEvent есть обращение к полю FOutCount - в данном частном случае можно добавить сохранение этого поля в локальную переменную.
А, нет, поспешил с выводом - ведь и сам массив будет уничтожен. Ну, предусмотрит автор схемы, чтобы ##clear/##delete был последним внутри контейнера. Сейчас ведь тоже должен много чего городить, чтобы удалить текущую копию схемы.

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

0
Ответов: 9906
Рейтинг: 351
#28: 2014-02-23 15:06:46 ЛС | профиль | цитата
Neo писал(а):
Даже схему выложил с примером демонстрации ошибки

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

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

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


------------ Дoбавленo в 15.06:
Netspirit писал(а):
После Free на первом событии хаб просто вхолостую пробежится по остальных событиях.

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

1
Голосовали:Netspirit
Ответов: 4476
Рейтинг: 716
#29: 2014-02-23 15:12:49 ЛС | профиль | цитата
Ладно, согласен, есть проблемы. Спасибо за наставления. Но, если проблема только в том, что после вызова ##delete из самого себя ничего больше не стоит вызывать, то думаю авторы схемы это осилят.
карма: 26

0
Ответов: 9906
Рейтинг: 351
#30: 2014-02-23 15:21:20 ЛС | профиль | цитата
Думаю, что не осилят. Те, для кого сформировать "отложенное" событие - проблема, нифига не осилят.
И именно исходя из таких мыслей, сделан более сложный алгоритм проверки "на самого себя".
Это не "через ...", это - учет возможной условно неограниченной рекурсии.
карма: 9

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)