Собственный дизайнер окон API - PullRequest
2 голосов
/ 16 июля 2009

Почему в Visual Studio нет дизайнера для собственных форм API? Похоже на Delphi? Если есть какие-либо программы, инструменты и т. Д., Пожалуйста, совет.

Каков наилучший подход к проектированию сложных окон в чистом API?

Ответы [ 3 ]

3 голосов
/ 17 июля 2009

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

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

WinForms был разработан с нуля с учетом поддержки дизайнеров, и это видно. Основной проблемой дизайна элементов управления Win32 было использование памяти и кода.

Даже MFC (который все еще показывает много признаков нехватки памяти) не достаточно абстрагирует эти странности, чтобы гарантировать достойного дизайнера форм.

Все среды, которые поставляются с приличным редактором форм (я помню Watcom ++ / Optima, ZINC и многие другие, имена которых я забыл), также поставляются с приличной библиотекой форм с высоким уровнем абстракции.

Тогда возникает проблема модификаций. Каким должен быть результат работы дизайнера? Можно было бы использовать файл данных XML, но это добавило бы зависимость для некоторых больших библиотек в ваше нативное приложение - не имеет особого смысла. Или вы создаете код, но C / C ++ не очень подходит для этого. Еще один двоичный формат? Вы ограничитесь тем, что позволяет дизайнер.


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

1 голос
/ 17 июля 2009

Это, вероятно, потому, что в WinAPI нет стандартного способа создания макетов управления, вам нужно управлять им самостоятельно. В WinAPI нет базового класса «Control» - все это какое-то окно, поэтому нет способа поддержать их различия с помощью обычного редактора / дизайнера макетов.

Однако вы можете создать макет окна в диалоговом окне и изменить его размер самостоятельно или с помощью методов, опубликованных в codeproject ( this или this - оба связаны с MFC, но это довольно легко перевести).

Или адаптируйте ScreenLib к потребностям своего рабочего стола.

0 голосов
/ 17 июля 2009

Это из-за Microsoft. Они уже перешли к dotNet и C #. Visual Studio 2005 имеет хороший графический редактор для тех. Зачем вам использовать чистый API?

...