Avis sur évolution d'un control (Windows Forms)

Bonjour,

Je travaille sur un projet d'application, assez grosse. Avec une bibliothèque propre à l'entreprise en développement à côté. Et en ce moment, je me heurte à un conflit avec un collègue.

C'est à dire, nous souhaitons gérer des onglets dans ce logiciel, naturellement on a décidé de choisir le TabControl, mais assez vite j'ai trouvé ce control assez limité par Windows en terme de personnalisation et de pratique (Add/remove pour cacher un onglet plutôt visible=false ? :/), ce qui est bien dommage. Alors je comptais évoluer sur une technique de panel superposé, avec un panel de "navigation" contenant des boutons servant à afficher ou non les panels du dessous, impliquant une gestion d'events. Mais pour mon collègue c'est une hérésie de repenser un control déjà créé, à cause des normes etc etc.

Mais n'étant pas très calé en IHM, j'aimerais savoir quels problèmes je risquerais de rencontrer pour l'évolution de mon logiciel sur mon principe de panel superposé ?

Merci d'avance, en espérant avoir expliqué mon problème assez explicitement !

redévelopper un genre de tabcontrol mieux est faisable, il y en a d'ailleurs surement plusieurs sur le net mieux que celui de windows forms (certains payants certes)

je ne vois pas d'hérésie à créer autre chose que les controles de bases, il n'y a pas de normes ou autre chose, windows forms n'est compatible qu'avec windows forms de toute façon, technologie qui n'évolue plus depuis 2005
de plus le tabcontrol n'est qu'un container, qui n'a donc que peu d’interactions avec des données ou autre

après c'est comme tout il faut penser aux besoins, et à la rentabilité (temps de développement / temps gagné ou apport en qualité)
par exemple un tabcontrol qui demande un controle pour l'entete de chaque tabpage c'est mieux que celui d'origine, ca permet de mettre un label coloré ou un usercontrol évolué avec des boutons des voyants et autres (sans passer par du draw, car le tabcontrol de base permet déjà certaines trucs)

après le dessous de l'iceberg c'est le mode design, reproduire le comportement du tabcontrol en mode design ne doit pas être des plus simple

Merci beaucoup de ton avis Pol63, n'ayant pas le luxe de perdre trop de temps pour un tabControl "maison" super performant, je pense faire une classe de couple Bouton/Panel, et gérer ces couples dans un panel "conteneur", ainsi je reprendrais les méthodes "générales" (AddOnglet,RemoveOnglet,Index, etc), mais au minima des mes besoins, et à étoffer lorsque j'aurais le temps/besoin ...

Ainsi je laisse de côté le "TabPage" pour un "Panel/Bouton" en espérant que cela ne me posera pas trop de soucis, car si TabPage existe, c'est qu'il doit y avoir une bonne raison, et surement une gestion poussée derrière (?)

Je reste toujours à l'écoute d'avis :D

[HS] Pol63, tu commences à devenir célèbre au sein de notre département info, on te voit sur tous les forums où l'on cherche des réponses et indirectement tu contribues déjà au développement de notre projet, grand merci à toi :mrgreen: [/HS]

si c'est juste le visible sur le tabpage qu'il vous manqueca doit etre codable en quelques lignes avec les extension de méthode dans un module, dans les grandes lignes en rajoutant une fonction de stockage via remove, et donc la possibilité de réinsert un tabpage plus tard (avec un addhandler sur le tabcontrol.disposed pour le supprimer de la collection de stockage et le tabdapge est surement disposable)
c'est pas super joli mais niveau utilisation finale ca doit etre pas trop mal quand même

pour la personnalisation, avec un peu de code là aussi on doit pouvoir améliorer (je crois qu'on peut draw soit même le header, et donc coder ca avec quelques propriétés contenant ce qu'on veut mettre sur un inherits de tabcontrol)

Citation:

---

Envoyé par _Ez3kiel

[HS] Pol63, tu commences à devenir célèbre au sein de notre département info, on te voit sur tous les forums où l'on cherche des réponses et indirectement tu contribues déjà au développement de notre projet, grand merci à toi :mrgreen: [/HS]

---

de rien, je passerais à l'occasion et vous me payerez une bière ^^

Hello,

C'est pas du tout une hérésie de vouloir faire évoluer/repenser des contrôles déjà existant. Surtout que certains on clairement des manques niveaux fonctionnalités.

MAIS ca peut prendre du temps pour faire les choses "bien" et demander de bonne connaissance... Ce qui peut aussi se traduire par une augmentation du coup de maintenance non négligeable. Si en plus de ce casser la tête sur les bugs dans la partie buisness de votre appli, il faut aussi se casser la tête sur des trucs d'interface graphique.

Sachant qu'il existe pas mal de librairie déjà existante qui offre beaucoup de possibilité, j'essaierai déjà de voir s'il n'y a pas une solution de ce coté. C'est payant ok, mais je pense que ça couvre largement le gain de temps du développement homemade.

Au final c'est qu'une question de moyen... Si vous avez une star de winforms, GDI qui se tourne les pouces actuellement, n'hésitez pas à le faire. Si vous avez un peu de budget en rab pour faire l'aquisition d'une solution payante, tester les! Si vous avez ni l'un ni l'autre, concentrez vous plutôt sur le coeur de votre application!

Concernant le volet didactif, je dirais que niveau acquisition de connaissance, c'est jamais perdu. Mais de nos jours, il y a des trucs plus "utile" à apprendre que la création de contrôle Winforms

Citation:

---

(Add/remove pour cacher un onglet plutôt visible=false ? :/), ce qui est bien dommage.

---

On peut gérer en parrallèle avec le TabControl une List de l'ensemble des TabPage. Lorsqu'on veut cacher/visualiser un onglet, il suffit de faire un Clear() des Pages du TabControl et d'ajouter les pages visibles depuis la List complète.

Citation:

---

Envoyé par Graffito

On peut gérer en parrallèle avec le TabControl une List de l'ensemble des TabPage. Lorsqu'on veut cacher/visualiser un onglet, il suffit de faire un Clear() des Pages du TabControl et d'ajouter les pages visibles depuis la List complète.

---

Bonne idée :ccool: c'est un peu ce qu'on a repris dans notre principe. Un panneau TabbedPan, qui contient des couples boutons/panelsContenu (Class TabbedPanTab inherits Panel), ainsi qu'un panel menu pour y intégrer les boutons, et un panel contenu pour y intégrer les panelsContenu. Etant amené à être réutilisé partout dans l'appli, on essaye de le faire générique au maximum, et si possible ne pas se fermer entièrement sur l'évolution (Nouveau framework etc)

@pol63, oui cette notion de redraw avait été exploité, mais on trouvait ca assez bof de devoir redraw avec les bounds etc

@sinople, on a pas "d'expert Winforms", mais notre développeur asp s'y connait, surtout sur la partie archi-logicielle, et on ne souhaite pas intégrer de bibliothèque externe à la notre, on veut avoir la main au maximum sur notre projet, son évolution, sa maintenance etc. Et on préfère se taper nous-même pour nos mauvais choix, que taper sur les autres pour leurs mauvais choix. :mrgreen:

Bref, on progresse lentement, mais on progresse surement, il ne faut pas laisser un point noir qui deviendra un abcès dans l'évolution du logiciel !

Je vous tiendrais au courant si je rencontre des limites à ce choix.
Et si non, et bien "Pas de nouvelles, Bonnes nouvelles" ! :mrgreen: