Discussion :

[Aizen64]

Salut!

J'ai quelques petites questions assez basiques sur les formulaires que je n'ai pas réussi à faire.

- Lors de la fermeture de mon application (clic X) je veux afficher un formulaire Oui Non et s'il clique sur Oui je ferme l'appli, sinon je le remet sur le formulaire principal (Focus). J'ai vu quelques exemples mais aucun ne fonctionne correctement quand j'ai essayé de le reproduire.

- Dans le menu principal, j'ai une liste déroulante qui correpond aux différents "modules" de l'application, lors du clic sur le bouton OK je fais un switch pour instancier le formulaire correspondant. Le problème de cette méthode c'est que si l'utilisateur clique 10 fois sur OK, ça va créer 10 fois la même fenêtre, je veux vérifier si une instance de mon formulaire existe déjà, si c'est le cas je fais un focus dessus sinon je la crée.

Une dernière chose, je l'ai déjà dit mais ça me saoule que mon application prenne trop de mémoire quand j'ouvre toutes les fenêtres (dans les 20Mo je crois). Je sais que le GC ne prend pas vraiment toute cette mémoire mais quand même, je sais aussi que le mode "release" diminue fortement la mémoire allouée au processus comparé au mode "debug".

Y a t-il un moyen de forcer le Garbage Collector à avoir une limite d'allocation pour tout le processus ? 10Mo sont plus que suffisants pour mon application.
Si j'ai bien compris cet article :

http://gfx.developpez.com/tutoriel/java/gc/

le Garbage Collector de Java est paramétrable, est il possible de paramétrer celui de .NET ?

[Guulh]

Salut!

J'ai quelques petites questions assez basiques sur les formulaires que je n'ai pas réussi à faire.

Essayons de faire des réponses pas trop basiques

- Lors de la fermeture de mon application (clic X) je veux afficher un formulaire Oui Non et s'il clique sur Oui je ferme l'appli, sinon je le remet sur le formulaire principal (Focus). J'ai vu quelques exemples mais aucun ne fonctionne correctement quand j'ai essayé de le reproduire.

Suffit de se plugger sur l'événement Closing de ta Form et d'ouvrir une MessageBox en spécifiant que tu veux les boutons "YesNo" (cf la doc de Messagebox.Show). L'événement Closing a une propriété "Cancel" qui, si elle est mise à true, interrompt la fermeture de la form.

- Dans le menu principal, j'ai une liste déroulante qui correpond aux différents "modules" de l'application, lors du clic sur le bouton OK je fais un switch pour instancier le formulaire correspondant. Le problème de cette méthode c'est que si l'utilisateur clique 10 fois sur OK, ça va créer 10 fois la même fenêtre, je veux vérifier si une instance de mon formulaire existe déjà, si c'est le cas je fais un focus dessus sinon je la crée.

Plutôt que faire TaForm f = new TaForm(); f.Show(), tu peux implémenter un pattern singleton.

Une dernière chose, je l'ai déjà dit mais ça me saoule que mon application prenne trop de mémoire quand j'ouvre toutes les fenêtres (dans les 20Mo je crois). Je sais que le GC ne prend pas vraiment toute cette mémoire mais quand même, je sais aussi que le mode "release" diminue fortement la mémoire allouée au processus comparé au mode "debug".

Y a t-il un moyen de forcer le Garbage Collector à avoir une limite d'allocation pour tout le processus ?

Quel est l'intérêt ? Si Windows a vraiment besoin de mémoire, il demandera au framework d'en libérer, ce qu'il fera s'il le peut. Si t'as 2 Go de RAM dont 1,5 de libre, qu'est ce ça change que ton process, prudent, se soit alloué 20 Mo ?
Les frameworks comme DotNet sont taillés pour qu'on ait le moins possible à se soucier de la mémoire ; laissons les faire

[dev01]

- Lors de la fermeture de mon application (clic X) je veux afficher un formulaire Oui Non et s'il clique sur Oui je ferme l'appli, sinon je le remet sur le formulaire principal (Focus). J'ai vu quelques exemples mais aucun ne fonctionne correctement quand j'ai essayé de le reproduire.

Voir l'évènement OnClosing du formulaire

