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.Native API-Fenster-Designer
Was ist der beste Ansatz, um komplexe Fenster in reiner API zu entwerfen?
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.
Danke! Interessante und hilfreiche Artikel. Dies wies mich in die richtige Richtung :) –
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?
[Ironie] Natürlich darf nur Microsoft so etwas implementieren, oder? [/ Ironie] – peterchen
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.
Vielen Dank für Ihren Kommentar :) Einverstanden.Warum es nie gemacht wurde, war mehr, worüber ich mich wunderte. Warum konnte MS in Delphi nicht etwas Ähnliches wie VCL implementieren? –
Wie gesagt, MFC, wie es war - und ist - ist nicht mehr als reines Win32 geeignet. Vielleicht haben sie erkannt, dass sie mit MFC und ATL genug in UI-Frameworks investiert haben, um einen dritten Zweig nicht auf dem gleichen Level anzugehen. Business-wise, wahrscheinlich eine gute Entscheidung, die Ressourcen in .NET zu setzen. Aber das ist nur Spekulation. – peterchen
Verwenden Sie den Ressourcen-Dialog-Editor, um Ihr Dialogfenster visuell zu gestalten (nur verfügbar für VS Ultimate, aber nicht für VS Express). – dns