2009-09-27 4 views
2

Просто для удовольствия Я разрабатываю собственный порт Win32 Mozilla XUL. XUL позволяет создавать сложные вложенные структуры всех видов макетов (hbox, vbox, grid, deck ..). Для моей реализации Windows было бы удобно реализовать их как дочерние окна STATIC. Потому что тогда я могу расположить их дочерние окна, используя x & y смещения независимо от положения родительского окна.Недостатки вложенности дочерних окон?

Однако этот подход может привести к тому, что некоторые окна имеют много вложенных дочерних окон. И мне интересно, будут ли какие-то недостатки в такой ситуации. Кто-нибудь здесь знает?

ответ

2

Я был на этом пути, и я не рекомендую вам делать глубокие иерархии окон. Многие вспомогательные функции Windows (например, IsDialogMessage) работают лучше с «традиционными» макетами. Кроме того, окна в Windows являются относительно тяжелыми объектами, в основном по историческим причинам. Итак, если у вас есть множество объектов, вы можете столкнуться с ограничениями, проблемами с производительностью и т. Д.

То, что я сделал вместо этого, состоит в том, чтобы представить глубоко вложенную компоновку как дерево регулярных объектов C++, которые параллельны более плоской иерархии фактические окна. Некоторые узлы иерархии объектов имеют HWND «реальных» окон, которые они представляют. Вы указываете иерархию, чтобы выложить, и узлы применяют результаты к соответствующим окнам.

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

+0

Это именно то, что я делаю! Например, для макета сетки у меня есть класс с именем VirtualGrid. Он просто знает прямоугольник, на который он может рисовать, и не полагается на собственное окно. Единственное исключение, которое я сделал до сих пор, это прокрутка. Поскольку гораздо проще прокручивать одиночное статическое окно, чем кучу дочерних окон в определенной области. – StackedCrooked

0

Грубая взять на это:

  • накладные расходы памяти для управления окном на APPLICATION- и ос стороны
  • снижение скорости из-за обращений к внешней библиотеке/зева, которые делают намного больше для окон, чем нужно для применения
  • возможно довольно много накладных расходов через длинных путей сообщений окна в сложных раскладок

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

Смежные вопросы