Всем ночи доброй.
Такой вот вопрос: есть кусок кода

Код

if (FocusedLeft->Next() != NULL)  { FocusedLeft = FocusedLeft->Next(); UpdateWindow(hLeftWnd);

по этой обработке, по идее, переносится отображние фокуса на другой элемент (мой, я там сам все в WM_PAINT перерисую).

Так вот, корректно перерисует он только в том случае, если я, например, спрячу и покажу окно, или закрою его окном другого приложениея, и т.д. А мне нужно сразу. Как сказать - "возьми и перерисуйся"?
Добавлено @ 01:19
а, и еще: есть окно

Код

hLeftWnd = CreateWindow("RJ-Panel","Root", WS_CHILD|WS_VISIBLE|WS_BORDER|WS_CAPTION|WS_TABSTOP|WS_GROUP,                             0,0,0,0,hMainWnd,GetMenu(hMainWnd),hInst,NULL); SetFocus(hLeftWnd);

Можно ему как-то сказать подсветить синим заголовок - что оно активно? Заголовок хоть убей серый, неактивный.
Заранее спасибо.

Это сообщение отредактировал(а) Ibragim - 29.7.2005, 01:17

1) сделай так:

Код

if (FocusedLeft->Next() != NULL)  {     FocusedLeft = FocusedLeft->Next();     InvalidateRect(hLeftWnd, NULL, TRUE);

2) за место сет фокус попробуй воспользоваться SetActiveWindow

Спасибо, 1) - без коментариев, все прекрасно тут же заработало.

... а вот 2) не помогает
если не делаешь SetFocus - окно вообще не ловит сообщения, а SetActiveWindow ни к чему не приводит - никаких изменений. Может, лажа где-то в WS_XXX ?

Цитата(Ibragim @ 29.7.2005, 01:16)

а, и еще: есть окно Код hLeftWnd = CreateWindow("RJ-Panel","Root", WS_CHILD|WS_VISIBLE|WS_BORDER|WS_CAPTION|WS_TABSTOP|WS_GROUP,                             0,0,0,0,hMainWnd,GetMenu(hMainWnd),hInst,NULL); SetFocus(hLeftWnd); Можно ему как-то сказать подсветить синим заголовок - что оно активно? Заголовок хоть убей серый, неактивный. Заранее спасибо.

а про это по подробнее бы и коду побольше

C удовольствием:

