Discussion :

[fpinter]

Bonjour à tous!!

Je voudrais savoir comment programmer la chose suivante:

J'ai un projet winform C++ qui affiche une page (form1) au démarrage et qui possède 2 boutons.
Le bouton 1 ouvre une fenêtre comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
form2 ^mafenêtre_2 = gcnew form2();
mafenetre_2->Show();

Le bouton 2 ouvre une fenêtre comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
form3 ^mafenêtre_3 = gcnew form3();
mafenetre_3->Show();

la form3 possède elle aussi un bouton avec lequel je voudrais fermer "mafenetre_2".....et là je sèche

Alors s'il y a un as du visual C++ pour me faire avancer ce serait bien.

Merci par avance

[bacelar]

Ca sent déjà l'architecture bancale.
On n'est pas près d'atteindre un modèle MVC avec ça.
Pour limiter la case, le plus simple est de sauvegarder dans form1 mafenêtre_2 et mafenêtre_3 comme champs (initialisé à NULL au démarrage de form1).
Lors de la création de l'une, on demande à l'autre de se fermer.

[fpinter]

Bonjour bacelar

Merci beaucoup que tu t'es déjà intéressé à ma question.
Sur le plan architecture, je suis d'accord, c'est absolument "NAZE".
Dans le fond, ma question est de savoir si l'essai que je voudrais faire est possible, a savoir si on peut fermer une form depuis un endroit du programme autre que celui qui a demandé l'affichage de la form. Le but est d'avoir à un moment donné 3 forms en simultané à l'écran et de pouvoir en fermer une depuis une autre form. (C'est expérimental)

Tu sais je ne fais que redémarrer dans ce puissant langage qu'est le visual C++, (comme j'ai passé mon brevet de pilote j'ai du laisser tomber un peu)
je ne suis qu'un tout petit et ridicule programmeur qui ne connait que le VB6 (on ne rigole pas) et en VB6 on peut atteindre toutes les forms et tout ce qu'il y a dessus depuis n'importe où.

Alors même si ce que je veux faire n'est pas bien, est-ce malgré tout possible? et comment ?

Merci

[bacelar]

Ne prend pas mal mes remarques sur la qualité de l'architecture. Elles sont là pour bien indiquer que cela ne correspondra jamais à du code qui sera facilement maintenable dans le temps.

Si c'est pour faire une simple démo, pourquoi pas, mais souvent les démos se transforme POC (proof of concept) puis en code pour un projet temporaire puis un code qui date de 30 ans.

Il est tout à fait possible de faire en C++, comme dans beaucoup d'autres langages généralistes, les mêmes horreurs qu'en VB6.

Trèves d'amabilités.

a savoir si on peut fermer une form depuis un endroit du programme autre que celui qui a demandé l'affichage de la form

C'est bien le genre de question montrant un problème de conception, mais oui, il est tout à fait possible de faire cela.

Le but est d'avoir à un moment donné 3 forms en simultané à l'écran et de pouvoir en fermer une depuis une autre form.

C'est le même topo, mais oui, c'est possible.

puissant langage qu'est le visual C++,

La puissance, sans maitrise, n'est rien.

en VB6 on peut atteindre toutes les forms et tout ce qu'il y a dessus depuis n'importe où.

Bon on va arrêter de faire l'ayatollah du code mais si vous vous faite pincez avec ce code, je n'irais tout en bloc. (quoi, tous les pilotes ne font pas partie du MI6, on m'aurait menti)

Regardes du côté des variables globales et de ses petites cousines que sont des membres statics publiques d'une classe.

En gros, si vous n'avez que trois forms, vous les déclarez comme des références d'objet globales (hors de toutes classes) que vous initialisez en temps voulu.

En mode "static" vous les déclarez comme des membres "public static" d'une classe et vous les initialisez de la même manière.

Si le nombre de form est arbitraire et que vous voulez vraiment avoir le même horrible comportement que VB6, vous créez un membre public static de type Dictionnary ayant pour type de clé une chaine de caractère et comme type de valeur une form. Vous n'aurez qu'à ajouter vos forms après leur création dans ce Dictionnary. Vous pouvez aussi opter pour une classe dérivée de Form qui fera cet affreux enregistrement de manière automatique dans son constructeur.

Au faite, c'est la méthode "Close" de la classe Form qui permet de fermer, même de l'extérieur, LA form (vu que ce n'est pas une méthode static mais une méthode d'instance).

Sincèrement, je pense que vous devez rapidement vous débarrassez de vos mauvais reflexes de VBiste pour pouvoir concevoir rapidement du code maintenable par plus d'une personne pendant plus de 15 jours.

[fpinter]

Pas de problèmes, j'ai intégré ta première réponse de façon tout à fait positive et constructive. Je comprends bien que l'on ne peut pas replacer un apprenti programmeur sur les bons rails en faisant des rondes jambes et des courbettes, et je suis déjà bien content qu'une personne comme toi, qui est pragmatique et qui à de l'expérience m'ai répondu.
Sinon, pour ta 2ème réponse, t'as encore bien répondu à mon faux problème (car je que j'avais derrière la tête n'est pas très pro) t'as sorti le mot magique "variables globale", mais j'ai lu pas mal d'articles qui ne recommandent pas de tels usages.
Et pour tout te dire, comme je me remets fraichement à la programmation, j'avoue que je me considère un peu comme un chien errant. Je veux laisser tomber le VBNET ça c'est sûr, et me consacrer à un autre langage. Par contre, aujourd'hui, il y en a pas mal. (C++, C#, java.....etc...etc) et plus je lis de forums, plus j'ai du mal à prendre une décision à savoir lequel prendre.
J'hésite encore entre visual C++ managé et C#. je vais peut être démarrer sur les 2 en même temps, et voir lequel je vais laisser tomber en cour de route.
Sinon tous les pilotes ne font pas parti du MI6, il y en a qui font aussi parti du FSB, CIA, DGSE, MOSSAD pour les principaux. En ce qui me concerne aucun de ces services n'a encore fait appel à moi

[bacelar]

Attention, j'ai tiré à boulet rouge sur VB6, pas sur VB.NET. Et j'ai tiré car vous utilisez une horreur de VB(non .NET) mais la qualité du code est fonction du programmeur, pas du langage de programmation. Rien ne vous obligeait à utiliser cette fonction qui semble être pratique (et qui l'est pour une approche RAD, Rapid Application Developement) de recherche automatique des formulaires "Nommées" inhérente aux langages dynamiques donc non ".NETiffiable" en VB.NET, C# ou C++/CLI.

Tout programmer doit être polyglotte.

Il doit choisir le langage en fonction du domaine d'exécution de la solution logicielle.
Même les langages dits généralistes ont des lacunes et des points forts (largement fonction des bibliothèques associées).

On peut tout faire avec n'importe quel langage, même des routines BIOS en ROM avec VB ou des macro Excel avec un macro assembleur.
Mais c'est loin d'être optimum en temps de développement.

Dans votre cas, si vous venez du domaine RAD (Rapid Application Developement) tel que le suggère VB6, je pense que vous devez commencer par un langage .NET dans le même domaine.

VB.NET et C# sont les langages .NET les plus répandus dans ce domaine (soit avec les librairies WinForm, soit WPF).
C++/CLI doit être réservé aux personnes venant de la programmation système ou sur des projets utilisant lourdement des fonctionnalités managées ET non managées.

Entre VB.NET et C#, je vous dirais de regarder du côté de C#, car il y a plus d'utilisateurs donc plus de support, et aussi, pour ne pas être tenté par de mauvaises habitudes VB6. Pour les bonnes (habitudes), VB.NET et C# sont très similaires.

Il n'y a pas de variables globales en C# mais il reste les membres et les constructeurs "static" pour implémenter votre usine à gaz de récupération de formulaire par nom.