Поймать ситуацию перетаскивания формы

Evg · Регистрация: 30.03.2009

Студворк — интернет-сервис помощи студентам

Имеется следующая функциональность. По нажатию на кнопочку создаётся новая форма, на которой должна быть картинка, скачанная из инета. Размер картинки заранее неизвестен, а потому при создании размеры формы имеют некоторое дефолтное значение.. Из неё рождается поток, который лезет в инет и скачивает картинку. Чтобы не возиться с отловом точки завершения потока, я обновляю картинку на форме прямо из потока. Поток создаю через TThread, так что всю синхронизацию по части компонент берёт на себя библиотека VCL. После прорисовки картинки на форме меняются размеры формы - подгоняются под картинку. Изменение размера формы делается в потоке. После чего поток успешно помирает.

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

А потому вопросы:
1. Можно ли каким-то образом заставить VCL адэкватно реагировать на изменение геометрии окна из потока, в то время как идёт перетаскивание окна в основном процессе.
2. Если по п.1 ответ отрицательный или излишне геморройный, то может быть как-то можно в основном процессе окна поймать ситуацию того, что сейчас идёт процесс перетаскивания окна (а точнее интересен момент завершения перетаскивания).

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

oxotnik · 05.10.2010, 12:00

Нельзя ГУЕм управлять напрямую из дочернего потока (не из потока ГУЯ)!
Из дочернего потока можно только слать сообщения основному, а в последнем их отлавливать и перерисовывать что надо.

Evg · 05.10.2010, 12:14 **[ТС]**

Сообщение от oxotnik

Нельзя ГУЕм управлять напрямую из дочернего потока (не из потока ГУЯ)!

В описании TThread (уже не помню где щас читал) одним из его достоинств было то, что из потока можно работать с гуем, а весь сопутствующий геморрой учтён в библиотеке VCL

Сообщение от oxotnik

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

А можешь вот этот момент объяснить. Или пример где-нить показать

@MikeSoft · 05.10.2010, 12:23

Сообщение от oxotnik

Нельзя ГУЕм управлять напрямую из дочернего потока (не из потока ГУЯ)!

Несколько не согласен. В TThread реализована "безопасная" отсылка сообщений, позволяющая обновлять интерфейс.

Evg, обновления границ формы необходимо выполнять из потока, через функцию Synchonize, данный метод гарантирует взаимодействие с методами VCL компонентов.

Цитирую:

C++
1
2
3
4
5
6
7
8
9
10
11
//   Important: Methods and properties of objects in VCL can only be
//   used in a method called using Synchronize, for example:
//
//      Synchronize(&UpdateCaption);
//
//   where UpdateCaption could look like:
//
//      void __fastcall TThread::UpdateCaption()
//      {
//        Form1->Caption = "Updated in a thread";
//      }

oxotnik · 05.10.2010, 13:54

Сообщение от MikeSoft

Несколько не согласен. В TThread реализована "безопасная" отсылка сообщений, позволяющая обновлять интерфейс.

На счет конкретно TThread не знаю (в части его синхронизации), но собственно моя мысль сводилась к тому что отрисовывать ГУИ должен основной поток, видимо под термином <<"безопасная" отсылка сообщений>> это и реализовано в TThread. Но, т.к. никто не знает как именно это сделано, то лучше все же пользоваться SendMessage/PostMessage.

Сообщение от Evg

А можешь вот этот момент объяснить. Или пример где-нить показать

см. личку, кинул ссылку

Evg · 05.10.2010, 15:12 **[ТС]**

Сообщение от oxotnik

но собственно моя мысль сводилась к тому что отрисовывать ГУИ должен основной поток

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

Буду пробовать. Если не прокатит с синхронизацией, буду извращаться с сообщениями

oxotnik · 05.10.2010, 15:23

Сообщение от Evg

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

Буду пробовать. Если не прокатит с синхронизацией, буду извращаться с сообщениями

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

@MikeSoft · 05.10.2010, 15:50

oxotnik, я думаю, плачевного результата не будет, т.к. потоки всего лишь создают иллюзию параллельного выполнения. Мне кажется, тут дело в недостаточности привилегий на изменение свойств VCL объектов.
Для примера, объекты, не имеющие оконного дескриптора обновляются из потоков без проблем (проверял на объектах класса TLabel), в то время, как TEdit не даёт себя обновлять из сторонних потоков.

Как раз месяца два-три назад рассматривал подобную проблему. Т.к. пользовался API-шными функциями наподобии CreateThread , пришлось добавить на форму таймер и список операций в enum и уже в потоке таймера обновлял то, что нужно было.

Позже начал рассматривать класс TThread. Используя Synchronize с подобными проблемами не сталкивался.

