Как можно сделать свой титл окна (размер, положение, кнопки....)?

Привет!

Fenixs wrote:
>
> Как можно сделать свой титл окна (размер, положение, кнопки....)?

1.

WM_NCPAINT переписать. Но размер при этом не изменить.

2.

WS_CAPTION убрать.
Нарисовать свой псевдо-заголовок требуемого размера.
Нарисовать в нем кнопки (круглые, шестиугольные, фигурные .
Обрабатывать WM_MOUSEMOVE при проходе над ними курсора, WM_LBUTTONDOWN
при нажатии, когда курсор над ними. И т.д.

--
С наилучшими пожеланиями
Дворкин Павел

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Привет!

PD>Fenixs wrote:
>>
>> Как можно сделать свой титл окна (размер, положение, кнопки....)?

PD>1.

PD>WM_NCPAINT переписать. Но размер при этом не изменить.

PD>2.

PD>WS_CAPTION убрать.
PD>Нарисовать свой псевдо-заголовок требуемого размера.
PD>Нарисовать в нем кнопки (круглые, шестиугольные, фигурные .
PD>Обрабатывать WM_MOUSEMOVE при проходе над ними курсора, WM_LBUTTONDOWN
PD>при нажатии, когда курсор над ними. И т.д.

PD>--
PD>С наилучшими пожеланиями
PD> Дворкин Павел

мдя это конечно здорово самому написать все процедуры работы с титле
( перемещение окна, минимизация/максимизация по дабл клику... )
а стандартных апишных функций нету?
во многих оболочках (том же Visual C 6, WSAD, Eclipse... ) там титлы с кнопками свои не стандартные...

Привет!

Fenixs wrote:
> мдя это конечно здорово самому написать все процедуры работы с титле
> ( перемещение окна, минимизация/максимизация по дабл клику... )
> а стандартных апишных функций нету?

Кое-что есть : DrawFrameControl, но толку от него мало.

--
С наилучшими пожеланиями
Дворкин Павел

Ну так хватай WM_NCPAINT... и заодно WM_NCHITTEST.
Никакую максимизацию и т.п. менять не придется, только переопределить, где лежат в заголовке разные элементы. Но, откровенно говоря, я как-то немного с этим поэкспериментировал, и, помнится, то ли мерцание было, то ли еще что-то...
Оно и понятно — например, поток-владелец окна повис, а система ведь все равно рисует заголовок, видели, наверное? То есть есть еще кто-то помимо DefWindowProc, кто отрисовывает non-client area.
Кстати, коллеги, не просвятите, кто это и как с ним договориться, чтобы он поумерил активность?

Slicer

Здравствуйте, Fenixs, Вы писали:

F> Как можно сделать свой титл окна (размер, положение, кнопки....)?

Про кнопки здесь http://www.sources.ru/cpp/cpp_ccaptionbutton.shtml

Здравствуйте, Aton, Вы писали:

A>Про кнопки здесь http://www.sources.ru/cpp/cpp_ccaptionbutton.shtml

Интересно.
Захват мыши делают SetCapture. Опасно, хотя мелкие баги в поведении можно и стерпеть... если лень писать хук
Новые "кнопки" невозможно будет найти функциями типа control-at-pos(hwnd,x,y). Но это уже вообще из области мечтаний, правда?
А вот мое замечание относительно того, что будет при провисании message pump, остается в силе. Новых кнопок в такой ситуации видно не будет
DrawTransparentBitmap подозрительно здоровый что-то, казалось бы, задача несложная... Впрочем, я не особо аккуратно читал

Slicer

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Fenixs wrote:
>>
>> Как можно сделать свой титл окна (размер, положение, кнопки....)?

PD>1.

PD>WM_NCPAINT переписать. Но размер при этом не изменить.

Размер можно изменить, для этого есть WM_NCCALCSIZE.

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Здравствуйте, Aton, Вы писали:

A>>Про кнопки здесь http://www.sources.ru/cpp/cpp_ccaptionbutton.shtml

SM>Интересно.
SM>Захват мыши делают SetCapture. Опасно, хотя мелкие баги в поведении можно и стерпеть... если лень писать хук

Можно поподробней чем так опасен SetCaprure? Что за мелкие баги?

Здравствуйте, kliff, Вы писали:

K>Можно поподробней чем так опасен SetCaprure? Что за мелкие баги?

Смотри: юзер нажал на левую кнопку, мы захватили мышь. И тут какому-то другому приложению приспичило тоже захватить мышь (согласен, маловероятно, но ведь возможно). Тогда у нас мышь просто отберут. Последствия: кнопка осталась в "утопленном" состоянии (т.е. на самом деле класс кнопки продолжает находиться в соответствующем состоянии) — т.к. мышь с нее, скорее всего, к моменту отпускания клавиши мыши уже утащили, и сообщение об этом отпускании мы не получим.

Значит, 1) если это состояние отражается визуально, то мы увидим залипшую кнопку, 2) в каких-то случаях (возможно, не в данном, но в принципе это возможно) может нарушиться логика работы класса кнопки, а следовательно, возможно, и всего приложения.

