Elle n’a d’effet que sous Windows, mais permet une évolution graphique constatable.
Son paramètre est une variable dérivée de wxWindow, par exemple wxButton.
Je te conseille de l’essayer sur tes wxTreeCtrl et tes wxListCtrl et dérivés, mais aussi sur le plus grands controles natifs. Je ne l’ai personellement testée que sur ces 2 premiers et ils améliorent bien l’apparence. de toute façon, si ça ne marche pas, tout ce qu’il y a, ce que l’apparence du contrôle reste inchangée, c’est tout.
Particulièrement, sous vista, les wxToolbar ne marchent pas, rien de testé pour les autres contrôles. Autre précision, je pense que ça ne marche que sur Vista+.
Tu auras besoin d’inclure <wx/msw/uxtheme.h>.
Par exemple :
wxListCtrl* list = new wxListCtrl(parent,id);
wxMswApplyMui(list);
Je ne vous dis pas ce que ça fait pour vous en laisser la surprise. Tout ce que je peux vous garantir, c’est que ce n’est pas un virus (de toute façon, on ne peut pas faire un virus en une macro).
Chez moi j’ai pu corriger le problème en utilisant GetHWND à la place de GetHwnd. Pas besoin d’inclure windows.h
J’ai testé ça sur quelques contrôles ( mais sans la macro, les macro c’est le mal, y en a pas besoin ici ) et ça marche en effet assez bien, je ne savais pas que Windows faisait exprès d’afficher par défaut des contrôles moches.
Enfin, ça remplace essentiellement les rectangles pleins de sélections en des jolies bordures graphiques ( Style “explorateur windows” comme l’indique le L"Explorer" ), ce qui est déjà pas mal.
EDIT :
Je viens de trouver cette page : codeproject.com/KB/vista/the … trols.aspx qui traite du sujet en question. Apparamment, ça se limite aux wxTreeCtrl et au wxListView, le reste utilisant déjà le thème le plus récent disponible.
Désolé, ce n’était pas windows.h mais bien <wx/msw/uxtheme.h>qu’il fallait inclure.
J’utilise ici une macro parce que je veux généraliser ça sans générer de code supplémentaire, mais si tu veux, tu peux en faire une fonction, un snippet, ou ce que tu veux.
LOL Ce n’est pas que windows le fasse “exprès”, mais ça vient du moteur de thèmes.
Pour développer l’explorateur, Microsoft a créé un nouveau thème qu’ils ont baptisé “EXPLORER” (le L indique que c’est une wchar_t*, mais ça tu le savais déjà) mais les applications utilisent normalement le thème par défaut, que tu qualifies de "moche. Par cette macro, tu indiques à Windows que tu veux que ton contrôle utilise le thème de l’explorateur, ce qui affecte le dessin par défaut des contrôles.
Il semble bien que ça se limite là, et ça s’explique par le fait que ce sont ces 2 contrôles que l’explorateur utilise le plus. Tu remarqueras d’ailleurs l’apparition de boutons “twister” sur les wxTreeCtrl (les boutons en flèches qui remplacent les +/-. ce qui se fait par un style : http://docs.wxwidgets.org/trunk/classwx_tree_ctrl.html (Doc officielle wxWidgets). Le reste des contrôles ont déjà la meilleure apparence car leur nouveau design fait partie de thème par défaut.
si vous avez des problèmes, je pense que c’est à cause du fait que vous ne respectiez pas une règle fondamentale qui dit “La version des bibliothèques, tu vérifieras” ( XD). J’imagine que vous en êtes restés à wxWidgets 2.9.1, alors que sous la 2.9.2, ça fonctionne bien.
De plus, 4ian, tu devrais trouver un intérêt aux contrôles wxCommandLinkButton at wxInfoBar (cherches leur nom sur la doc). Moi aussi ils m’ont bluffé.
Sinon, ta page est superbe, bien qu’elle parle surtout du .NET et pas du C++ (fallait bien que je trouve quelque chose à redire) et du devrais t’en inspirer pour me faire des hacks de ce genre en combinant GetHwnd() et des fonctions de la WinApi (inspires toi de ta page et de MSDN, tu dois pouvoir arriver aux mêmes résultats que sur ta page)
Avec un logiciel comme GD, j’ai pas trop le temps de mettre à jour wxWidgets à chaque nouvelle version. Je le fait que si j’ai besoin d’une nouvelle fonctionnalité ou si c’est pour corriger un bug spécifique. Mon but est d’avoir une version récente et stable. ( Le risque avec les nouvelles versions étant aussi de souffrir d’éventuels nouveaux bugs, ça m’est déjà arrivé avec SFML par exemple. )
Oui, je sais, mais un développeur peut s’attendre à ce que Windows utilise une apparence la meilleur qui soit pour tous les contrôles sans avoir besoin de recourir à ce genre de hack.
J’essaye justement au maximum d’éviter les hacks de ce genre : Autant avoir un code qui reste aussi générique que possible, c’est wxWidgets qui s’occupe de tout ce qui est spécifique à la plateforme. Ici, ça reste assez correct même si c’est du code spécifique à la plateforme.
Mais de toute façon, à part les wxTreeCtrl et wxListView qui ne profitaient pas du meilleur design qui soit, le reste des contrôles est déjà dans “le plus bel état” possible.
Au fait, comme on parlait (dans une autre rubrique, mais le sujet reste le même) d’interface, je te recommande de lire ce document concernant les règles de base du design d’interfaces qui pourraient t’être très utiles pour améliorer l’interface de GD.
Attention, le document est en Anglais et demande un certain niveau, mais au moins, on est sùr que ses données sont correctes puisqu’il vient de Microsoft elle-même…
Tu devrais, et même tu DOIS le lire en tant que développeur (et tout développeur qui se respecte et qui ne l’a pas déjà fait aussi) puisque ça décrit les règles fondamentales du design d’une interface utilisateur. Je dirais même que tu aurais du le lire avant de commencer ton interface (même s’il faut avouer que tu t’es bien débrouillé sans). Normalement, si tu l’as bien compris, tu devrais penser à des tas de changements sur ton interface. On doit tous passer par là un jour où l’autre, et ajourd’hui c’est ton tour !
N’aies pas peur d’y passer du temps (bien que les 3 dernières ne te soient pas très utiles pour l’instant)
PS: Je vous déconseille fortement d’utiliser un traducteur sur ces documents sous peine d’avoir une traduction absurde puisque ce sont des documents parlant d’informatique et avec un certain niveau de langue.
Par exemple, 4ian, tu devrais prendre en compte cet extrait des Guidelines Windows :
Pour l’appliquer au dialogue des mises à jour qui devien assez barbant quand on utilise GD sur un ordinateur qui n’est connecté que de temps en temps et qu’on veut laisser les mises à jour activées pour éviter d’avoir une version trop vieille. Ou alors, trouves une autre façon de notifier de l’erreur sans interrompre le “control flow” avec une boîte de message qui en plus provoque un vacarme assourdissant (je voulais dire un petit bruit dérangeant ), comme par exemple un message dans la barre de statut, un texte qui s’ajoute à la page de démarrage (en une couleur flashy pour qu’on le remarque) ou alors, utilises la nouvelle classe wxInfoBar
A noter que la fenêtre de mise à jour peut être désactivée dans les options, même si une case pour le faire dans la fenêtre elle même serait mieux j’avoue.
Je ne veux pas désactiver complètement les MAJ, juste que GD trouve un meilleur moyen de nous en avertir, parce que le message d’erreur à chaque démarrage, au bout d’un moment, il y a de quoi devenir chèvre.
Dans ce cas 4ian, pourquoi ne rajouterais-tu pas une notification seulement lorsqu’il y a une mise à jour trouvée ? Et puis, les mises à jour ce n’est pas important, ce n’est pas comme Windows, Game Develop ne risque pas d’avoir un virus parce qu’il n’est pas à jour… Autant enlever cette fenêtre que je qualifierai d’intempestive. N’affiche des boîtes de dialogue que lorsque c’est absolument nécessaire.
C’est exactement le genre de chose qui est dite dans les Guidelines. Les as-tu lues ?
Sinon, c’est une très bonne idée, mais j’insisterai sur le fait qu’il faille garder une façon d’avertir l’utilisateur, en utilisant un effet sur la page d’accueuil.
Voir cette section des Guidelines de Windows : http://msdn.microsoft.com/en-us/library/windows/desktop/aa511285.aspx
Il n’y a aucune raison d’éviter ce hack !
Si tu utilises la technique exacte contenue dans cette macro, il n’y a aucun effet sur les versions de Windows ne supportant pas les thèmes.
sinon, si tu comptes utiliser ce code sous Linux, utilises la compilation conditionnelle (#ifdef, #if, #endif…) pour la rendre inactive :
Après une petite recherche, j’ai trouvé la vraie raison pour laquelle les listes (wxListCtrl) et les arbres (wxTreeCtrl) ne s’affichent pas avec leur meilleure apparence par défaut, contrairement aux boutons, progressbars…
Les contrôles dans Windows sont rangés dans une bibliothèque nommée “common controls” (commctl32.dll). Cette bibliothèque contient tous les controles dans leur plus belle version sous Vista, voila pourquoi ils s’affichent bien.
Cependant, les “beaux” thèmes pour les listes et les arbres ne sont pas inclus dans les “common controls”, mais dans un thème UX séparé (uxtheme.dll) qu’il faut donc charger et appliquer.
Au fait, pourquoi ne pas utiliser ces améliorations dans une prochaine version de GD ? Même si j’ai déjà un programme externe qui permet d’appliquer ce genre de combines à une fenêtre en lui cliquant dessus, ce n’est pas le cas de tout le monde.
Et puis, j’ai envie de dire, normalement dans l’absolu c’est aux gestionnaires de fenêtre/d’interface utilisateurs qui doivent se débrouiller pour rendre mes contrôles de la meilleure façon qui soit, c’est pas à moi d’aller écrire du code spécifique pour profiter du must.
( Enfin, je suis quand même preneur si jamais il y a une astuce pour linux, mais normalement y a pas de raison pour qu’il y en aient, de telles “astuces” : On s’attend à ce que la bibliothèque qui gère le fenêtrage affiche tout de la meilleure façon qui soit par défaut ).
) et ça marche en effet assez bien, je ne savais pas que Windows faisait exprès d’afficher par défaut des contrôles moches. 
), comme par exemple un message dans la barre de statut, un texte qui s’ajoute à la page de démarrage (en une couleur flashy pour qu’on le remarque) ou alors, utilises la nouvelle classe wxInfoBar
).