Evg · 05.10.2010, 16:02 **[ТС]**

Сообщение от MikeSoft

Цитирую:
// Important: Methods and properties of objects in VCL can only be
// used in a method called using Synchronize, for example:

Я правильно понял смысл этой фразы, что из потока гарантируется работа со всеми компонентами, но только в случае, если мы вызовем Synchronize?

В общем суть этого Synchronize понял. Оказывается не всё так просто, как я думал. Насколько я понял, Synchronize можно вызвать только из метода потомка класса TThread и параметром ему подавать тоже метод потомка класса TThread. В итоге получается, что код размазывается по двум классам, в то время как в моей нынешней реализации всё сосредоточено только в одном классе. При таком раскладе Synchronize мне не очень нравится, но пока однозначно сказать не могу. Надо поэкспериментировать, который из способов проще (Synchronize или через сообщения)

Добавлено через 2 минуты

Сообщение от oxotnik

И если вклиниться в эту очередь из другого потока, то результат может быть плачевный

Когда я читал статью про то, что дескать разработчики всё учли по части многопоточности, то я так понял, что там на уровне интерфейсов внутри библиотеки всё разрулено. Оказалось, что разрулено, но только через Synchronize. И мой способ (тот, которым реализовано сейчас в результате того, что я неправильно понял) действительно может привести к непонятным последствиям

Добавлено через 5 минут
Возможно, что проблемы, описанные здесь так или иначе являются последствиями неправильной реализации

@MikeSoft · 05.10.2010, 16:31

Сообщение от Evg

Я правильно понял смысл этой фразы, что из потока гарантируется работа со всеми компонентами, но только в случае, если мы вызовем Synchronize?

Да.

Сообщение от Evg

Возможно, что проблемы, описанные здесь так или иначе являются последствиями неправильной реализации

Ту тему ещё не смотрел ... Попаду за компьютер постараюсь посмотреть.

oxotnik · 05.10.2010, 16:35

Сообщение от MikeSoft

с подобными проблемами не сталкивался

все дело в том, что эти проблемы при многопоточности очень трудно уловимы, т.е. программа может тыщу раз отработать правильно (без сбоев), а на тыщу первый раз выкинуть AV. Т.к. я не видел исходников TThread в части Synchronize, то не стал бы им вот так вслепую пользоваться и надеяться что правильно понял документацию.

Evg · 05.10.2010, 17:01 **[ТС]**

В общем Synchronize тоже не помог:

Вот трассировка нормальной работы (т.е. когда просто нажимаем кнопку, рисуется окошко и скачивается картинка). В печатях "thread=" - то, что выдаёт вызов GetCurrentThreadId(), w и h - соответственно ширина и высота. Изначальна пустая форма создаётся с размерами 294x175. Скачанная картинка имеет размер 660x345. Надпись "Constructor:" - печать в конструкторе формы. "Before Synchronize" и "After Synchronize" - печати до и после вызова метода Synchronize, который, как видно, вызывается в потоке. "Inside Synchronize" - печать внутри метода, который параметрами подали в Synchronize. Для меня оказалось неожиданностью, что этот метод исполнился в главном процессе, а не дочернем потоке. "start resize" - место, где загружена картинка и начинаются изменяться размеры (но ещё не изменены). "finish resize" - размеры изменены. "OnResize" - печать в событии OnResize формы

Code
1
2
3
4
5
6
7
Constructor: thread=3656 w=294 h=175
Before Synchronize: thread=2584
Inside Synchronize: start resize: thread=3656
OnResize: thread=3656 w=660 h=175
OnResize: thread=3656 w=660 h=345
Inside Synchronize: finish resize: thread=3656
After Synchronize: thread=2584

А такая трасса, когда в момент скачивания из инетоа у меня окно зажато под мышкой и двигается

Code
1
2
3
4
5
6
7
8
Constructor: thread=3656 w=294 h=175
Before Synchronize: thread=392
Inside Synchronize: start resize: thread=3656
OnResize: thread=3656 w=660 h=175
OnResize: thread=3656 w=660 h=340
Inside Synchronize: finish resize: thread=3656
OnResize: thread=3656 w=294 h=175
After Synchronize: thread=392

Видим, что в главном же процессе появилась дополнительная запись "OnResize". Т.е. что-то типа того, что в момент захвата окна мышкой размеры зафиксировались и при попытке их изменения они восстанавливаются. Понятно, что по таким печатям сказать модно немного, но вдруг кого-то осенит идея

Добавлено через 4 минуты
Да, такая трасса мне интуитивно говорит о том, что в случае реализации через сообщения будет та же песня

@MikeSoft · 05.10.2010, 17:06