Код

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) { ...... // Создаем главное окно приложения hMainWnd = CreateWindow(szAppName, szTitle, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, 0,CW_USEDEFAULT,                         0, NULL, NULL, hInstance, NULL); ShowWindow(hMainWnd, nCmdShow); UpdateWindow(hMainWnd); ...... // Создаем левую панель hLeftWnd = CreateWindow("RJ-Panel","Root", WS_CHILD|WS_VISIBLE|WS_BORDER|WS_CAPTION|WS_TABSTOP|WS_GROUP,                             0,0,0,0,hMainWnd,GetMenu(hMainWnd),hInst,NULL); // Говорим ей  - давай, становись активной SetFocus(hLeftWnd); SetActiveWindow(hLeftWnd); // Ну это просто чтобы размеры панели корректно отобразить PostMessage(hMainWnd, WM_SIZE, 0, 0); // И вот после этого всего все равно активное (синее) окошко главного окна, а hLeftWnd по-прежнему серое, хотя сообщения WM_KEYDOWN отлавливает hLeftWnd, то есть как-то оно все-таки активно :) ... наполовину :)

Если нужно, вот классы окон:

Код

WNDCLASS wc;     wc.style = CS_HREDRAW | CS_VREDRAW;     wc.lpfnWndProc = (WNDPROC)WndProc;     wc.cbClsExtra = 0;     wc.cbWndExtra = 0;     wc.hInstance = hInstance;     wc.hIcon = LoadIcon(hInstance, szAppName);//IDI_MAINICON);     wc.hCursor = LoadCursor(NULL, IDC_ARROW);     wc.hbrBackground = (HBRUSH) (COLOR_WINDOW);     wc.lpszMenuName = NULL;     wc.lpszClassName = szAppName;     WNDCLASS wpc;     wpc.style = CS_HREDRAW | CS_VREDRAW;     wpc.lpfnWndProc = (WNDPROC)PanelProc;     wpc.cbClsExtra = 0;     wpc.cbWndExtra = 0;     wpc.hInstance = hInstance;     wpc.hIcon = NULL;     wpc.hCursor = LoadCursor(NULL, IDC_ARROW);     wpc.hbrBackground = (HBRUSH) (COLOR_WINDOW + 1);     wpc.lpszMenuName = NULL;     wpc.lpszClassName = "RJ-Panel";

А если после

Цитата(Ibragim @ 29.7.2005, 12:48)

SetFocus(hLeftWnd);

ShowWindow(hLeftWnd, SW_RESTORE); // ну или SW_SHOW
по идее должно помочь.

Цитата

SetFocus(hLeftWnd);

SetForegroundWindow(hLeftWnd);

вот посмотри решение:
сделал я следуюющее: создал дав независимых окна(не установленно свойство WM_CHILD и тп)
послетого как создал делаю SetParent

Код

#include <windows.h> char name1[] = "wnd1"; char name2[] = "wnd2"; HWND hWnd1, hWnd2; HINSTANCE hInst; WNDCLASS wnd1, wnd2; LRESULT CALLBACK WndProc1(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); LRESULT CALLBACK WndProc2(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) {     hInst = hInstance;     wnd1.cbClsExtra = 0;     wnd1.cbWndExtra = 0;     wnd1.hbrBackground = (HBRUSH) COLOR_BACKGROUND;     wnd1.hCursor = LoadCursor(NULL, IDC_ARROW);     wnd1.hIcon = LoadIcon(NULL, IDI_APPLICATION);     wnd1.hInstance = hInstance;     wnd1.lpszClassName = name1;     wnd1.lpszMenuName = NULL;     wnd1.style = CS_HREDRAW | CS_VREDRAW;     wnd1.lpfnWndProc = WndProc1;     wnd2.cbClsExtra = 0;     wnd2.cbWndExtra = 0;     wnd2.hbrBackground = (HBRUSH) (COLOR_WINDOW + 1);     wnd2.hCursor = LoadCursor(NULL, IDC_ARROW);     wnd2.hIcon = LoadIcon(NULL, IDI_APPLICATION);     wnd2.hInstance = hInstance;     wnd2.lpszClassName = name2;     wnd2.lpszMenuName = NULL;     wnd2.style = CS_HREDRAW | CS_VREDRAW;     wnd2.lpfnWndProc = WndProc2;     if (!RegisterClass(&wnd1))     {         MessageBox(NULL, "Create wnd1 ERROR!!!", "ERROR", MB_OK);         return FALSE;     }     if (!RegisterClass(&wnd2))     {         MessageBox(NULL, "Create wnd1 ERROR!!!", "ERROR", MB_OK);     }     hWnd1 = CreateWindow(                     name1, name1,                     WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN | WS_CLIPSIBLINGS,                     CW_USEDEFAULT, CW_USEDEFAULT,                     CW_USEDEFAULT, CW_USEDEFAULT,                     NULL, NULL, hInstance, NULL);     if (NULL == hWnd1)     {         MessageBox(NULL, "Create hWnd1 ERROR!!!", "ERROR", MB_OK);         return FALSE;     }     ShowWindow(hWnd1, nShowCmd);     UpdateWindow(hWnd1);     hWnd2 = CreateWindow(                 name2, name2,                 WS_CLIPCHILDREN | WS_VISIBLE|WS_BORDER|WS_CAPTION|WS_TABSTOP|WS_GROUP,                 0, 0,                 100, 100,                 NULL, NULL, hInst, NULL);     if (NULL == hWnd2)     {         MessageBox(NULL, "Create hWnd2 ERROR!!!", "ERROR", MB_OK);     }              ShowWindow(hWnd2, SW_SHOW);     UpdateWindow(hWnd2);     SetParent(hWnd2, hWnd1);     MSG msg;     while (GetMessage(&msg, NULL, 0,0))     {         TranslateMessage(&msg);         DispatchMessage(&msg);     }     return msg.wParam; } LRESULT CALLBACK WndProc1(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {     switch(uMsg)     {     case WM_DESTROY:         PostQuitMessage(0);         break;     default:         return DefWindowProc(hWnd, uMsg, wParam, lParam);     }     return 0; } LRESULT CALLBACK WndProc2(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {     switch(uMsg)     {     case WM_DESTROY:         PostQuitMessage(0);         break;     default:         return DefWindowProc(hWnd, uMsg, wParam, lParam);     }     return 0; }

если не понравится решение, попробуй почитать сдесь:
http://www.lcard.ru/~nail/frolov/bsp/v17/ch1.htm#ch1_1

Спасибо за помощь всем откликнувшимся, трудовая ночь начинается, буду попробовать. Сегодня напишу, что получилось.

Да,
chaos, спасибо, все заработало!!
сэнкс.

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

Обрабатываешь сообщение WM_GETMINMAXINFO, в lParam - указатель на структуру MINMAXINFO. В ней ставь нужные размеры. Или сразу при обработке этого сообщения SetWindowPos(...);

а есть вариант просто убрать такую возможность в стиле окна? ну, например, чтобы пользователю нельзя было "ухватиться" за край окна?

Сейчас посмотрю...

Ага, вот стиль окна:

Код

WS_OVERLAPPED| WS_CAPTION| WS_SYSMENU|WS_MINIMIZEBOX

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

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

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

Если создавать дочернее, нет переключения между ними - не подсвечиваются заголовок. Мне 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

Цитата

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

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

(зы: )

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

Стоп-стоп-стоп p0s0l!
Мы о разных вещах спорим
Я во всем с тобой согласна, что касается максимального использования готового API и т.д. И NCHITTEST обрабатывать не проблема, очень полезное сообщение.
Но в данном конкретном случае - с чего все началось - помнишь? Создаем оверлаппед окно, а потом делаем его дочерним - и ради чего? чтобы стандартный заголовок иметь. А потом еще и бороться со стандартным его поведением - не перемещаться и т.д. Вот это мне и не нравится - какой-то проктологический подход.

Когда может возникнуть такая задача? Представляю 2 варианта: 1) Куча придоченных окон, собранные вместе на панели - но тогда за заголовок как раз и надо таскать. 2) Страничка проперти в современном стиле, не в окне с закладками, а когда слева дерево, а справа показывается набор параметров для текущего выбора - примерно как VC7 свойства проекта и настройки. Нужен весь описанный геморрой для 2-й задачи? Нужно, чтобы заголовок дочерней странички выглядел точь-в-точь как "настоящий"? А вот хлебнуть каких-нибудь проблем из-за того, что страница изначально создавалась как не-дочерняя - ты уверен, что их не будет? Что она будет получать и генерировать все положенные дочернему окну сообщения? И не посылать ничего лишнего? Будет ли оно с точки зрения системы дочерним, или все же нет? И куча т.д. Можно, конечно, все это проверить... Нет, возможно где-то в недрах MSDN есть статья где русским языком по-английски написано: если popup окну поставить парента, то оно превращается в честное дочернее окно. Может, там заодно написано, что с перетаскиванием за заголовок делать? Не попадалсь мне пока такая статья.
Если бы речь шла о том, чтобы прибить к экрану оверлаппед окно - то во всем ты прав, да и не о чем тут спорить.