Slicer

Hello, Slicer!
You wrote on Fri, 28 Nov 2003 14:24:01 GMT:

K>> Можно поподробней чем так опасен SetCaprure? Что за мелкие баги?

SM> Смотри: юзер нажал на левую кнопку, мы захватили мышь. И тут какому-то
SM> другому приложению приспичило тоже захватить мышь (согласен,
SM> маловероятно, но ведь возможно). Тогда у нас мышь просто отберут.
SM> Последствия: кнопка осталась в "утопленном" состоянии (т.е. на самом
SM> деле класс кнопки продолжает находиться в соответствующем состоянии) —
SM> т.к. мышь с нее, скорее всего, к моменту отпускания клавиши мыши уже
SM> утащили, и сообщение об этом отпускании мы не получим.

SM> Значит, 1) если это состояние отражается визуально, то мы увидим
SM> залипшую кнопку, 2) в каких-то случаях (возможно, не в данном, но в
SM> принципе это возможно) может нарушиться логика работы класса кнопки, а
SM> следовательно, возможно, и всего приложения.

Ну, если кто-то использует SetCapture и при этом не реагирует на WM_CAPTURECHANGED, то он сам виноват

Best regards,
Sergey.

Здравствуйте, Sergey, Вы писали:

S>Ну, если кто-то использует SetCapture и при этом не реагирует на WM_CAPTURECHANGED, то он сам виноват
Во-первых, они в этом примере как раз и не реагируют
Во-вторых, в каких-то случаях уведомления о том, что мышь отобрали, достаточно: можно отменить операцию или остановиться там, где в последний момент была мышь. В данном случае, похоже, это так, то есть достаточно добавить анализ WM_CAPTURECHANGED.

Но нередко хотелось бы все же довести операцию до конца. А иногда требуется долговременное отслеживание мышки. Или мы не знаем, насколько оно будет долговременным. В этих случаях imho лучше использовать хуки.

Slicer

Hello, Slicer!
You wrote on Fri, 28 Nov 2003 14:48:44 GMT:

S>> Ну, если кто-то использует SetCapture и при этом не реагирует на
S>> WM_CAPTURECHANGED, то он сам виноват
SM> Во-первых, они в этом примере как раз и не реагируют
Очень может быть, пример я как раз и не смотрел.

SM> Во-вторых, в каких-то случаях уведомления о том, что мышь отобрали,
SM> достаточно: можно отменить операцию или остановиться там, где в
SM> последний момент была мышь. В данном случае, похоже, это так, то
SM> есть достаточно добавить анализ WM_CAPTURECHANGED.

SM> Но нередко хотелось бы все же довести операцию до конца.

Реакция на WM_CAPTURECHANGED — это и есть доведение операции до конца, с возможностью учесть пожелания пользователя — откатить операцию или продолжить.

SM> А иногда требуется долговременное отслеживание мышки.

Напиример?

SM> Или мы не знаем,
SM> насколько оно будет долговременным. В этих случаях imho лучше
SM> использовать хуки.

Угу, только глючить будет примерно как mouseimp.

Best regards,
Sergey.

Здравствуйте, Sergey, Вы писали:
SM>> А иногда требуется долговременное отслеживание мышки.
S>Напиример?

Например, чтобы отследить клик по области, которая перехватом WM_NCHITTEST сделана нечувствительной к мыши.

Slicer

Hello, Slicer!
You wrote on Fri, 28 Nov 2003 15:08:46 GMT:

SM>>> А иногда требуется долговременное отслеживание мышки.
S>> Напиример?

