@nexen

В сообщении о изменении размера WM_SIZE ставлю следующее :
GetWindowRect(hWnd, &r);
ClipCursor(&r);
Но, почему-то, при изменении размера окна (больше его сделать нельзя, ибо идет привязка, а вот меньше можно) привязка сбрасывается.
r - static RECT.

Добавлено через 16 часов 46 минут
up-to-date

Добавлено через 6 часов 38 минут
up-to-date

0

@volvo

А теперь - подробно, чего ты хочешь добиться? Того, чтобы курсор всегда был "заперт" в твоем окне? Не надо этого делать, курсор - разделяемый ресурс, а не твой личный. Зачем понадобилось по WM_SIZE вызывать ClipCursor, да еще и нигде не освобождая?..

1

@nexen

UI, вопрос был не в том. Мне лишь интересно, почему оно не срабатывает.
По идее, даже если я вышел за пределы дозволенной границы, то CliCursor должна вернуть курсор на место. На msdn нет ничего о том, в каких случаях она сбрасывается.
p.s Но на самом деле применение для данной функции я найти могу в своем приложении, в котором просчитывается скорость относительно мыши. Хоть и стоит SetCapture, но когда приложение создает "реальную" стенку гораздо проще оперировать с такой функцией

0

@volvo

Обрабатывай не только WM_SIZE, а еще и WM_EXITSIZEMOVE, которое отсылается, когда ресайз/перемещение окна завершены. Нет. Даже не так. Скорее, вот так: WM_SIZE - только для того, чтобы изначально "запереть" мышь, потом от него толку нет. Основную работу делает WM_EXITSIZEMOVE:

1

@nexen

UI, спасибо. Помогло.
Однако все равно не понятно мне, почему не работает с сообщение WM_SIZE. Разве не получается так, что посылается туча сообщений на WM_SIZE, когда я растягиваю окно, и каждое это сообщение устанавливает захват на новый размер клиентского окна? Даже если всё и завершает функция WM_EXITSIZEMOVE, то перед тем, как отпустить кнопку мыши, изменение в WM_SIZE уже произошли и, как минимум, должна остаться команда на захват ClipCursor. Но она снимается ;<

0

@volvo

А теперь подумай, кто (и куда) посылает сообщение WM_SIZE. Как только пользователь нажал левую кнопку мыши на заголовке или на бордюре, ты получаешь WM_ENTERSIZEMOVE, и начинается модальный цикл перемещения/ресайза окна. В это время сообщения из очереди окном не обрабатываются (а получаешь ты WM_SIZE только потому, что тебе оно высылается не через очередь сообщений, а напрямую в оконную функцию). Выходит система из этого модального цикла только тогда, когда кнопка отпущена, и тебе об этом сигнализируют: WM_EXITSIZEMOVE.

Вероятно, если ClipCursor вызывать во время этого модального цикла, он не отрабатывает как положено (или вообще не отрабатывает). Другого объяснения у меня нет.

1

@nexen

UI, собственно он отрабатывает. BreakPoint на 1000hit'ов (WM_SIZE) спокойно преодолевает при изменении размера.

0

@volvo

В том, что ты получаешь 1000 сообщений WM_SIZE, и даже в том, что вызываешь 1000 раз ClipCursor() - я не сомневаюсь. А вот результат этого? Что дальше происходит после того, как вызвана ClipCursor()? В очередь окна засылается какое-то сообщение, которое должно быть обработано твоим окном? Что-то еще происходит? Но засылать сообщения бесполезно. Пока модальный цикл не завершится, оно обработано-то не будет. Равно и другие вещи могут не так работать. пока не начнется, собственно. выборка сообщений из очереди. Поэтому не надо вешать ClipCursor() на WM_SIZE (в первый раз, при инициализации окна, она отработала потому что никакого модального цикла не было, просто начальная установка размеров). Работай с окончанием drag-а.

1