Про Дельфи: про стремные кнопочки - это ты сам сказал, только это я и имела в виду. Мне не нравится язык - потому что это Паскаль (испорченный ), и еще больше мне не нравится устройство библиотеки - т.е. глубокая иерархия классов с множественным наследованием (это у них общее с борландовским С++). Внутри у нее все слишком перевязано. Если устраивают готовые компоненты, с изменениями поведения в запроектированных пределах, - все отлично и быстро пишется. Но если нужно что-то не стандартное - все, караул. Ну вот же оно, почти то что мне нужно, вот только здесь и здесь поменять! А фиг вам! Это private, здесь тоже и здесь, а вот эта функция не виртуальная... В общем, садись и переписывай половину кода. Что называется - близок локоть, да не укусишь. Раздражает. (MFC - да, убога по составу - но все, что там есть, я могу использовать из любой позиции с минимальными изменениями - т.е. практически везде, где нужно, торчат необходимые ручки).
Вот с базами данных у Дельфи хорошо (но тоже до известных пределов), но меня базы данных последнее время совсем не волнуют.

Цитата(p0s0l @ 4.8.2005, 07:54)

А почему, собственно, "Эрнест" ? Я из-за этого и протормозил...

А это фамилия моя бывшая... (ностальгия).

Цитата(Earnest @ 6.8.2005, 07:29)

Мы о разных вещах спорим

Ааа... Вот оно в чем дело... Ну ладно
Я только теперь понял, про что ты говоришь... На счет этого тоже кстати можно поспорить, но спорить не буду, т.к. вопрос на самом деле весьма спорный для меня самого (я много раз это делал, проблем не было, но выяснять конкретно о последствиях - не выяснял)...

Цитата(Earnest @ 6.8.2005, 07:29)

Про Дельфи: ...

Согласен, сам не раз натыкался на это... Но! Это бывает очень редко, когда необходим доступ к приватным данным и методам, когда необходим какой-то извращенный компонент; к тому же, просто я не любитель использовать компоненты третьих фирм, а сейчас этих компонентов столько развелось, что можно найти любой компонент, который только душа пожелает...
А что, в других библиотеках так прямо всё и доступно ? Это ж вообщем-то тоже не есть гуд...
Ну чего-то это совсем оффтоп пошел, сейчас модератор раздела заругается ...

Цитата(p0s0l @ 6.8.2005, 14:49)

Ну чего-то это совсем оффтоп пошел, сейчас модератор раздела заругается

Кхе-кхе... "В пределах нормы"

Действительно, начиналось всё с дочернего окна. Зачем там какие-то дополнительные элементы? Открываем MS Word 2003 и тянем в нём тульбарную панельку, утягиваем до обособления в дочернее окно. Обратите внимание на заголовок этого появившегося окна. Теперь меняем стиль на WinXP. Просто? просто. Красиво? красиво. А чего ещё надобно?..