Сообщение от oxotnik

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

Согласен, но использовал явно не один раз, жалоб не было.
Вообще, сам объект VCL - подразумевает под собой работу внутри потока, т.к. идёт наследование от класса TPersistent (о нём я писал здесь: Visual Component Library: Вид изнутри, удаление и установка компонентов). Без исходного кода сложно понять, куда мы пытаемся вклиниться, поэтому сложно судить о последствиях. После прочтения документации я прекратил изощрения и начал пользоваться TThread ... думаю, разработчики данного VCL класса, обладая исходными кодами допустят меньше ошибок при внедрении, чем я, посылая команды напролом и вслепую.

Добавлено через 3 минуты
Evg, ещё раз...насколько я понял, задача звучит примерно так: из главной формы вызвать действие, которое создаст новую форму, запустит поток, в котором скачается изображение. После окончания загрузки - отобразить картинку в новой форме и изменить размеры формы под размер рисунка... правильно я понял?

oxotnik · 05.10.2010, 17:09

Сообщение от MikeSoft

Без исходного кода сложно понять, куда мы пытаемся вклиниться, поэтому сложно судить о последствиях. После прочтения документации я прекратил изощрения и начал пользоваться TThread ... думаю, разработчики данного VCL класса, обладая исходными кодами допустят меньше ошибок при внедрении, чем я, посылая команды напролом и вслепую.

В том то и дело, что не зная внутренней реализации TThread можно искать баг до потери пульса. В случае если посылать сообщение средствами Win Api, то тут во-первых система гарантирует, что будет сообщение обработано корректно, а во-вторых мы не лезем из дочернего потока в основной своими (часто кривыми) руками.

Evg · 05.10.2010, 17:19 **[ТС]**

Сообщение от MikeSoft

Evg, ещё раз...насколько я понял, задача звучит примерно так: из главной формы вызвать действие, которое создаст новую форму, запустит поток, в котором скачается изображение. После окончания загрузки - отобразить картинку в новой форме и изменить размеры формы под размер рисунка... правильно я понял?

Общая задача такая. Но она уже реализована и работает. Есть проблема: в тот момент, когда поток скачивает изображение, пользователь начинает перетаскивать окно (которое ещё пустое). Если в момент завершения загрузки изображения пользователь ещё не отпустил мышку, то геометрия окна не изменится (а по трассе - изменится после загрузки изображения и сразу же вернётся в исходное состояние из-за того, что сейчас идёт процесс перетаскивания окна).

Как вариант затычки меня устроило бы разобраться, как определить тот момент, когда пользователь закончил перетаскивать окно, и в этот момент ещё раз изменить геометрию

Evg · 07.08.2011, 10:45 **[ТС]**

Сообщение от MikeSoft

Evg, ещё раз...насколько я понял, задача звучит примерно так: из главной формы вызвать действие, которое создаст новую форму, запустит поток, в котором скачается изображение. После окончания загрузки - отобразить картинку в новой форме и изменить размеры формы под размер рисунка... правильно я понял?

По текущему состоянию уточнение. Картинка грузится в потоке. Затем поток шлёт сообщение WM_USER главному процессу, главный процесс это сообщение подхватывает и рисует картинку на форму. Тем не менее, беда остаётся. Если в этот момент таскать за форму мышкой, то размер окна не изменится

Evg · 07.08.2011, 11:59 **[ТС]**

Короткий пример для воспроизведения ситуации. Тут даже потоков никаких не надо.

Запускаем приложение, жмём на кнопку. В это время включится таймер и на дочернем окне появится соответствующая надпись. Через 5 секунд таймер отключится и опять появится надпись, при этом размер окна увеличится. Тут пока всё хорошо.

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

Тут надо решать одним из способов:
1. Отловить ситуацию "в лоб". Т.е. понять, почему так происходит и что-то сделать, чтобы не происходило.
2. Обойти ситуацию. В тот момент, когда мы делаем изменение размеров, запомнить размеры, а в тот момент, когда отпустили мышку - установить нужные размеры. Для меня попрос только в том, как поймать ситуацию, что отпустили мышку

@Maluda · 07.08.2011, 21:32

Сообщение от Evg

Для меня попрос только в том, как поймать ситуацию, что отпустили мышку

TApplicationEvents в OnMessage можешь отловить и когда отпустили мышку WM_LBUTTONUP,
и когда окно перемещается WM_MOVING.

Evg · 07.08.2011, 23:49 **[ТС]**

Пичаль... опять на низкий уровень спускаться

Добавлено через 3 минуты
Не канает. LBUTTONUP срабатывает только когда мышку отпустили внутри окна. А когда на заголовке - тут какое-то другое событие надо

