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

Ну ладно, буду пробовать дальше

Так ты как дочернее создаешь? Вроде это автоматом должно быть, те по спец стилю.

Если создавать дочернее, нет переключения между ними - не подсвечиваются заголовок. Мне chaos посоветовал сделать WS_OVELAPPED и потом привязать SetParent(hWnd2, hWnd1); - заработало нормально переключение фокуса, но теперь его можно тягать

Цитата(Ibragim @ 2.8.2005, 01:28)

но теперь его можно тягать

че значит тягеть, перетаскивать что ли?
ты хочешь что бы твои панельки нельзя было перетаскивать?

Да, чтобы у дочернего окна был заголовок (активный или не активный), но пользователь не мог бы начать действия по изменению размера (это сделано - просто нет BORDER) или положения окна (вот как это запретить - не знаю). Само собой, что поскольку окно дочернее, то при изменении размеров родительского окна я пересчитываю размеры дочерних, и при изменении положения родительского окна дочерние перетаскиваются вместе с ним автоматически (так уж окна в Windows устроены).

Цитата(Ibragim @ 2.8.2005, 13:44)

(вот как это запретить - не знаю)

Если у окна есть заголовок - его можно тягать, должно быть без вариантов Выход - нарисуй заголовок сам.

Либо по таймеру проверяй Top & Left Формы, изменились .... поставь необходимые.

Понятно, буду рисовать сам. Спасибо.

Romikgy - мне нужно убрать возможность начать перетаскивание, а не "бороться" с пользователем - он туда, я назад. К тому же зачем лишний раз занимать процессорное время?

Цитата

господа, а не знаете - как запретить двигать и изменять размеры окна, но иметь у него CAPTION (ну, эдакую синюю или серую панельку с названием вверху)?

Можно обрабатывать WM_NCHITTEST и просто возвращать всегда HTCLIENT (или HTNOWHERE), тогда изменять размер и таскать окно будет нельзя...

В данном случае правильнее рисовать заголовок самому - как ManiaK сказал. Тем более есть для этого готовые функции (точно не помню, кажется DrawFrameControl). И не изобретать лишних сущностей. Вариант от chaos остроумный, но все же это извращение. Хорошо для "поиграться", но в реальной работающей программе... Поверьте, вам хватит извращений, которые и без вас есть в WIndows.

Цитата(Earnest @ 3.8.2005, 06:57)

В данном случае правильнее рисовать заголовок самому - как ManiaK сказал. Тем более есть для этого готовые функции

Нет, этот способ как раз-таки не очень неправильный
Т.к. такое окно будет выделяться на фоне других окон, если включены визуальные стили в WinXP. В этом случае надо рисовать через ThemeManager, но, при этом никто не гарантирует, что в следующей версии Microsoft не сделает еще один API для визуалиции окошек... Нужен ли лишний геморрой ради ничего ?
Кроме этого, возможно, нужно рисовать кнопочки свертывания, развертывания, закрытия, обрабатывать их нажатие, и учитывать Active окно или нет - легче ли это ?
Не знаю, как кому, но вставить 1-2 строчки кода, чтобы запретить двигать окно и изменять размер, имхо, не извращение. Извращение - рисовать самому окно ...

Не согласная я
1) Для имитации системных контролов есть DrawFrameControl - она должна рисовать так, как в данный момент установлено в системе. Так что рисование - это тоже 2 строчки. Да и с чего это ты взял, что дочернее окно должно иметь такой же заголовок как overlapped...
2) Одной-двумя строчками кода проблему не решить. Resize - да, можно отбить стилями, а вот чтобы за заголовок таскать нельзя было, да чтобы курсор над ним не менялся... Радикальнее всего - перехватывать NCHITTEST и возвращать HTCLIENT, но тогда забудьте про стандартные кнопочки - не будут они сами работать. А если они не нужны - о чем разговор.
3) Извращение - создавать окно как OVERLAPPED, а потом делать его дочерним. Даже если в данный момент код работает, никто не гарантирует, что в дальнейшем не появится проблем.
4) Нарисовать можно все, что угодно, как бы геморройно это не было. И это уж точно локально и безопасно.

Цитата

1) Для имитации системных контролов есть DrawFrameControl - она должна рисовать так, как в данный момент установлено в системе. Так что рисование - это тоже 2 строчки.

Эрнест , ну попробуй сам, раз не веришь, включи визуальные стили, и нарисуй что-нибудь с помощью DrawFrameControl , она рисует всегда в стиле Win9x, независимо от выбранного визуального стиля.
Также почитай в MSDN об UxTheme Manager

Цитата

4) Нарисовать можно все, что угодно, как бы геморройно это не было.

Вот такой подход и привел к тому, что программы, написанные в Delphi6 (и ранее), использующие BitBtn выглядят в WinXP очень стремно (одни кнопки - как кнопки, а другие - как доисторические ископаемые...), а делали эти кнопочки Borland, рисуя с помощью DrawFrameControl (они ж не знали в те года, что Microsoft изобретет визуальные стили )... Зачем повторять чужие ошибки ? (хотя в случае Borland, сложно придумать другой вариант (корректный) реализации такой кнопки)

Цитата

Радикальнее всего - перехватывать NCHITTEST и возвращать HTCLIENT

Это я и предлагал... т.к. это самый легкий и правильный способ

Цитата

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

