concepteur fenêtre API native

Question

Pourquoi est-il pas un concepteur pour les formulaires api natifs dans Visual Studio? Semblable à Delphi? S'il existe certains programmes, outils etc, s'il vous plaît des conseils.

Quelle est la meilleure approche pour concevoir des fenêtres complexes dans l'API pure?

Answer 1

C'est probablement parce qu'il n'y a aucun moyen standard de faire de contrôle mises en page dans WinAPI, vous devez le gérer par vous-même. Il n'y a pas de base classe « Control » dans WinAPI -. Tout est une fenêtre de quelque sorte, donc aucun moyen de soutenir leurs différences avec un éditeur mise en page commune / concepteur

Vous pouvez toutefois créer votre mise en page de la fenêtre dans un dialogue et faire redimensionnable par vous-même ou en utilisant des méthodes publiées sur CodeProject ( ce ou cette - les deux sont MFC-lié, mais qui est assez facile à traduire).

Ou adapter ScreenLib à vos besoins de bureau .

Answer 2

Il y a éditeur de dialogues pour ressource, et puis il y a le code. Je ne l'ai jamais vraiment manqué un peu l'outil de conception visuelle, bien que certains meilleur soutien des contrôles eux-mêmes serait bien.

Le problème de base est le niveau d'abstraction: en utilisant seulement les contrôles Win32, la conception d'une interface graphique complexe a besoin d'un peu de réflexion, et les contrôles ont tous bizarreries légèrement différentes, des capacités et fonctionnalités. Ils ne disposent pas d'une interface commune qui peut être utilisé pour construire un concepteur sur le dessus.

WinForms a été conçu à partir du sol avec le soutien du concepteur à l'esprit, et il montre. La principale préoccupation de la conception des contrôles Win32 était empreinte mémoire du code et des données.

Même MFC (qui montre encore beaucoup de signes de pénurie de mémoire) ne abstraite ces bizarreries loin assez bien pour justifier un concepteur de formes décent.

Tous les environnements qui viennent avec un éditeur de formes décent (je me souviens Watcom ++ / Optima, ZINC, et pas mal d'autres, je l'ai oublié les noms) viennent également avec une bibliothèque de formulaires décente avec un haut niveau d'abstraction.

Ensuite, il y a le problème des modifications. Quelle devrait être la sortie du concepteur? On pourrait tirer d'un fichier de données XML, mais cela ajouterait une dépendance à certaines grandes bibliothèques à votre application native - ne fait pas beaucoup de sens. Ou vous créez code, mais C / C ++ ne convient pas à cela. Un autre format binaire? Vous souhaitez vous limiter à ce que le concepteur permet.

---

En fin de compte, le concepteur devra prendre soin de chaque contrôle séparément, et ne peut toujours pas vous isoler de connaître les contrôles et les mécanismes de fenêtre intérieur. Il n'a jamais été entreprise en C ++ a été le premier choix pour le développement à grande échelle de bureau. Ajoutant maintenant , quand il y a - sans doute -. De meilleurs choix, serait un mouvement assez stupide

Answer 3

Il est à cause de Microsoft. Ils ont déjà évolué vers dotNet et C #. Visual Studio 2005 a bel éditeur de GUI pour ceux-ci. Pourquoi avez-vous besoin d'utiliser l'API pure?