Windows Utilisation de l'interface native pour un programme - Page 1

yop,

J'utilise MSVC++ 2010 quand je fais un programme spécifique à Win (7). Mais apparemment, il faudrait une version Studio pour fabriquer des boites de dialogue comme Qt Designer ? J'espère que je me trompe ? Je peux pas utiliser un outil MS dédié à la création d'application utilisant l'interface native ?

Si tu veux créer des boîtes de dialogue Win32, il faut que tu utilises l'éditeur de ressources.
Tu dois créer une ressource de type Dialog à chaque fois que tu veux créer un nouveau type de boîte de dialogue.
Ces fenêtres s'utilisent légèrement différemment des fenêtres créées à la main (appel de CreateDialog ou DialogBox au lieu de CreateWindowEx (qui est apellée en interne)), mais ce sont pour le reste des fenêtres Win32 tout ce qu'il y a de plus standard.
Il y a normalement un support pour les boîtes de dialogues avec MFC (au lieu de l'API C) si jamais c'est ce que tu utilises, mais je ne connais pas suffisamment pour y indiquer quoi que ce soit.

Normalement, l'éditeur de ressources devrait être inclus dans ta version de Visual Studio, mais par contre il faut rassurer que tu aies bien installé les .h et .lib nécessaires au développement Win32. (On peut les installer via le Platform SDK si besoin)

Sinon, une façon "simple" de procéder c'est d'utiliser Windows Forms (.NET, donc) mais je ne pense pas que ce soit ce que tu recherches.

GoldenCrystal (./2) :
Il y a normalement un support pour les boîtes de dialogues avec MFC (au lieu de l'API C) si jamais c'est ce que tu utilises, mais je ne connais pas suffisamment pour y indiquer quoi que ce soit.

Visual Studio n'inclut plus le support des MFC dans les éditions Express, donc c'est cuit de ce côté-là.

Donc soit tu pars sur le modèle de développement classique qu'a décrit GC, soit tu regardes du côté des nouveautés (Windows Forms, WPF et autres, mais je ne sais pas si on peut les utiliser en C, je ne me suis jamais penché dessus).

GoldenCrystal (./2) :
Normalement, l'éditeur de ressources devrait être inclus dans ta version de Visual Studio

J'ai MS Visual C++ Express 2010, pas Visual Studio malheureusement... Et au prix de la license, c'est même pas envisageable :/

Le "modèle de développement classique", ça veut dire qu'il faut se taper toutes les boites de dialogue à la main ?

Non, tu peux les concevoir de manière graphique avec l'éditeur de ressources, par contre tu devras écrire le code pour gérer la boucle d'événements toi-même (c'est assez rustique).

Super. A moi de coder la boucle, au lieu de coder uniquement les évènements que j'utilise ? Même pas la peine :/

Rôh Folco, je t'ai connu plus combatif que ça

En fait il n'y a pas grand-chose dans la boucle de messages, y'a une fonction qui applique la gestion par défaut et qui suffit la plupart du temps. C'est un peu plus compliqué que la boucle SDL, mais pas énormément.

Zerosquare (./7) :
Rôh Folco, je t'ai connu plus combatif que ça

Faut partir du principe que je ne connais pas du tout l'API Win32, donc j'ai déjà 459286592784938021950369 pages de doc de classes à lire avant de coder le premier octet...

Ce n'est pas du C++ avec 36 millions de classes emberlificotées, c'est du C et la conception date de la fin des années 80 / début des années 90

Ah ? Marrant, ça fait rétro quand même, c'est dingue ça Ya rien qui est prévu pour le C++ dans l'API ?

Remarque, le C me va très bien, mais c'est pour le moins étonnant.

Il faut voir qu'à l'époque où ça a été conçu (certains concepts datent de Windows 2, voire 1), le C++ était loin d'avoir la notoriété et la maturité qu'il a maintenant.
Par contre, ça se prête plutôt bien à l'encapsulation en C++, les MFC étant justement l'implémentation officielle en C++.

Ils sont restés au C ISO tant qu'à faire ? Ou c'est un C MS à leur sauce ? ^^

Y'a quelques types et macros custom, mais ça reste du C, la preuve ça marche avec Code::Blocks qui est basé sur GCC ^^

Pour le coup y'a rien de vraiment très évolué dans l'API C de Win32. Ça reste comme ça parce que c'est facilement utilisable par n'importe quel langage.
(Par contre pour WinRT (dans Windows 8), tout est orienté objet, et ça devrait être beaucoup plus galère (suicidaire) d'utiliser l'API dans un langage non objet… ^^)

Zerosquare (./3) :
Visual Studio n'inclut plus le support des MFC dans les éditions Express, donc c'est cuit de ce côté-là.

Ah oui, je n'étais pas au courant. (C'est à dire qu'en fait je me fous un peu de MFC mais bon ^^)
D'ailleurs apparemment, la version express n'inclut pas d'éditeur de ressources (j'avoue, j'ai rarement utilisé la version C++), il faut utiliser un éditeur externe comme par exemple celui-ci : http://www.resedit.net/

Zerosquare (./7) :
En fait il n'y a pas grand-chose dans la boucle de messages, y'a une fonction qui applique la gestion par défaut et qui suffit la plupart du temps. C'est un peu plus compliqué que la boucle SDL, mais pas énormément.

Yep, c'est très simple, surtout depuis qu'on a internet et que toute la doc MSDN est lisible gratuitement…
Je pense que cette page résume bien le sujet de la gestion des messages : http://msdn.microsoft.com/en-us/library/windows/desktop/ms644928(v=vs.85).aspx
C'est pas très compliqué sur le principe général, mais écrire du code Win32 correct est assez rébarbatif et peu intéressant… Et écrire du code pas correct c'est mal !

(NB : Pour les jeux on utilise une forme de boucle particulière basée sur PeekMessage au lieu de GetMessage)

GoldenCrystal (./14) :
(NB : Pour les jeux on utilise une forme de boucle particulière basée sur PeekMessage au lieu de GetMessage)

(bôah, t'es pas obligé... tu mets ta boucle de message dans un thread à part, et zou
PeekMessage() c'est mal ! )

Interface utilisateur et multitâches ne font pas bon ménage… ^^
Sous Windows, tu ne trouveras quasiment aucun API d'interface qui soit thread-safe. (À part DirectX, en fait)

Et je ne vois pas en quoi PeekMessage serait mal… C'est très bien, au contraire !

GoldenCrystal (./16) :
Interface utilisateur et multitâches ne font pas bon ménage ^^

Mais si, c'est pas un souci tant que tout ce qui est UI Windows est géré par le même thread (et des jeux purement mono-thread, il ne doit plus y en avoir des masses ). Surtout que pour la gestion UI Windows, dans un jeu Direct X, y'a vraiment pas grand-chose à faire.

GoldenCrystal (./16) :
Et je ne vois pas en quoi PeekMessage serait mal… C'est très bien, au contraire !

C'est du polling, et le polling c'est mal, c'est des cycles et de l'énergie gâchée

Ben ouais mais pourquoi pomper 1+ Mo de RAM en créant un thread uniquement pour la boucle de messages Windows, au lieu de faire une bête boucle principale qui appelle PeekMessage une fois par frame ?
C'est pas parce que ton code est paralléllisé que ta procédure de rendu le sera, elle… (En pratique d'ailleurs, ce n'est pas vraiment le cas, sauf peut-être pour certains jeux très récents (et gourmands) qui utilisent DirectX11)

C'est crade sur le principe, c'est tout (et puis, 1 Mo de RAM en 2012... même moi je m'en fous )

Sinon y'a pas que la rendering, t'as aussi le son, l'AI, le réseau, potentiellement plein de trucs que tu peux threader.

Ben oui, mais typiquement dans ta boucle principale, tu caseras la gestion des messages et le rendu
Et donc PeekMessage… Enfin bref… Je ne sais pas si tout ça intéresse Folco

Si, j'ai ma réponse, donc vous m'intéressez.

GC > bah non, moi le rendering je le met dans un thread à part

Zerosquare (./3) :

GoldenCrystal (./2) :
Il y a normalement un support pour les boîtes de dialogues avec MFC (au lieu de l'API C) si jamais c'est ce que tu utilises, mais je ne connais pas suffisamment pour y indiquer quoi que ce soit.

Visual Studio n'inclut plus le support des MFC dans les éditions Express, donc c'est cuit de ce côté-là.

Donc soit tu pars sur le modèle de développement classique qu'a décrit GC, soit tu regardes du côté des nouveautés (Windows Forms, WPF et autres, mais je ne sais pas si on peut les utiliser en C, je ne me suis jamais penché dessus).

En fait, tu peux utilise les MFC "gratuitement" avec les version express, car bug il y a

Installer Visual Studio 2010 "Demo", et installer la version C++ Express, et paf tada: on peux compiler du MFC (Par contre pas d'editeur graphique pour les fichier ressources, mais on peux quand meme editer a la main

Mais Folco est quelqu'un de bien trop honorable pour utiliser ce genre de failles

C'est clair, surtout que si tu commences à développer ça, tu réinstalles ton système, et là ça marche plus, t'as plus qu'à écarter violemment les fesses.

Je signale au passage qu'il est évidemment possible d'utiliser les bibliothèques portables comme Qt ou wxWidgets même pour un projet monoplateforme, et que c'est ce que font les développeurs qui n'ont pas envie de s'embêter avec les MFC et avec le lock-in qui va avec (marche pas avec MinGW, notamment).

./22 > Mais au final, le surcout en mémoire et en synchronisation (thread ui <-> thread de rendu) dépasse probablement largement le (très) faible cout de PeekMessage dont tu te plains…
Programmer du code parallèle je trouve ça très amusant, mais ça complexifie vite le code (et en C++, n'en parlons pas), et ça reste quand même assez casse-gueule quand on débute… Et pour une application lambda (pas un jeu dernier cri DirectX 11.1, quoi…), l'intérêt reste quand même très limité, donc c'est pas forcément intéressant de vouloir balancer du multitâches à toutes les sauces.

./25 > Non, ce genre d'astuce marchera toujours, suffit de te garder la version demo au chaud dans un coin… Ou même mieux, tu sauvegardes les fichiers de développement dans une petite archive que tu mets à côté, et tu pourras les utiliser avec n'importe quelle version.

./26 > T'as du oublier la mention "interface native" qui est marquée dans le titre du sujet…
Sinon tu peux aussi coder une interface Windows Forms en C#, qui apellera le code C++ via P/Invoke. Le code tournera aussi bien sous Windows (.NET) que sous Linux ou OSX (Mono). Et il sera même possible de coder une interface totalement native pour n'importe quelle plateforme en appelant le code C++ de la même manière !
Et toc !

Kevin Kofler (./26) :
Je signale au passage qu'il est évidemment possible d'utiliser les bibliothèques portables comme Qt ou wxWidgets même pour un projet monoplateforme, et que c'est ce que font les développeurs qui n'ont pas envie de s'embêter avec les MFC et avec le lock-in qui va avec (marche pas avec MinGW, notamment).

Enfin, si tu veux le look & feel d'une application native, vaut mieux utiliser le framework de l'OS

Je rejoins 0² contre les "while (se_passe_t_il_qqchose())", surtout quand comme ici les threads pourraient se permettre d'être en pause une grande majorité du temps (même dans un jeu, on martèle rarement les touches toutes les quelques millisecondes). Si le coût pour continuer à utiliser GetMessage c'est d'avoir une pauvre queue asynchrone pour transférer les messages à l'unique thread GUI, alors ça me semble être quand même raisonnable niveau quantité de code.

D'ailleurs il me semble que c'est le comportement par défaut des signaux de Qt (mais loin de moi l'idée de conseiller ce framework si l'objectif est de faire du natif Windows, sauf pour ceux qui aiment les dlls de 30mo et les look & feel "presque natifs").

Zeph (./29) :
(même dans un jeu, on martèle rarement les touches toutes les quelques millisecondes)

Toi, tu ne joues pas contre des Coréens à SC II