SM> Например, чтобы отследить клик по области, которая перехватом
SM> WM_NCHITTEST сделана нечувствительной к мыши.

Не понял. Для отслеживания собственно клика ни хуков, ни даже SetMouseCapture не требуется. SetMouseCapture нужна только для отслеживания перемещений мыши при нажатой кнопке. И хуки в этом случае, насколько я понимаю, нечем не лучше (даже хуже) чем SetMouseCapture.

Best regards,
Sergey.

SM>> Например, чтобы отследить клик по области, которая перехватом
SM>> WM_NCHITTEST сделана нечувствительной к мыши.
Звиняйте, тормознул. Тут SetCapture просто не справится (т.к. при движении по этой области, да еще и без нажатой кнопки, сообщения не придут нашему окну — ведь мы сами отмазались от WM_NCHITTEST), так что без хуков не обойтись. Ладно, нужен какой-то пример с движением мыши при нажатой кнопке...
Во, Desktop Toys!

>Не понял. Для отслеживания собственно клика ни хуков, ни даже SetMouseCapture не требуется. >SetMouseCapture нужна только для отслеживания перемещений мыши при нажатой кнопке. И хуки в этом случае, >насколько я понимаю, нечем не лучше (даже хуже) чем SetMouseCapture.
Вот как раз таки и требуется, и даже не хватает Мы же говорим, что клик был не по нам (в WM_NCHITTEST) — как же он к нам тогда придет?

Slicer

Hello, Slicer!
You wrote on Fri, 28 Nov 2003 15:39:45 GMT:

SM>>> Например, чтобы отследить клик по области, которая перехватом
SM>>> WM_NCHITTEST сделана нечувствительной к мыши.
SM> Звиняйте, тормознул. Тут SetCapture просто не справится (т.к. при
SM> движении по этой области, да еще и без нажатой кнопки, сообщения не
SM> придут нашему окну — ведь мы сами отмазались от WM_NCHITTEST), так что
SM> без хуков не обойтись. Ладно, нужен какой-то пример с движением мыши
SM> при нажатой кнопке... Во, Desktop Toys!

Что такое Desktop Toys? В принципе, понятно что это какой-то твикер десктопа, но что конкретно оно делает?

??>> Не понял. Для отслеживания собственно клика ни хуков, ни даже
??>> SetMouseCapture не требуется. >SetMouseCapture нужна только для
??>> отслеживания перемещений мыши при нажатой кнопке. И хуки в этом
??>> случае, >насколько я понимаю, нечем не лучше (даже хуже) чем
??>> SetMouseCapture.
SM> Вот как раз таки и требуется, и даже не хватает Мы же говорим, что
SM> клик был не по нам (в WM_NCHITTEST) — как же он к нам тогда придет?

Не, ты скажи что ты в результате хочешь получить.

Best regards,
Sergey.

S>Что такое Desktop Toys? В принципе, понятно что это какой-то твикер десктопа, но что конкретно оно делает?
Какая разница, скачать хочешь? Например, держишь левую кнопку и расстреливаешь десктоп из пулемета. Хотя, боюсь, опять не вполне корректный пример. Он, вроде, морозит десктоп на время выполнения.
Ну и ладно, может, и правда это я загнул. Снимаю с рассмотрения этот пункт, про длительное отслеживание.

S>Не, ты скажи что ты в результате хочешь получить.
Хочу получить: 1) окно является совершенно пустым местом для мыши, 2) его можно таскать мышью.
И не спрашивай, зачем мне это надо, такой вопрос не я первым задал

P.S. Е-мое, сколько уже постингов навалили... Может, хватит?

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

S>>Что такое Desktop Toys? В принципе, понятно что это какой-то твикер десктопа, но что конкретно оно делает?
SM>Какая разница, скачать хочешь? Например, держишь левую кнопку и расстреливаешь десктоп из пулемета. Хотя, боюсь, опять не вполне корректный пример. Он, вроде, морозит десктоп на время выполнения.
SM>Ну и ладно, может, и правда это я загнул. Снимаю с рассмотрения этот пункт, про длительное отслеживание.

S>>Не, ты скажи что ты в результате хочешь получить.
SM>Хочу получить: 1) окно является совершенно пустым местом для мыши, 2) его можно таскать мышью.
SM>И не спрашивай, зачем мне это надо, такой вопрос не я первым задал

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

