Native API-Fenster-Designer

Question

Warum gibt es keinen Designer für native API-Formulare in Visual Studio? Ähnlich wie Delphi? Wenn es einige Programme, Tools usw. gibt, bitte Beratung.

Was ist der beste Ansatz, um komplexe Fenster in reiner API zu entwerfen?

Answer 1

Das liegt vermutlich daran, dass es in WinAPI keine Standardmethode zum Erstellen von Steuerungslayouts gibt. Sie müssen es selbst verwalten. Es gibt keine Basis "Control" -Klasse in WinAPI - alles ist ein Fenster von einer Art, also keine Möglichkeit, ihre Unterschiede mit einem gemeinsamen Layout-Editor/Designer zu unterstützen.

Sie können jedoch Ihr Fensterlayout in einem Dialog erstellen und es selbst in der Größe ändern oder Methoden verwenden, die auf Codeprojekt (this oder this) veröffentlicht werden - beide sind MFC-bezogen, aber das ist ziemlich einfach zu übersetzen).

Oder passen Sie ScreenLib an Ihre Desktop-Bedürfnisse an.

Answer 2

Es ist wegen Microsoft. Sie sind bereits auf dotNet und C# zugegangen. Visual Studio 2005 hat einen schönen GUI-Editor für diese. Warum müssen Sie die reine API verwenden?

Answer 3

Es gibt Ressourceneditor für Dialoge, und dann gibt es Code. Ich habe noch nie ein visuelles Design-Tool vermisst, obwohl eine bessere Unterstützung durch die Steuerung selbst nett wäre.

Das Kernproblem ist die Abstraktionsebene: mit nur Win32-Steuerelemente, das Entwerfen einer komplexen GUI braucht einige Voraussicht, und die Steuerelemente haben alle etwas andere Kuriositäten, Fähigkeiten und Funktionen. Sie verfügen nicht über eine gemeinsame Schnittstelle, über die ein Designer erstellt werden kann.

WinForms wurde von Grund auf mit Designer-Unterstützung entwickelt und es zeigt. Das Hauptproblem bei der Gestaltung von Win32-Steuerelementen war der Speicherbedarf von Code und Daten.

Sogar MFC (die immer noch viele Zeichen von Speicherknappheit zeigt) abstrahiert diese Kuriositäten nicht gut genug, um einen anständigen Formulardesigner zu rechtfertigen.

Alle Umgebungen, die mit einem anständigen Formulareditor (ich erinnere mich an Watcom ++/Optima, ZINC, und einige andere habe ich die Namen vergessen) kommen auch mit einer anständigen Formularbibliothek mit einem hohen Abstraktionsniveau.

Dann gibt es das Problem der Änderungen. Was sollte der Designer ausgeben? Man könnte für eine XML-Datei schießen, aber das würde einige große Bibliotheken zu Ihrer nativen App hinzufügen - macht wenig Sinn. Oder Sie erstellen Code, aber C/C++ ist dafür nicht gut geeignet. Ein anderes Binärformat? Sie würden sich darauf beschränken, was der Designer zulässt.

---

Am Ende würde der Designer hat jede Kontrolle separat kümmern, und konnte immer noch nicht isoliert von den Kontrollen und Fenstermechanismen von innen nach außen zu kennen. Es wurde nie unternommen, als C++ die erste Wahl für Desktop-Entwicklung in großem Maßstab war. Hinzufügen jetzt, wenn es - wohl - bessere Entscheidungen gibt, wäre eine ziemlich dumme Bewegung.