Добавлено через 5 минут
В момент нажатия мыши приходит WM_NCLBUTTONUP, а когда отпускаешь приходит НЕ WM_NCLBUTTONDOWN, а WM_NCMOUSEMOVE (которое приходит и в случае обычного движения мыши). По крайней мере по комбинации идущих подряд WM_NCLBUTTONUP и WM_NCMOUSEMOVE ситуёвину можно отловить, но опять как-то всё через ж..у получается

Новые блоги и статьи Все статьи Все блоги /
изучаю kubernetes lagorue 13.01.2026 А пригодятся-ли мне знания kubernetes в России?	сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .	Classic Notepad for Windows 11 Jel 10.01.2026 Old Classic Notepad for Windows 11 Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .
Почему дизайн решает? Neotwalker 09.01.2026 В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .	Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30

	Поймать ситуацию перетаскивания формы 05.10.2010, 11:52. Показов 2659. Ответов 18 Метки нет (Все метки) Имеется следующая функциональность. По нажатию на кнопочку создаётся новая форма, на которой должна быть картинка, скачанная из инета. Размер картинки заранее неизвестен, а потому при создании размеры формы имеют некоторое дефолтное значение.. Из неё рождается поток, который лезет в инет и скачивает картинку. Чтобы не возиться с отловом точки завершения потока, я обновляю картинку на форме прямо из потока. Поток создаю через TThread, так что всю синхронизацию по части компонент берёт на себя библиотека VCL. После прорисовки картинки на форме меняются размеры формы - подгоняются под картинку. Изменение размера формы делается в потоке. После чего поток успешно помирает. Всё это работает. Но есть один неприятный момент. Если в тот момент, пока поток скачивает из инета, начать двигать форму мышкой за заголовок, то в момент скачивания картинки происходит изменение геометрии окна (в потоке), после чего поток умирает, после чего в основном процессе (в котором и обрабатывается факт перетаскивания формы) восстанавливается прежняя геометрия окна. Т.е. по каким-то причинам внутренняя синхронизация VCL не сработала. Или попросту в такой ситуации и не должна была сработать. А потому вопросы: 1. Можно ли каким-то образом заставить VCL адэкватно реагировать на изменение геометрии окна из потока, в то время как идёт перетаскивание окна в основном процессе. 2. Если по п.1 ответ отрицательный или излишне геморройный, то может быть как-то можно в основном процессе окна поймать ситуацию того, что сейчас идёт процесс перетаскивания окна (а точнее интересен момент завершения перетаскивания). Понятно, что более правильным решением было бы поймать точку завершения потока и все манипуляции проделывать уже оттуда. Но как эту точку поймать с классом TThread я так и не понял 0

oxotnik 1665 / 1134 / 80 Регистрация: 21.08.2008 Сообщений: 4,734 Записей в блоге: 1
	05.10.2010, 12:00
	Нельзя ГУЕм управлять напрямую из дочернего потока (не из потока ГУЯ)! Из дочернего потока можно только слать сообщения основному, а в последнем их отлавливать и перерисовывать что надо. 0

@MikeSoft 3956 / 1811 / 184 Регистрация: 21.11.2009 Сообщений: 2,540
	05.10.2010, 15:50
	oxotnik, я думаю, плачевного результата не будет, т.к. потоки всего лишь создают иллюзию параллельного выполнения. Мне кажется, тут дело в недостаточности привилегий на изменение свойств VCL объектов. Для примера, объекты, не имеющие оконного дескриптора обновляются из потоков без проблем (проверял на объектах класса TLabel), в то время, как TEdit не даёт себя обновлять из сторонних потоков. Как раз месяца два-три назад рассматривал подобную проблему. Т.к. пользовался API-шными функциями наподобии CreateThread , пришлось добавить на форму таймер и список операций в enum и уже в потоке таймера обновлял то, что нужно было. Позже начал рассматривать класс TThread. Используя Synchronize с подобными проблемами не сталкивался. 0

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30
	07.08.2011, 23:49 [ТС]
	Пичаль... опять на низкий уровень спускаться Добавлено через 3 минуты Не канает. LBUTTONUP срабатывает только когда мышку отпустили внутри окна. А когда на заголовке - тут какое-то другое событие надо Добавлено через 5 минут В момент нажатия мыши приходит WM_NCLBUTTONUP, а когда отпускаешь приходит НЕ WM_NCLBUTTONDOWN, а WM_NCMOUSEMOVE (которое приходит и в случае обычного движения мыши). По крайней мере по комбинации идущих подряд WM_NCLBUTTONUP и WM_NCMOUSEMOVE ситуёвину можно отловить, но опять как-то всё через ж..у получается 0