Хе
Предположим, нам нужны кнопочки.
В твоём случае надо, навскидку:
1. Рисовать кэпшен: DrawCaption ( DrawThemeBackground )
2. Рисовать кнопочки: DrawFrameControl ( DrawThemeBackground )
3. Обрабатывать NCHITTEST, чтобы указать, что мышь щелкнула по такой-то кнопочке ( И охото же это тебе делать )
Как видишь, обработкой одного сообщения не обойтись.
При чем ни один из этих пунктов не делается в пару строк кода. Например, кнопочки - нужно учитывать, наведен ли курсор, нажата ли она, узнавать размер кнопочек; кэпшен - активное или неактивное окно, получать размер Caption'а. Всё это усложняется тем, что нужно учитывать визуальные стили. В случае Win9x и классического визуального стиля, нужно использовать старые функции DrawCaption и DrawFrameControl, при включенном визуальном стиле - использовать OpenThemeData + DrawThemeBackground + CloseThemeData (при чем правильно должно быть сделано так, что uxtheme.dll не статически подключается, а динамически, т.к. она есть только в WinXP).
И, как я уже говорил, даже если реализовать такой геморройный подход, мы не защищены от будущих нововведений, которые обязательно будут. Тогда нам надо будет добавлять еще 1 вариант рисования, использующий новый API.

В моём случае:
В обработчике WM_NCHITTEST вызываем стандартный обработчик, в случае, если результат = HTCAPTION, делаем его HTCLIENT... Буквально пара-тройка строк кода, и вуаля, всё готово , без всяких ухищрений и издевательств над бедным окном.

Ну, убедил, или еще нет ?

Проще (меньше кода) - не значит лучше...

Верю, верю я насчет тем и стилей, но ведь стандартные средства для рисования все равно есть. Ну, 5 строчек будет. Можно "расширить" API, написав отдельную функцию, которая всегда рисует правильно. Даже если добавятся новые средства рисования - это всего лишь изменения в одной функции.

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

Но если это коммерческая программа, или бесплатная, но долго-живущая и для других, тогда см. п.3.
Как еще один аргумент - посмотри код какой-нибудь известной библиотеки контролов - не извращаются там ребята, сами все рисуют как миленькие и пользуются исключительно стандартными приемами. Наверное, лохи

При появлении нового API от Микрософт выпускаем новую версию с поддержкой новых бантиков и берем за это дополнительные деньги.

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

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

Стремно выглядящий интерфейс - не самая большая проблема Дельфи... Надеюсь, дельфисты здесь не ходют, а то побьют.

Цитата(Earnest @ 4.8.2005, 06:23)

Проще (меньше кода) - не значит лучше...

"Проще" был как дополнительный аргумент. Главный аргумент - совместимость и корректность.

Цитата

Ну, 5 строчек будет.

Угу, попробуй сама сделать полность рисование и имитацию титле бара с кнопочками . Это только кажется, что раз-два и всё готово...

Цитата

Обрабатывать нужно не NCHITTEST (это же не NC-область)...

Это точно, это еще усложняет поставленную тобой задачу

Цитата

Как еще один аргумент - посмотри код какой-нибудь известной библиотеки контролов - не извращаются там ребята, сами все рисуют как миленькие и пользуются исключительно стандартными приемами. Наверное, лохи

Смотрю VCL - сами рисуют только графические контролы (TImage, TBitBtn и пр.) - остальные оставляют на участь винды. Не лохи.

Цитата

При появлении нового API от Микрософт выпускаем новую версию с поддержкой новых бантиков и берем за это дополнительные деньги.

Ню-ню. С таким отношением можно за каждый выход нового мелкого патча для винды выпускать новую версию программы...

Ты так и не объяснила, чем же плохо обрабатывать NCHITTEST - какие же будут последствия ? Опиши их поподробнее, чем же это грозит таким страшным, что нужно вместо 10 секунд сидеть полчаса кодить...
Я тебе уже описал несколько минусов твоего способа. Есть и другие проблемы. Например, многие видяхи в настройках имеют всякие штукенции, которые добавляют какие-нибудь кнопочки во все приложения - твоя программа будет обделена этой фичей... Да мало еще чего может быть - мы никак не можем узнать, что винда располагает в титлебарах, может в следующей винде там появяться еще какие дополнительные элементы...
Рисовать самому - это уже не стандартно. Давай так же: нафиг нам обычное чтение файлов, будем сами читать структуру FAT32 / NTFS и так читать файлы - чего нам стоит ? Здесь абсолютно такая же ситуация - лишний геморрой, хотя винда сама может всё сделать сама...

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

Цитата

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

Т.е. ты хочешь сказать, что запретить изменять размер оверлапеда и перемещать его - это запрещено ? К тому же где ты увидела, что речь идет именно об оверлаппедах, я говорю вообще про любое окно с титлебаром, не только оверлаппеды. Этому способу наплевать, оверлаппед оно или нет...

Цитата

Стремно выглядящий интерфейс - не самая большая проблема Дельфи...

А какая ? Расскажи поподробнее, мне интересно
И чем интерфейс Дельфи стремен ? Тем что, стандартный виндовый ? Тогда это претензии не к Borland, а Microsoft

Цитата

Надеюсь, дельфисты здесь не ходют, а то побьют.

Буду бить беспощадно, т.к. я модератор раздела Дельфи, готовься

(зы: )

ДОБАВЛЕНО ПОЗЖЕ
Блин, я сразу и не заметил, что ты девушка!
Эээ.. Пардон Везде в этом посту переправил глаголы.
А почему, собственно, "Эрнест" ? Я из-за этого и протормозил...