- Dans le menu principal, j'ai une liste déroulante qui correpond aux différents "modules" de l'application, lors du clic sur le bouton OK je fais un switch pour instancier le formulaire correspondant. Le problème de cette méthode c'est que si l'utilisateur clique 10 fois sur OK, ça va créer 10 fois la même fenêtre, je veux vérifier si une instance de mon formulaire existe déjà, si c'est le cas je fais un focus dessus sinon je la crée.

il te faut alors garder une trace des formulaires ouvert. S'ils ont chacun une clef distinct (peut importe ce que tu prend comme clef) tu peux utiliser un Dictionary. Ensuite pour donner le focus tu utilises la méthode Show()

Une dernière chose, je l'ai déjà dit mais ça me saoule que mon application prenne trop de mémoire quand j'ouvre toutes les fenêtres (dans les 20Mo je crois). Je sais que le GC ne prend pas vraiment toute cette mémoire mais quand même, je sais aussi que le mode "release" diminue fortement la mémoire allouée au processus comparé au mode "debug".

Y a t-il un moyen de forcer le Garbage Collector à avoir une limite d'allocation pour tout le processus ? 10Mo sont plus que suffisants pour mon application.
Si j'ai bien compris cet article :

http://gfx.developpez.com/tutoriel/java/gc/

le Garbage Collector de Java est paramétrable, est il possible de paramétrer celui de .NET ?

A ma connaissance non. Et d'ailleur il n'y aucun intéret. Le GC de Java n'as pas la notion de communication avec le système alors que le GC .NET oui.

[EDIT]Grillé .... [/EDIT]

[Guulh]

[EDIT]Grillé .... [/EDIT]

grillé certes, mais pour le point numéro 2, ta solution à base de dicos est très bien (m'en suis déjà servi moi-même en fait ), ma réponse est à côté parce que j'avais mal lu

[Aizen64]

Un pattern singleton ? Jamais entendu parler, ça a l'air un peu chiant a faire ça, je préfère la solution du dictionnaire mais je vois pas bien comment m'en servir, je mets comme clé le nom de la classe (du formulaire) et comme valeur le nom de l'instance ?

Gullh
Quel est l'intérêt ? Si Windows a vraiment besoin de mémoire, il demandera au framework d'en libérer, ce qu'il fera s'il le peut. Si t'as 2 Go de RAM dont 1,5 de libre, qu'est ce ça change que ton process, prudent, se soit alloué 20 Mo ?
Les frameworks comme DotNet sont taillés pour qu'on ait le moins possible à se soucier de la mémoire ; laissons les faire

C'est bien ce genre de truc qui m'énerve, sous prétexte que le PC moyen actuel possède au minimum 1Go de mémoire, on s'en tappe si une application basique prend 20Mo ? C'est ce que je reproche à pas mal de développeurs actuellement, faire des softs qui prennent une quantité phénoménale de mémoire, et ce, même quand ils sont développés en C/C++ donc sans GC.

Pour moi la question ne se pose pas, je ne sais pas vraiment me servir de C/C++ pour gérer dynamiquement la mémoire et je me suis arrêté au listes chainées mais pour des ingénieurs expérimentés je trouve ça con de faire toujours plus gourmand.

[dev01]

Un pattern singleton ? Jamais entendu parler, ça a l'air un peu chiant a faire ça, je préfère la solution du dictionnaire mais je vois pas bien comment m'en servir, je mets comme clé le nom de la classe (du formulaire) et comme valeur le nom de l'instance ?

La clef tu met ce que tu veux du moment que c'est unique

C'est bien ce genre de truc qui m'énerve, sous prétexte que le PC moyen actuel possède au minimum 1Go de mémoire, on s'en tappe si une application basique prend 20Mo ?

Et c'est la que tu ne comprend pas ce que l'on te dit. Le runtime .NET n'utilises pas vraiment les 20 Mo qui sont affichés. Il se les garde au cas ou il en aurait besoin (et évites ainsi en cas de besoin des opérations d'augmentation de mémoire qui sont couteuse en temps et en processeur). Mais si le système dit au runtime : "Hey salut, j'ai une app qui a besoin de 100 Mo de ram mais j'en ai plus que 90 en réserve tu peux faire quelque chose ?", le runtime vas lui répondre : "Ouais pas de pb, j'ai pris 20Mo mais l'app n'utilise pas plus de 2Mo en réalité, je t'en donne donc 10 et ça me laisse une marge"

