Win32: CreateDialog вместо нескольких вызовов CreateWindow - есть ли недостатки?

Question

В настоящее время я работаю над программой Win32, для которой требуется главное окно, содержащее множество дочерних оконных элементов управления - кнопки, списки и т. Д. Я считаю, что стандартный способ создания такого окна - сначала вызвать CreateWindow для главного окна, а затем снова для каждого из элементов управления.

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

Используя оператор CLASS в шаблоне диалогового окна, я смогу заставить главное окно использовать пользовательский класс окна (и, следовательно, пользовательскую оконную процедуру) и, таким образом, избегать окна, имеющего какое-либо диалоговое поведение. Пример этой техники можно найти в «Программировании Windows» Чарльза Петцольда: программа HEXCALC в главе 11 .

Есть ли недостатки в создании моего главного окна таким образом? Если так, то кто они? Если нет, то почему этот подход используется редко?

Answer 1

Вы не получаете контроль над циклом сообщений главного окна - менеджер диалогов обрабатывает его за вас. С другой стороны, диспетчер диалогов управляет ускорителями клавиатуры, упорядочением табуляции и рядом других эффектов.

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

Answer 2

Единственный недостаток CreateDialog, о котором я знаю (по сравнению с повторяющимся CreateWindow, не говоря уже о какой-то тяжелой инфраструктуре, просто Win32 против Win32), это то, что ресурсы диалога позиционируют дочерние окна с помощью диалоговых модулей.Таким образом, макет зависит не только от DPI, но и от настроек темы пользователя (выбор и размер шрифта).

Если любой из ваших элементов управления должен иметь фиксированные размеры в пикселях, вы не будетебудьте довольны позиционированием, обеспечиваемым диалоговым окном, и вам нужно будет пройти и переместить все дочерние окна после факта.

Так что да, вы можете использовать CreateDialog в качестве ярлыка для создания группы окон с указаннымклассы и стили.Но нет, вы не можете сделать свой макет в диалоговом редакторе.

OTOH, вы можете сохранить преобразование пикселей DLU <->, используемое на вашей машине проектирования, а затем достаточно узнать о синтаксическом анализе внутреннего формата ресурса DIALOG.вытащить информацию о местоположении, затем преобразовать в пиксели и откорректировать позиционирование более автоматизированным способом.

Answer 3

Вы сможете иметь полный контроль над своим окном, даже если оно было создано с помощью CreateDialog.

Обычно, когда вы создаете свое собственное окно (вашего класса), используемая оконная процедура - та, которую вы зарегистрировали в классе.Окна OTOH, созданные с помощью CreateDialog, будут иметь стандартную диалоговую процедуру окна (DefDlgProc), которая в основном будет вызывать предоставленный вами «обработчик диалога».

Если вы хотите иметь полный контроль над всеми сообщениями,замените процедуру окна только что созданного окна сразу после его создания.Просто позвоните SetWindowLongPtr с параметром GWLP_WNDPROC.Тем не менее, вы можете выполнить автоматическую обработку некоторых вещей, относящихся к диалогу, вызвав IsDialogMessage в вашей процедуре.

Answer 4

Существует нет недостатков вообще.

Почему это редко используется?Потому что:

• Вместо этого люди обычно используют DialogBox, поскольку это проще для простых случаев.

• В более сложных случаях люди используют вещикак MFC или ATL (или какая-то внешняя библиотека, такая как GTk или Qt), и не беспокойтесь о нативной графике Win32.

Answer 5

Нет недостатков в использовании Windows SDK, внутренние библиотеки, такие как MFC, используют Windows SDK.

Люди склонны использовать библиотеки, такие как MFC, вместо Windows SDK, поскольку в библиотеках есть готовые вещи. Однако вызовы Windows SDK выполняются быстрее, чем вызовы из библиотеки, поэтому в некоторых ситуациях разработчики вызывают Windows SDK напрямую.

CButton btnOk ;
btnOK.Create(_T("Press Me"), WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,CRect(100,100,300,300), pParentWnd, 1);

похож на следующий код,

HWND hWnd = CreateWindow("BUTTON","Press Me",WS_CHILD|WS_POPUP|BS_DEFPUSHBUTTON,100,100,300,300,NULL,NULL,GetModuleHandle(NULL),NULL);
ShowWindow(hWnd,SW_SHOW);