Вот расскажи, почему не надо
((а то ведь опять получается, что ты даешь челу рыбу, а не удочку))
Я это понимаю так, что в элементе просто нет защиты от "перегрузки"
Собственно, даже думаю, что если таковая появятся, то жизнь легче не станет ни на минуту
Другого-то как-то и в голову не приходит

Но тогда это именно "наложения"
И что тогда с такой "логикой":





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

А если не работает, значит элемент глючный
Или голова все-таки

Пробовал тоже самое за исключением того что приложение попросту виснет .

Дык по идее на каждую картинку приходится по одному HTTP_GET по логике вещей даже схема сервера не уничтожается до тех пор пока HTTP_GET не докачает картинку даже при методе Wait=False а после закрывается.
Наблюдал лично в процессах следя за размером памяти , даже Месенжер ставил на окончание закачки и пробовал в INI записать закачки закачивало всегда до конца даже при EROR естли не нажать на окне ошибки ранее кнопку OK.

tsdima, а чисто для интереса, у тебя TCP_Connection.onRead - синхронизировано, или нет

Какие-то вопросы ты, Galkov, задаёшь странные.
Ответить могу только так: если у тебя TCP_Client.onRead синхронизировано, то и у меня TCP_Connection.onRead - синхронизировано

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

Ну хорошо. Ну вылетает вышеприведённая схема. Ну допустим при вызове th.Synchronize( ShowInfo ) из-за того, что th левый. Извечный вопрос: кто виноват и что делать? Galkov, а?

Ну хорошо, можем ли мы утверждать, что ID потока для события из TCP_Client.onRead совпадает с ID основного потока проги (того, который делает ##open)

Или фиг его знает

А как должен работать динамический мультик, когда его убивают и при этом внутри него живёт другой Thread? Кто о бедном Thread позаботится?
------------ Дoбавленo:

Вот ты щас скажешь - деструктор! А и где он такой у HTTP_Get?
------------ Дoбавленo:

Опять, понимаете ли, динамическая нечистоплотность

Не давать его делать левым.
Насколько я понимаю, такое бывает при Wait=false, от этого
- без закрытия предыдущего Называется: не успеешь выполнить одно задание, как тут же не успеваешь выполнить второе...
А проверять - не задача элемента, ИМХО
Потому-что, проверивши, чего-то надо делать, а чего - элементу неведомо
Да и не должно быть ведомо...
Это задача схемы

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



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

tsdima, то, чего ты говоришь, имеет смысл при Wait=false
Или ты не особо доверяешь сообщению:

Нет там вроде никаких потоков.
Собственно, я потому про асинхронность и спрашивал...
------------ Дoбавленo:


А если нооборот: А как это его начинают убивать, когда внутри у него живет другой Thread?
Кто посмел?

Не доверяю. У меня с Wait=True работает без проблем.
------------ Дoбавленo:


Сокет закрылся, вот и посмел.

Это чего же получается: после onRead никто ничего не обещал
------------ Дoбавленo:

И по onDisconnect ничего нельзя предпринять

Ну почему-же. У нашего TSocket на этот счёт свой "synchronize"

Редактировалось 7 раз(а), последний 2021-05-21 04:11:39

А что, до сих пор не сделал?
Можно так:
code_8655.txt

я попробовал. теперь не падает во время работы, но при закрытии та же ошибка 216.

Редактировалось 7 раз(а), последний 2021-05-21 04:11:39

tsdima, а как насчёт моего вопроса , пришли к какому заключению ?