Функция SendMessage
Если я создаю дополнительный поток и из него посылаю сообщение главному окну с помощью SendMessage - в каком потоке будет обрабатываться сообщение? В основном или дополнительном?
И тот же вопрос но с функцией PostMessage?
:-?
Есть такой вопрос:
Если я создаю дополнительный поток и из него посылаю сообщение главному окну с помощью SendMessage - в каком потоке будет обрабатываться сообщение? В основном или дополнительном?
И тот же вопрос но с функцией PostMessage?
:-?
В основном
В основном
Хм... Тогда получается неувязочка!
Если ф-я SendMessage, вызванная в дополнительном потоке, будет обрабатываться в основном - тогда дополнительный поток не будет ожидать завершения работы функции. Но по спецификации на ф-я SendMessage не возвращает результат, пока не будет обработано сообщение! :!!!:
Например, если я хочу получить текст главного окна из дополнительного потока, я должен вызвать SendMessage с параметром WM_GETTEXT, и ф-я должна возвратить указатель на строку.
И пока она его не возвратит, поток должен висеть!
Хм... Тогда получается неувязочка!
Если ф-я SendMessage, вызванная в дополнительном потоке, будет обрабатываться в основном - тогда дополнительный поток не будет ожидать завершения работы функции. Но по спецификации на ф-я SendMessage не возвращает результат, пока не будет обработано сообщение! :!!!:
Например, если я хочу получить текст главного окна из дополнительного потока, я должен вызвать SendMessage с параметром WM_GETTEXT, и ф-я должна возвратить указатель на строку.
И пока она его не возвратит, поток должен висеть!
А это зависит где ты обрабатываешь сообщения
А это зависит где ты обрабатываешь сообщения
Так ведь сообщения всегда поступают в цикл обработки сообщений окна. И если я посылаю сообщение главному окну, то оно всегда попадет в его цикл обработки, который работает в основном потоке.
Вот и интересно узнать, что на самом деле получается.
Наверное, мне кажется, что вызов ф-ии SendMessage в свою очередь вызовет напрямую метод WndProc окна. Т.е. фактически из дополнительного потока мы вызовем ф-ю основного потока.
Может быть, такие вызовы вообще некорректны?
сколько раз это обсуждалось на подобных форумах...
она именно будет ожидать обработки этого сообщения в основном потоке.
Если конечно вызов функции не происходит в основном потоке.
Джефри Рихтер (не цитата. по памяти)
Все сообщения, всех окон, всегда, обрабатываются в потоках,
которым эти окна принадлежат. (тем кто их создавал,
вызывая CreateWindow)
Если окно, которому посылается сообщение, принадлежит к потоку,
вызвавшем SendMessage, то происходит просто вызов подпрограммы.
Если другому потоку (что в одном процессе, что в разных),
вызвавший SendMessage поток останавливается и ждет, пока
сообщение не будет, обработанно.
Если поток, которому принадлежит окно, не находиться в
alertable state (упрощая можно сказать, не обрабатывает
в данный момент никакого сообщения), то message ставиться
в очередь и взводиться флаг (точно его имя не помню), что
в очереди присутсвуют send-нутые сообщения.
На GetMessage, сначала проверяется нет ли send-тых сообщений,
если да то отдается первое найденное (они как пенсионеры,
в порядке своей очереди) если таковых нет, проверяется
есть ли в очереди кто (post-нутые), если нет, проверяется
не установлен ли флаг PAINT, если да то формируется и
оттдается сообщение WM_PAINT, если нет, проверяется флаг
TIMER, если да то формируется и отдается WM_TIMER,
если нет поток помечается как "бездельный" и планировщик
ему не дает. до тех пор пока что-нибудь из перечисленного
выше не изменит ситуацию (и флаг занятости).
а alertable state поток переходит при вызове GetMessage,
sleep, SleepEx(..., TRUE) , WaitForSingleObject,
WaitForMultipleObjects, и т.д.
дальше я уже буду просто msdn повторять
APC Anisochronous Procedure Call
С уважением, Сергей
http://www.rsdn.ru/Forum/Message.aspx?mid=669317&only=1
Теперь хоть понимаю принцип работы сообщений в Windows!
:}
Например, если я хочу получить текст главного окна из дополнительного потока, я должен вызвать SendMessage с параметром WM_GETTEXT, и ф-я должна возвратить указатель на строку.
И пока она его не возвратит, поток должен висеть!
Если что запросил, то нужно дождаться результата
А вообще ИМХО win messages далеко не лучший метод обмена информацией между потоками
...А вообще ИМХО win messages далеко не лучший метод обмена информацией между потоками
Просто никак не могу найти стандартного решения для такой задачи:
Один поток (дополнительный) принимает данные в буфер. Другой поток (основной) по таймеру обновляет график. И вот я каждый раз пытаюсь избавиться от глобальных переменных, типа коэф. масштабирования графиков - чтобы дополнительный поток только принимал данные в буфер, а основной их масштабировал и строил графики.
Просто никак не могу найти стандартного решения для такой задачи:
Один поток (дополнительный) принимает данные в буфер.
От кого принимает?
Другой поток (основной) по таймеру обновляет график.
Если не секрет, почему по таймеру, а не по приходу данных?