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

K>Не сходится. Помните -
VF>>>SM_CYBORDER ?
K>SM_CYBORDER — это 1 пиксель.
K>В общем, все очень запутанно
Пожалуй я погорячился насчет SM_CYBORDER. Правильно было бы сказать "какой-то BORDER", в зависимости от стиля окна:
SM_CYBORDER — Height of a window border, in pixels. This is equivalent to the SM_CYEDGE value for windows with the 3-D look.
SM_CYSIZEFRAME — Thickness of the sizing border around the perimeter of a window that can be resized, in pixels. SM_CXSIZEFRAME is the width of the horizontal border, and SM_CYSIZEFRAME is the height of the vertical border.
Same as SM_CYFRAME.
SM_CYFIXEDFRAME — Thickness of the frame around the perimeter of a window that has a caption but is not sizable, in pixels. SM_CXFIXEDFRAME is the height of the horizontal border and SM_CYFIXEDFRAME is the width of the vertical border.
Same as SM_CYDLGFRAME.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Отвратительная концепция nonclient area есть самый главный архитектурный огрех USERа, и я бы не советовал ею пользоваться в собственных наработках.

А еще mvp

По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)

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

VF>SM_CYBORDER — Height of a window border, in pixels. This is equivalent to the SM_CYEDGE value for windows with the 3-D look.

Кстати, вот еще один пример путающих неряшливостей в MSDN: "equivalent to the SM_CYEDGE value"...
Обратное примечание куда точнее: "SM_CYEDGE — The height of a 3-D border, in pixels. This is the 3-D counterpart of SM_CYBORDER".

По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)

MSS>>Отвратительная концепция nonclient area есть самый главный архитектурный огрех USERа, и я бы не советовал ею пользоваться в собственных наработках.

K>А еще mvp

И что — мне теперь все микрософтное хвалить?

Фишка в том, что создание второго окна внутри первого — view внутри frame — это намного более удобная штука, чем использование nonclient area.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>>>Отвратительная концепция nonclient area есть самый главный архитектурный огрех USERа

Все-таки "отвратительная концепция" совершенно естественна и вполне достигает цели:
обеспечить единообразие окон в системе (распределив заботу об окне между юзером и системой).

MSS>>Идея некрасива и неэлегантна (один второй набор сообщений WM_NC_xxx чего стоит)

А по-моему — наоборот: такая симметрия как раз логична и потому украшает "отвратительную концепцию"

MSS>Фишка в том, что создание второго окна внутри первого — view внутри frame — это намного более удобная штука, чем использование nonclient area.

Короче, вас не устраивает эта древняя схема:



Так что взамен ?
И как насчет оконных стилей и NcHitTest-а ?

По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)

Б_О_Л_Ь_Ш_О_Е СПАСИБО, kero, за поддержу...

но, к сожалению, а может и к счастью, я решил отказаться от своей затеи, но вовсе не потому, что проникся идей г-на Maxim S. Shatskih, а вот по каким тех. причинам: во-первых, при resizing'е окна-владельца, вложенной в non-client area панели, ее приходиться тоже resize'ить, но только сделать это затруднительно без глюков прорисовки. Если включить поддержку отрисовки содержимого в момент перетаскивания, то видны различные артефакты подобного преобразования, в виде постоянно вылезающего за границы окна-фрейма куска панели (оно же WS_POPUP) при сдвиге левого края окна фрейма к правому краю. Во-вторых, при изменении размеров окна сразу в двух плоскостях, т.е. уменьшаем размеры по горизонтали и вертикали, освобожденная площадь рабочего стола, которая была "накрыта" поверхностью окна, некорректно перерисовывает себя не стирая прямоугольные куски различного размера, хотя ф-ция WM_NCCALCSIZE написана корректно и все возвращаемые размеры окон в ней корректные, в-третьих, есть подозрение, что такое перекрытие одним окном неклиентской области другого вызовет дополнительные расходы на перерисовку всей неклиентской области, но это всего ли подозрение. В общем, прикинув все за и против, я все-таки решил ввести одну единственную ф-цию, возвращающую границы псевдо-клиентской области, чем городить ряд всяческих ухищрений (в которых сам потом запутаешся) дабы предотвратить нежелательные артефакты. После чего перенес содержимое в клиентскую область и все заработало как надо, сейчас уже продолжаю работать в этом направлении, пока успешно. Мне наверно просто не хватило желания разбираться с нарастающими проблемами, но в целом от идеи я не отказался, просто не заточенная под такое мышление программиста реализация non-client area в winapi не дает всей гибкости ее использования в столь сложных масштабах, хотя, повторюсь, дело тут скорее в моих кривых руках...

Еще раз благодарю всех, кто откликнулся!

Спасибо!