SM>P.S. Е-мое, сколько уже постингов навалили... Может, хватит?

Ну я тебя писать вроде не заставляю Лично я в 20:00 уйду домой и до понедельника сюда писать не буду

Здравствуйте, Slicer [Mirkwood], Вы писали:

S>>Что такое Desktop Toys? В принципе, понятно что это какой-то твикер десктопа, но что конкретно оно делает?
SM>Какая разница, скачать хочешь? Например, держишь левую кнопку и расстреливаешь десктоп из пулемета. Хотя, боюсь, опять не вполне корректный пример. Он, вроде, морозит десктоп на время выполнения.
SM>Ну и ладно, может, и правда это я загнул. Снимаю с рассмотрения этот пункт, про длительное отслеживание.

Прммер отслеживания при котором не стоит применять SetCapture — тебе надо отследить выход мыши за область окна — типа самому написать TrackMouseEvents().

S>>Не, ты скажи что ты в результате хочешь получить.
SM>Хочу получить: 1) окно является совершенно пустым местом для мыши, 2) его можно таскать мышью.
SM>И не спрашивай, зачем мне это надо, такой вопрос не я первым задал

Короче подытожив — SetCapture() не опасен, надо просто знать как его готовить.

SM>Slicer

Здравствуйте, kliff, Вы писали:

K>Короче подытожив — SetCapture() не опасен, надо просто знать как его готовить.
Ну, скажем, у меня не придумалось контрпримеров Факт тот, что SetCapture имеет смысл юзать только тогда, когда мы можем как-то корректно обработать потерю захвата.

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Здравствуйте, kliff, Вы писали:

K>>Короче подытожив — SetCapture() не опасен, надо просто знать как его готовить.
SM>Ну, скажем, у меня не придумалось контрпримеров Факт тот, что SetCapture имеет смысл юзать только тогда, когда мы можем как-то корректно обработать потерю захвата.

Во всех случаях, когда вообще удастся юзать SetCapture, потерю захвата можно отработать корректно. А использовать хуки имеет смысл только тогда, когда других средств нет (ну, не совсем — таймеры иногда еще хуже).

Здравствуйте, kliff, Вы писали:

K>Здравствуйте, Slicer [Mirkwood], Вы писали:

S>>>Что такое Desktop Toys? В принципе, понятно что это какой-то твикер десктопа, но что конкретно оно делает?
SM>>Какая разница, скачать хочешь? Например, держишь левую кнопку и расстреливаешь десктоп из пулемета. Хотя, боюсь, опять не вполне корректный пример. Он, вроде, морозит десктоп на время выполнения.
SM>>Ну и ладно, может, и правда это я загнул. Снимаю с рассмотрения этот пункт, про длительное отслеживание.

K>Прммер отслеживания при котором не стоит применять SetCapture — тебе надо отследить выход мыши за область окна — типа самому написать TrackMouseEvents().

Слово "не стоит" здесь неуместно — SetCapture там просто не применишь

Здравствуйте, Sergey, Вы писали:


S>Во всех случаях, когда вообще удастся юзать SetCapture, потерю захвата можно отработать корректно. А использовать хуки имеет смысл только тогда, когда других средств нет (ну, не совсем — таймеры иногда еще хуже).

А чем таймеры хуже ?

Hello, AndrewJD!
You wrote on Mon, 01 Dec 2003 17:39:55 GMT:

S>> Во всех случаях, когда вообще удастся юзать SetCapture, потерю захвата
S>> можно отработать корректно. А использовать хуки имеет смысл только
S>> тогда, когда других средств нет (ну, не совсем — таймеры иногда еще
S>> хуже).

A> А чем таймеры хуже ?

Отлажавать сильно мешают Ну и просто неэстетичны — как, впрочем, и хуки.

Best regards,
Sergey.

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>Ну так хватай WM_NCPAINT... и заодно WM_NCHITTEST.
SM>Никакую максимизацию и т.п. менять не придется, только переопределить, где лежат в заголовке разные элементы. Но, откровенно говоря, я как-то немного с этим поэкспериментировал, и, помнится, то ли мерцание было, то ли еще что-то...
SM>Оно и понятно — например, поток-владелец окна повис, а система ведь все равно рисует заголовок, видели, наверное? То есть есть еще кто-то помимо DefWindowProc, кто отрисовывает non-client area.
SM>Кстати, коллеги, не просвятите, кто это и как с ним договориться, чтобы он поумерил активность?

