Discussion :

[LeonCosnyd]

Bonjour,

J'aimerais avoir votre retour d'expérience sur la conception (architecture) d'un logiciel. Et plus particulièrement les techniques que vous utilisez afin de créer les bases du logiciel. J'ai bien conscience que ceci est vraiment la base mais j'aimerais savoir si je n'ai pas raté quelque chose.

Voici un exemple :
Création d'un logiciel métier (progiciel) qui comportera de nombreuses fonctions (et donc fenêtres). Celui-ci devra être redimensionnable.

Voici mes interrogations sur l'architecture du projet:
Je me demande quelle est la meilleure solution dans ce cas. Je vois 3 solutions possibles mais je ne sais pas ce qu'elles valent :
- Succession de fenêtres modales. Je vois alors une succession de Ouvresoeur(NouvelleFenetre) suivi de Ferme(FenetreCourante). Mais ce cas pose problème quant au redimensionnement des fenêtres. Il faut gérer manuellement la position X/Y et la taille hauteur/largeur de la fenetre que l'on ouvre pour qu'elle est la même place que la fenêtre mère (du moins je ne connais pas de système automatique pour le faire). Évidemment je ne souhaite pas que l'utilisateur ai a redimensionner une par une toutes les fenêtres qui s'ouvrent... Une fois la fenêtre en cours redimensionnée, les autres doivent respecter cette taille/emplacement.
- Utilisation des fenêtres internes. Dans ce type d'architecture on aurait une fenetre "principale" contenant un champ fenetre interne qui contiendrait pratiquement tout le contenu. Les différentes fenetres seraient donc toutes des fenetres internes qui se mettraient dans le champ de la fenetre principale quand on veux l'afficher. Le redimensionnement ne serait à faire que sur la fenetre principale. Et avec l'ancrage les autres fenetres internes s'intégreraient automatiquement dedans.
- Utilisation de fenêtre MDI. Je ne connais pas très bien cet technique mais j'ai pu lire sur le net que le système MDI est un système ancien, pas très adaptatif et qu'il vaut mieux l'éviter (les raisons je ne les connais pas donc je préfère quand même me poser la question moi-même sur ce système).

[frenchsting]

Je me demande quelle est la meilleure solution dans ce cas. Je vois 3 solutions possibles mais je ne sais pas ce qu'elles valent :
- Succession de fenêtres modales. Je vois alors une succession de Ouvresoeur(NouvelleFenetre) suivi de Ferme(FenetreCourante). Mais ce cas pose problème quant au redimensionnement des fenêtres. Il faut gérer manuellement la position X/Y et la taille hauteur/largeur de la fenetre que l'on ouvre pour qu'elle est la même place que la fenêtre mère (du moins je ne connais pas de système automatique pour le faire). Évidemment je ne souhaite pas que l'utilisateur ai a redimensionner une par une toutes les fenêtres qui s'ouvrent... Une fois la fenêtre en cours redimensionnée, les autres doivent respecter cette taille/emplacement.

Si tu fais des ouvresoeur(), tu vas te retrouver avec des fenêtres partout. Les utilisateurs doivent être "bridés" (guidés pour faire poli).
Il suffit que tu utilises des ouvre(). Chaque fenêtre pourra être redimensionnée par l'utilisateur.

[LeonCosnyd]

Bonjour frenchsting,

Mon optique est de créer l'illusion qu'il n'y a qu'une seule fenêtre dans l'application. Un peu à la sauce Windev en fait. Une fenêtre principale avec d'autres fenêtres qui s'ouvrent de manière "intégrer" à la fenêtre principale.

[Romanops]

Dans ce cas, tu dois empêcher l'utilisateur de voir les fenêtres filles ouvertes en arrière plan. J'avais fait cela un jour dans un de mes projets. Il ne faut pas mettre de barre de menu dans ta fenêtre principale (mère mdi), et afficher toutes les fenêtres filles en maximisées à l'ouverture.

Pour les utilisateurs avancés d'ordinateur, le raccourcis CTRL + TAB leur permettra toujours de naviguer entre les fenêtres filles il me semble par contre...

[fffttt]

le mdi ca fait pas old school, mais juste naze!

Perso, j'aime bien les fenêtres internes.

[frenchsting]

Je n'avais pas compris l'idée "mono-fenêtre"...

Les fenêtres internes semblent adaptées. Et si tu as peu de fenêtres, pourquoi ne pas envisager les plans ?

[Ry_Yo]

Bonjour,

