.net dispose des ressources d'image dans les formulaires

Question

Je ne sais pas trop s'il faut ou non se débarrasser des ressources images et icônes lorsqu'elles sont référencées par mes formulaires. Plus précisément, s'il y a une différence de comportement si je référence une image/icône à partir des ressources de conception ou si je charge l'image au moment de l'exécution. (.Net4, VS2015, C#)

Évidemment, si vous définissez la propriété Icône d'un formulaire au moment de la conception sur une ressource, vous n'avez pas à expliciter la propriété Icône. Dispose() de celui-ci lors de la fermeture du formulaire. Mais qu'en est-il si vous le définissez comme ceci :

this.Icon = Resources.my_default_icon;

Devez-vous vous débarrasser de this.Icon à la fermeture de ce formulaire ?

De la même manière, que se passe-t-il si j'ai une mini-classe juste pour "l'image de marque" et que je dispose d'un fichier statique Icon qui est chargé (éventuellement à partir d'un fichier, éventuellement en faisant simplement référence à la ressource intégrée) au moment de l'exécution ? Devrais-je utiliser un constructeur de copie dans cet objet statique ? Icon s getter ? Ou est-il possible d'en faire un objet statique public ? Icon et permettre à tous mes formulaires d'avoir la ligne unique suivante dans leurs pages web. _Shown() événement ?

this.Icon = MyBrandingClass.formIcon;

Je ne suis pas sûr que ce soit très différent. J'ai vu quelques références à la définition de l'image d'une picturebox au moment de l'exécution et à la destruction de l'image, mais comment détruire une image de ressource intégrée ? Si je passe une référence à mon image de marque, puis-je/doit-on omettre la disposition ? Ou devrais-je utiliser un constructeur de copie dans le getter pour renvoyer un nouvel objet Image et le détruire une fois le formulaire terminé ?

Answer 1

Le programme doit se débarrasser des images lorsqu'il n'en a plus besoin, mais cela ne signifie pas nécessairement que c'est votre code qui doit s'en charger.

Dans votre premier exemple, lorsque vous le faites :

this.Icon = Resources.my_default_icon;

cela renvoie en fait à une instance statique d'une ResourceManager classe. Jetez un coup d'œil au code dans Resources.Designer.cs, vous le trouverez peut-être instructif.

On peut considérer que cette classe est "propriétaire" de l'image. Elle créera initialement la référence à l'image et s'en débarrassera donc lorsque l'instance du ResourceManager sera détruite (c'est-à-dire lorsque le programme se terminera).

Votre deuxième exemple est en fait très similaire :

this.Icon = MyBrandingClass.formIcon;

Vous implémentez vous-même quelque chose de similaire au ResourceManager.

Dans ce cas, considérez que MyBrandingClass est le propriétaire de l'image et qu'il est donc responsable de son nettoyage. Comment ? Faites de MyBrandingClass un singleton avec une instance statique. Ainsi, lorsque le programme se termine, le destructeur de MyBrandingClass est activé et vous pouvez alors disposer de toutes les ressources qu'il a instanciées au cours de sa vie.

Vous pourriez également envisager que votre MyBrandingClass hérite de ResourceManager. Ou peut-être qu'à la place, vous pourriez simplement avoir plusieurs instances de ResourceManagers (en supposant que vous prévoyiez d'avoir différentes versions de MyBrandingClass). Comme je l'ai dit, l'examen de la documentation et du code dans Resources.Designer.cs pourrait vous permettre de voir les éléments internes de ce qui se passe réellement et vous donner des idées sur la manière de remplir un ResourceManager au moment de l'exécution (peut-être à partir de un répertoire d'images ?)

Une autre option, si toutes les ressources sont connues au moment de la conception, serait d'avoir plusieurs objets Ressources dans votre projet. Cliquez avec le bouton droit de la souris sur le projet, ajoutez un nouvel élément et choisissez "Fichier de ressources". Vous pouvez alors remplir chacun d'eux avec le contenu approprié pour chaque marque et simplement initialiser une référence au bon objet au démarrage de l'application. Cela va cependant gonfler votre exécutable car vous incluez toutes les ressources pour chaque marque même si vous n'en utilisez qu'une seule. Cela nécessite également une reconstruction de l'application si vous voulez changer la marque ou ajouter une nouvelle marque, donc peut-être que remplir un gestionnaire de ressources dynamiquement à partir d'un répertoire au moment de l'exécution serait mieux (bien que cela rende l'emballage de l'installateur un peu plus impliqué).

Answer 2

Si vous avez une classe ( Resources o MyBrandingClass ), cette classe doit se charger de disposer de ses ressources lorsque celles-ci sortent de leur champ d'application.

Pour Resources ce n'est pas vraiment votre travail, et ce n'est probablement pas un gros problème puisque la portée de cette classe devrait être la durée d'exécution du processus.

Pour MyBrandingClass il semble que vous l'utilisiez de manière similaire - une classe statique qui vit pour la durée de vie de votre processus. Si ce n'est pas le cas, vous devez disposer de ces ressources de manière appropriée.

En général, IDisposable doit être utilisé pour les ressources gérées que le ramasseur d'ordures ne sera pas en mesure de saisir par lui-même, et qui doivent être libérées avant la fin de l'exécution du processus pour libérer les ressources. Votre Icon est probablement une telle ressource - mais, là encore, elle est probablement nécessaire pour la durée d'exécution de votre programme. Si vous vous en débarrassez en cours d'exécution et que vous souhaitez la réutiliser, vous obtiendrez presque certainement une exception.

Answer 3

Vous ne disposez pas des ressources intégrées, à moins d'être sûr que vous n'en aurez plus besoin. Si le formulaire de marque n'apparaît plus jamais, alors il peut être correct de le disposer. Le constructeur de copie est exagéré et ne résout rien.

Les icônes intégrées ne posent pas beaucoup de problèmes. J'en ai des centaines et cela fonctionne bien. Veillez à ne pas conserver de gros bmps.