SM>Slicer

Именно DefWindowProc и перерисовывает caption и всю non-client area. Я справился с этой проблемой просто: по событиям WM_NCPAINT и WM_NCACTIVATE рисую всю non-client area, включая титл и кнопки с иконкой на нем, возвращаю true, не вызывая DefWindowProc.

Тут прорисовка non-client без титла:

DrawEdge(hdc, &rc2, EDGE_RAISED, BF_RECT);

HPEN pen_old;
HPEN hpen = CreatePen(PS_SOLID, 1, GetSysColor(COLOR_BTNFACE));
pen_old = (HPEN)SelectObject(hdc, hpen);
MoveToEx(hdc, rc2.left+2, rc2.top+2, NULL);
LineTo(hdc, rc2.left+2, rc2.bottom-3);
LineTo(hdc, rc2.right-3, rc2.bottom-3);
LineTo(hdc, rc2.right-3, rc2.top+2);
LineTo(hdc, rc2.left+2, rc2.top+2);
MoveToEx(hdc, rc2.left+2, rc2.top+3+GetSystemMetrics(SM_CYSIZE), NULL);
LineTo(hdc, rc2.right-3, rc2.top+3+GetSystemMetrics(SM_CYSIZE));
SelectObject(hdc, pen_old);
DeleteObject(hpen);

rc2 — это RECT который хранит размеры окна. (Хех, ща подумал, что rc2.left и rc2.top всегда равны нулю... нахрена я их вписывал...)

Это далеко не образец для подражания. Я с удовольствием выслушаю гораздо более лудшие предложения. Ведь бордер окна юзверь может изменить и тогда получаем глюк с отрисовкой...

Но проблема полностью таким способом не решается, т.к.
1. при клике на титле отрисовываются старые кнопки с голубой рамочкой.
2. нарисоваными кнопками еще рулить надо.

Ето значит, что в бой вступают WM_NCLBUTTONDOWN, WM_NCRBUTTONDOWN и WM_NCMOUSEMOVE и свой обработчик для перемещения окна...
Вот с последним я пока не справился. Не хочу делать SetCapture для окна и двигать его по WM_MOUSEMOVE. Хочу поручить перемещение окна винде.

Может кто знает как это сделать?

1) А разве не достаточно будет перехватить WM_NCHITTEST и никогда не возвращать нахождение мыши над одной из стд. кнопок? А своими рулить вроде как не очень проблемно

2) Насчет перерисовки — оплошал Мне потом свои люди объяснили, что в MFC за non-client сообщения, если не определить свой обработчик, отвечает каркас (в отдельном потоке — потому и не висит). А если написать тестовое приложение на API, лекго убедиться, что налицо полное равноправие

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>1) А разве не достаточно будет перехватить WM_NCHITTEST и никогда не возвращать нахождение мыши над одной из стд. кнопок? А своими рулить вроде как не очень проблемно

SM>2) Насчет перерисовки — оплошал Мне потом свои люди объяснили, что в MFC за non-client сообщения, если не определить свой обработчик, отвечает каркас (в отдельном потоке — потому и не висит). А если написать тестовое приложение на API, лекго убедиться, что налицо полное равноправие

SM>Slicer

http://www.catch22.org.uk/tuts/titlebar.asp
Там далеко не все идеально, но на этой основе можно уже что-то сделать.

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>2) Насчет перерисовки — оплошал Мне потом свои люди объяснили, что в MFC за non-client сообщения, если не определить свой обработчик, отвечает каркас (в отдельном потоке — потому и не висит). А если написать тестовое приложение на API, лекго убедиться, что налицо полное равноправие

Я не использую MFC.
Интересно, так можно всетаки сделать так, чтобы не перерисоваывая non-client, перерисовать caption и кнопки на нем? Я так и не нашел как это сделать. Один хрен caption стандартный рисуется, а поверх него уже свой... и получаем мигание... Что не есть хорошо...

Здравствуйте, Sergey, Вы писали:
S>Угу, только глючить будет примерно как mouseimp.

offtop — знает ли кто клоны mouseimp? А то ...