On pourrait chipoter longtemps sur le fait que le runtime ne devrait s'allouer que le 10 Mo si n'utilise réellement que 2, et ainsi de suite, mais on s'en fiche

[SirJulio]

C'est bien ce genre de truc qui m'énerve, sous prétexte que le PC moyen actuel possède au minimum 1Go de mémoire, on s'en tappe si une application basique prend 20Mo ? C'est ce que je reproche à pas mal de développeurs actuellement, faire des softs qui prennent une quantité phénoménale de mémoire, et ce, même quand ils sont développés en C/C++ donc sans GC.

Pour completer ce que dis Dev01, il faut bien comprendre aussi que .Net est un environnement managé, de fait si tu t'en tiens à l'indication globale du task manager concernant l'occupation memoire, tu n'auras pas une image representative de l'appli. Dans les 20 Mo de conso, tu as tout le runtime .Net qui est compté (CLR, meta etc ). Donc oui, les applis .Net sont connus pour leur besoin gargantuesque en memoire, surtout pour de petites applis (en comparaison de leurs homologues C(++)), mais c'est tout à fait normal, et ce n'est pas une negligence, c'est juste la difference entre un environnement managé comme .Net et une appli native pure.

Bref, si tu veux avoir une attitude extreme concernant la gestion memoire ("chaque ko compte !" =p) alors clairement .Net n'est pas le bon choix de devel : L'hypothese de base quand tu developpes en .Net est que tu fais confiance au runtime pour gerer au mieux ta memoire (et il le fait plutot bien jusque la), .Net ne permet d'avoir un controle fin des alloc/desalloc (à quelques exceptions pret comme les memory gates, mais bon).

Pour conclure, pour avoir des chiffres plus pertinents concernants l'utilisation memoire de ton appli, essaie des applis comme Process Explorer (sysinternals) ou CLR profiler qui ont des compteurs specifiques pour les applis .Net.

[SaumonAgile]

Un pattern singleton ? Jamais entendu parler, ça a l'air un peu chiant a faire ça

Les patterns sont des méthodes standards de résolution de problèmes courants. Ne pas les connaitre pour un développeur est déjà une grosse lacune...
Mais si en plus, tu trouves que c'est chiant (sic), alors même que le singleton est le plus simple de tous, là je crois que c'est la fin...

Si tu préfères encore utiliser un dictionary, l'idée est d'utiliser l'instance du formulaire comme valeur associée à la clé, ainsi il ne te reste plus qu'à appeler la méthode Show sur le formulaire pour le remettre au premier plan (s'il existe déjà).
N'oublie pas de remettre la valeur associée à null quand le formulaire en question est fermé.

[Guulh]

Un pattern singleton ? Jamais entendu parler, ça a l'air un peu chiant a faire ça, je préfère la solution du dictionnaire mais je vois pas bien comment m'en servir, je mets comme clé le nom de la classe (du formulaire) et comme valeur le nom de l'instance ?

Le singleton aurait été utile si la fenêtre en question n'a vocation qu'à exister une seule fois dans toute ton appli. Mais ça n'a pas l'air d'être le cas, tu peux oublier.

Après, pour le dico : t'as une commande qui va t'ouvrir une fenêtre, bien. Tu dis que tu voudrais dans certains cas non pas créer une fenêtre, mais donner le focus a une existante. Mais dans quel cas ? Tu dois trouver ce qui caractérise chaque instance et en faire la clé de ton dico.

Quant à la gestion du GC, je n'ai rien à ajouter à ce que disent dev01 et SirJulio, à part qu'il ne faut pas confondre Laisser Aller (pas bien, consommateur) et Laisser Faire (bien, maintenable, anti-réinventage-de-roue). des fuites mémoires en C++, c'est du laisser-aller. Foutre la paix au GC, c'est du laisser-faire

[dev01]

il ne faut pas confondre Laisser Aller (pas bien, consommateur) et Laisser Faire (bien, maintenable, anti-réinventage-de-roue). des fuites mémoires en C++, c'est du laisser-aller. Foutre la paix au GC, c'est du laisser-faire

Énorme ! je pense que je vais la ressortir à mes étudiants celle la (si tu m'y autorise évidement )