Amis QT-eurs,
 
Comme vous le savez, QT 3 a introduit une nouvelle façon de coder les forms : on code toutes les fonctions membres de la classe de la form dans un fichier nom_de_la_form.ui.h, qui sera inclus par le fichier cpp généré par moc, alors qu'en version 2.xx, la méthode préconisée était de garder le code de la form d'origine dans le fichier form.cpp, puis de dériver cette form afin d'y rajouter les fonctions membres et les slots (subclassing). Cette méthode est également utilisable dans QT 3.
 
Vers quelle méthode va votre préférence ? Le subclassing de QT 2.xx ou l'inclusion de form.ui.h de QT 3 ?
 
Je trouve le subclassing beaucoup plus propre et plus orienté objet que le .ui.h. Par contre, si la form contient beaucoup de slots, ça peut être source d'oubli et/ou d'erreurs. Et si l'application contient beaucoup de forms, on finit par avoir une liste de fichiers source conséquente.
 
Bref, y'a du pour et du contre. Qu'en pensez vous ?
 

Moi je suis pour les CFormView, CFrame, et tout ça  
         

Salut Harkonnen,
 
Je suis comme toi, je préfère de loin la méthode de subclassing que je trouve vraiment plus clean.
 
Si la form contient bcp de slots, je pense qu'avec une ecriture clean, un classement des fonctions en section et des commentaires, tu peux tout de même facilement garder un code clean et eviter les erreurs.
 
M'enfin je ne suis vraiment pas un specialiste de QT alors mon commentaire est à moitié valable.

Merci pour ton avis
 
(encore un bide )

Je prefere pour ma part la methode de l'inclusion. Cela donne un resultat plus clair et tout autant objet a mon gout que la méthode de l'héritage. Il faut voir ca comme un generateur de code et pour un generateur de code, peut importe la forme finale obtenue. Ce qui compte c'est la facilité d'utilisation de ce système par le programeur.