Personnellement, je suis adepte de la fenêtre interne. Cela oblige à avoir une fenêtre assez robuste pour être paramétrable et donc recyclable. Et depuis l'ajout des onglets dynamique, je l'utilise encore plus.

Concernant les plans, je ne suis pas fan, mais c'est un avis perso. Je ne me sers des plans que rarement, car on arrive très facilement à des "doublons" de nom de bouton ou champ... du coup, soit on préfixe par le numéro du plan ou alors on précise encore plus le libellé du bouton (ex: BTN_VALIDER_1 ou BTN_VALIDER_CLIENT, etc...)

[LeonCosnyd]

Je suis également tenté pour dire que la solution qui me permettrait une "meilleure" organisation du projet serait celle des fenêtres internes mais comme je n'ai jamais réalisé de gros projet avec ce système j'ai un peu peur de me retrouver limité/bloqué à un certain moment à cause de quelques choses que je n'aurais pas vu et que je ne saurais pas.

Les plans je les utilisent de temps en temps pour des situations biens précises et en quantité limitée. Vu l'ampleur du projet je ne pense pas que cela soit la solution.

[tbc92]

Tu dis que les fenêtre en arrière devront être inaccessibles, et tu fais référence à la présentation des fenêtres dans Windev.

Dans Windev, tu as une partie de l'écran qui est une fenêtre MDI . C'est la partie de l'écran en principe la plus grande.
Et avec les fenêtre MDI, l'utilisateur peut switcher d'une fenêtre à l'autre. Tu ne peux pas 'condamner' temporairement telle fenêtre.

Et tu as par ailleurs des fenêtre de type ASSISTANT. Par exemple, la fenêtre pour compiler un projet est une fenêtre de type assistant. C'est une fenêtre modale, avec plusieurs plans. Et à chaque fois que tu cliques sur suivant, tu change de plan.
Quand tu ouvres cette fenêtre modale, tu ne peux plus accéder aux fenêtre en arrière plan.

Avec les fenêtres filles-MDI, si tu as sélectionné 'Taille Maximisée', toutes les fenêtre filles ont la taille de la fenêtre mère.
Aujourd'hui, la mode n'est plus aux fenêtres MDI, mais aux fenêtres avec des onglets. Internet-Explorer par exemple était organisé en fenêtres MDI jusqu'en 2005 à peu près, et est maintenant présenté sous forme d'onglets. Idem Excel a longtemps été sous forme de fenêtre MDI, et ce n'est plus le cas aujourd'hui.

Si tes utilisateurs ont 50 ans ou plus, ils seront très contents d'avoir du MDI. S'ils sont plus jeunes, bof.

[fffttt]

Bonjour,

Personnellement, je suis adepte de la fenêtre interne. Cela oblige à avoir une fenêtre assez robuste pour être paramétrable et donc recyclable. Et depuis l'ajout des onglets dynamique, je l'utilise encore plus.

Concernant les plans, je ne suis pas fan, mais c'est un avis perso. Je ne me sers des plans que rarement, car on arrive très facilement à des "doublons" de nom de bouton ou champ... du coup, soit on préfixe par le numéro du plan ou alors on précise encore plus le libellé du bouton (ex: BTN_VALIDER_1 ou BTN_VALIDER_CLIENT, etc...)

tout à fait d'accord.
pour compléter ma réponse ci dessus
On risque les doublons, on a une chiée de procédure dans la fenêtre
de plus l'usage de plan ralenti l'ensemble (ex chargements des champs table sur des plans cachés....)

Enfin, la personne qui reprend ce genre de fenêtre ne voit pas tout au 1er coup d'oeil.
personnellement, j'évite totalement à part pour des fenêtres de type "assistant"

[gabcouts]

Bonjour,

J'utiliserais les fenêtre internes avec un Fenêtre Principal.

Mon seul problème avec les fenêtres internes était qu'à chaque chargement d'une fenêtre interne, l'ancienne perdaient tous ses infos;

Avec une petite classe, j'ai pu gérer facilement le multitâche en créant X nombre de champ FI(hors-écran). Lors de l'appel pour "ouvrir" la dites Fenêtre Interne, je ne fais que remplacer la position de mon champs FI. L'affichage reste le même que si tu aurais 1 seul champ Fenêtre Interne, mais pour un progiciel le multi-tâche est vraiment nécessaire.

Rien ne t’empêche d'appeler un Ouvre depuis tes fenêtres internes pour des plus petites fenêtres, popup,etc.

Bonne prog