Intégration de Qt dans les applications MFC existantes

Question

Nous maintenons actuellement une suite d'applications MFC qui sont assez bien conçues, mais l'interface utilisateur commence à paraître fatiguée et une grande partie du code a besoin d'un peu de refactorisation pour résoudre certains problèmes de duplication et/ou de performances.Nous utilisons un certain nombre de contrôles personnalisés qui gèrent tous leurs propres dessins (tous écrits à l'aide de MFC).

Récemment, j'ai fait davantage de recherches sur Qt et les avantages qu'il offre (multiplateforme et prend en charge ce que vous pourriez appeler un cadre d'aspect plus "professionnel" pour le développement de l'interface utilisateur).

Ma question est - quelle serait la meilleure approche pour peut-être passer au framework Qt?Qt fonctionne-t-il bien avec MFC ?Serait-il préférable de commencer à porter certains de nos contrôles personnalisés vers Qt et de les intégrer progressivement de plus en plus dans nos applications MFC existantes ?(Est-ce possible?).

Tout conseil ou expérience antérieure est apprécié.

Answer 1

Dans mon entreprise, nous utilisons actuellement Qt et en sommes très satisfaits.

Personnellement, je n'ai jamais eu à déplacer une application MFC vers le framework Qt, mais voici quelque chose qui pourrait vous intéresser :

Cadre de migration Qt/MFC

Cadre de migration Qt/MFC

Cela fait partie de Qt-Solutions, cela signifie donc que vous devrez acheter une licence Qt avec une licence Qt-Solutions.(modifier: Pas plus)

J'espère que ça aide !

Answer 2

(Cela ne répond pas vraiment à vos questions spécifiques mais ...) Je n'ai pas utilisé personnellement QT, mais ce n'est pas gratuit pour le développement de Windows commerciaux.

As-tu regardé wxWindows qu'est-ce qui est gratuit ?Bel article ici.En passant, si vous souhaitez une base de code unique pour toutes les plates-formes, vous devrez peut-être migrer loin de MFC - je suis presque sûr (quelqu'un corrigera si c'est faux) que MFC ne cible que Windows.

Une autre option serait d'examiner Mise à jour du pack de fonctionnalités vers MFC dans SP1 de VS2008 - il inclut l'accès à de nouveaux contrôles, y compris les contrôles du ruban de style Office.

Answer 3

C'est un problème délicat, et je soupçonne que la réponse dépend du temps dont vous disposez.Vous obtiendrez un bien meilleur résultat si vous portez vos contrôles personnalisés sur Qt - si vous utilisez les classes QStyle pour effectuer le dessin, vous obtiendrez un code thématique dès la sortie de la boîte.

En général, mon conseil serait de serrer les dents et d’aller jusqu’au bout d’un coup.Bien sûr, cela peut prendre plus de temps, mais l'alternative est de passer du temps à essayer de déboguer du code qui ne fonctionne pas. assez jouer au ballon et finir par écrire plus de code pour gérer les incompatibilités mineures entre les deux systèmes (j'y suis allé, je l'ai fait).

Donc, pour résumer, mon conseil est de démarrer une branche, d'extraire tout votre ancien code MFC et de le remplacer par Qt.Vous obtiendrez l'indépendance de la plate-forme (presque) gratuitement, et même si cela prendra un certain temps, vous vous retrouverez avec un produit bien meilleur à la fin.

Un dernier mot d’avertissement :assurez-vous de prendre le temps de comprendre la "façon Qt de faire les choses" - dans certains cas, cela peut être très différent de l'approche MFC - la dernière chose que vous voulez faire est de vous retrouver avec du code Qt de style MFC.

Answer 4

J'ai déjà dirigé une équipe faisant ce genre de chose (pas de MFC vers QT mais les principes devraient fonctionner).

Nous avons d’abord documenté les boîtes de dialogue et quelles étaient leurs entrées, commandes et sorties.Nous créons également plusieurs cas de test spécialement pour toute logique intelligente à l'intérieur de l'interface graphique.

Parfois, nous avons dû refactoriser une certaine logique métier pour fournir une interface propre aux interfaces graphiques, mais c'est ainsi que cela aurait dû être fait en premier lieu.

Nous avions maintenant une liste d'interfaces graphiques, d'entrées, de sorties, de tests et une interface à laquelle l'interface graphique encapsulée devait correspondre.

Nous avons commencé, projet par projet, à créer des interfaces graphiques équivalentes aux anciennes.Une fois que nous avons fait cela, nous avons pu insérer l'interface graphique là où se trouvait l'ancienne, la reconstruire et la tester.Au début, nous avons beaucoup trébuché, mais nous avons rapidement résolu les erreurs courantes et les avons corrigées.Nous avons parcouru (je pense) 612 boîtes de dialogue, même si nous étions une équipe d'environ une douzaine d'entre nous qui travaillaient dessus.