Discussion :

[ClaudeBg]

Bonjour,

Je suis toujours un peu dubitatif au sujet de la libération des ressources. En fait, je ne vois pas bien de façon intuitive quand je dois ou non m'occuper explicitement de libérer les ressources utilisées, et sur le net je trouve des exemples qui me semblent contradictoires.

Par exemple, si je dérive un RichTextBox, et que dans ce contrôle dérivé j'ai créé un menu interne.

Dois-je ajouter ceci à mon contrôle pour libérer le dit menu?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
        protected override void Dispose(bool disposing)
        {
            if (!disposed)
            {
                if (disposing)                              // pour les objets disposables
                {
                    if (menuInterne != null)                // libérer le menu
                        menuInterne.Dispose();
                }
                disposed = true;                            //un seul passage
                base.Dispose(disposing);                    // appel du dispose de base
            }
        }

Est-ce utile? Nuisible? Indifférent?
Comment savoir ce que je dois libérer explicitement ou non?

Question subsidiaire

Si je crée une librairie de contrôle, et que je remplace la dérivation pour utiliser un contrôle existant (ex:TextBox) au lieu de UserControl, quel constructeur est le plus approprié,

Celui-ci :

Code :

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

1
2
3
4
        public MonControle()
        {
            InitializeComponent();
        }

ou celui-là ?

Code :

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

1
2
       public MonControle() : base()
        {        }

Et pourquoi?

Merci d'avance
Claude

[ketan]

Bonjour,

Je vais peut être dire une bêtise, mais pour ce qui est libération de ressource, si on se réfère à ce que dit microsoft avsec le "Dispose pattern", il faut libérer dans la méthode Dispose() (et bien sur implémenter IDisposable) les ressources, qui sont conservées lors de la durée de vie de ton objet. Donc je suppose que dans ton cas, tu devrais utiliser le code que tu montre.
Par contre, plus généralement, il faut appeler Dispose sur tout les objets dont tu n'as plus utilité dés la fin de leur utilisation (si on ne veut pas avoir des surprises sur le nombre de handle qu'utilise ton application).

Pour la question subsidiaire, je sais InitializeComponent est généré par l'éditeur visuel de VS et que si tu ne l'appel pas dans le constructeur par défaut, je doute que tu puisse utiliser ce dernier sans problèmes.

Code :

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

1
2
3
4
5
 
public MonControle() : base()
        {
            InitializeComponent();
        }

me parait la meilleur solution.

[ClaudeBg]

Merci.

Je précise le contexte.

J'ai une série de contrôles dérivés de contrôles originaux.
Avant, je me contentais de créer une classe "ordinaire" que je dérivais d'un contrôle. Donc, pas de designer, pas de classe.designer.cs etc, juste une unique classe moncontrol.cs : Control
Je prenais en charge moi-même la libération comme indiqué.

J'ai décidé de regrouper mes contrôles dans une solution, et de les transformer tous en bibliothèque de contrôles, afin de pouvoir les utiliser dans mes autres projets directement via la barre d'outils de VS (avant, il fallait recopier la classe dans le projet).

Donc, maintenant que c'est une librairie de projets, la méthode onDispose est DEJA créée automatiquement dans le class.designer.cs, et donc évidemment je ne sais plus la surcharger une seconde fois dans mon contrôle.

Est-ce que ce que la ligne :

Code :

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

components.Dispose();

que le designer ajoute automatiquement effectue la libération des ressources de mon projet, ce qui rendrait inutile la libération explicite de chaque ressource utilisée?

Et si non, où ajouter cette libération?

Pour la question subsidiaire, je sais InitializeComponent est généré par l'éditeur visuel de VS et que si tu ne l'appel pas dans le constructeur par défaut, je doute que tu puisse utiliser ce dernier sans problèmes.

En fait, cette question était aussi la conséquence du transfert de mes contrôles dérivés.

A l'origine, avec ma façon de travailler, je n'avais évidemment pas d'initialisation automatique générée par le designer (pas de classe .designer.cs), et donc pas non plus de "InitialiseComponent".

C'est pourquoi j'étais obligé d'appeler le constructeur de base du contrôle dans le constructeur de mon contrôle dérivé (seule méthode pour l'initialiser correctement).

Avec la bibliothèque de contrôles, c'est différent.
Mais en transférant un contrôle, j'ai oublié de modifier le constructeur, et je me suis aperçu que ça fonctionnait strictement de la même façon, d'où ma question sur les deux syntaxes.

Merci
Claude

[Pol63]

la présence de fichier designer ou non n'est pas lié à une bibliothèque ou autre
quand on hérite d'un control pour le modifier, pas de designer
quand on fait un usercontrol il y a un designer

dans les 2 cas (et dans toutes tes autres classes meme non graphiques) il faut disposer les objets disposables (connexions aux données aussi par exemple)

pour un control, il faut overrides dispose(boolean) pour ajouter ses destructions puis appeler base.dispose(boolean)
pour un usercontrol ou form, on peut modifier le dispose dans le fichier designer (ou s'abonner à l'évent Disposed)

quelques infos ici :
http://www.developpez.net/forums/d83...r/#post4810294

mettre à null ne sert pas forcément, même pour les objets disposables

il me semble aussi que quand un control (donc aussi un usercontrol et un form car ils héritent de control) est disposé, il dispose tous les controles enfants posés sur lui meme

mais si à un moment on ne veut plus afficher un controle et qu'au lieu de mettre visible à false on le retire de son parent, alors il faudra le disposer soi meme


pour ta question subsidiaire
initializecomponent existe pour les usercontrol et form, il remplit l'interface
il est obligatoire, et ce à chaque niveau
si tu fais un UC qui hérite donc de usercontrol, ton uc va appeler le constructeur de base qui va appeler initializecomponent puis ta classe va appeler son initializecomponent
(on peut dériver autant de fois qu'on veut, le comportement est le meme, chaque étage de la hiérrarchie ajoute ses controles)
en vb.net intializecomponent est même implicite ainsi que le constructeur (on peut tout de même écrire le constructeur)

[ClaudeBg]

pour un control, il faut overrides dispose(boolean) pour ajouter ses destructions puis appeler base.dispose(boolean)

Oui, c'est ce que je faisais déjà, lorsque je dérivais directement de control et pas de usercontrol.

pour un usercontrol ou form, on peut modifier le dispose dans le fichier designer (ou s'abonner à l'évent Disposed)

Ok. Modifier dans le designer, je n'aime pas trop, parce que c'est sujet à erreur lorsqu'on recrée un projet du même genre en récupérant le code (oubli des modifs faites dans le designer).
Donc, je retiens l'abonnement à Disposed.

il me semble aussi que quand un control (donc aussi un usercontrol et un form car ils héritent de control) est disposé, il dispose tous les controles enfants posés sur lui meme

Ben en fait, c'est un peu ma question exprimée différemment, c'est ce que je voulais savoir: J'ajoute un contrôle de type menu à mon contrôle dérivé (dans mon cas, un menu popup), est-ce que lorsque mon controle est disposé par le designer ça dispose automatiquement tous les contrôles fils qu'on a créé à l'intérieur, et donc mon menu, SANS devoir le faire explicitement?

Vu que tu dis "il me semble", je reste un peu dans l'expectative.

quelques infos ici :
http://www.developpez.net/forums/d83...r/#post4810294

Merci, je faisais déjà un usage abondant de "using", mais ici c'était un contrôle fils qui reste global et détruit seulement à la destruction de son contrôle parent, et donc je ne peux ni l'inclure dans un using, ni le détruire autrement qu'en agissant au moment du dispose du contrôle parent.

si tu fais un UC qui hérite donc de usercontrol, ton uc va appeler le constructeur de base qui va appeler initializecomponent puis ta classe va appeler son initializecomponent

J'avais bien compris pour le contrôle dérivé de usercontrol. Je me suis probablement mal exprimé:

Si je crée une classe directement dans mon projet, et que je dérive cette classe d'un controle (pas d'un usercontrol), genre

classe MonTextBox : Texbox

Je n'ai pas de designer et pas de initializecomponent, je crée mon constructeur avec appel au constructeur de la base (moncontrol() : base())
et évidemment, ça fonctionne (sauf que je ne sais pas importer mon controle dans la barre d'outils d'un autre projet).

Si par contre j'utilise le "wizard" de création d'un usercontrol, et qu'ensuite je remplace la dérivation de "usercontrol" en "control", pour revenir au cas précédent, j'ai bien un designer.cs et un initializecomponent.

Mais que je remette mon constructeur avec appel au constructeur de "base" comme avant, ou que j'appelle initializecomponent SANS appeler le constructeur de base, ça semble fonctionner de façon identique (je n'ai pas de designer fonctionnel dans les deux cas, vu que j'ai modifié la classe de laquelle je dérive).

Ma question était donc : Quelle est la différence entre les 2 syntaxes et laquelle est la mieux adaptée (pour un dérivé de control, pas de usercontrol où la question ne se pose pas).

Bref, pour prendre un exemple élémentaire, ceci :

Code :

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

1
2
3
4
5
6
   public partial class MonTextBox : TextBox
   {
        public MonTextBox()                 // appel du constructeur de base
            : base()
        {}
    }

ou ceci :

Code :

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

1
2
3
4
5
6
7
   public partial class MonTextBox : TextBox
   {
        public MonTextBox() 
        {
             InitializeComponent();
        }
    }

J'espère que j'ai été plus clair

Merci
Claude

[Pol63]

voici un extrait du code de la méthode dispose de la classe control (trouvée via reflector)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 ControlCollection controls = (ControlCollection) this.Properties.GetObject(PropControlsCollection);
if (controls != null)
{
     for (int i = 0; i < controls.Count; i++)
     {
            Control control = controls[i];
            control.parent = null;
            control.Dispose();
     }
     this.Properties.SetObject(PropControlsCollection, null);
}

donc les controles enfants sont bien disposés

pour qu'un control soit accessible dans la barre d'outils c'est comme pour un usercontrol

faire un usercontrol, puis modifier en control c'est moche
surtout si tu ne supprimes pas le fichier designer, étant donné que c'est un partial class les 2 fichiers sont mélangés à la compilation

la méthode initializecomponent n'existe pas en cas d'héritage de control, donc ta question ne peut pas exister

si les controles n'apparaissent pas automatiquement après compilation, faire clic droit ajouter des éléments ...

[ClaudeBg]

faire un usercontrol, puis modifier en control c'est moche

J'ai suivi un tutorial trouvé sur le net qui expliquait que c'est comme ça qu'il fallait faire. Avant, je dérivais la classe directement. Manifestement, j'aurais mieux fait de ne pas changer,

Donc merci, j'abandonne cette méthode et j'en reviens à ma méthode de base, sauf que je vais créer la dll dans un projet séparé (sinon ça ne fonctionne pas avec l'importation dans la barre d'outils).

donc les controles enfants sont bien disposés

Ok, merci, ça répond à ma question.
Je n'ai pas encore le réflexe "réflector", désolé.

la méthode initializecomponent n'existe pas en cas d'héritage de control, donc ta question ne peut pas exister

Elle est déclarée dans designer.cs du contrôle (classe partielle). Et à l'usage, j'ai testé la méthode avec Initializecomponent dans des contrôles dérivés de control, et ça semble donner les mêmes résultats, puisque j'ai sous les yeux un contrôle dérivé de ComboBox qui appelle dans le constructeur Initializecomponent et qui n'appelle pas le constructeur de base.

Mais puisque je pose la question, ce n'est évidemment pas pour en faire à ma tête , et donc je vais suivre ton conseil et non le tutorial. Pour mes controles non dérivés de usercontrol, je vais créer simplement un projet contenant une classe plutôt qu'un usercontrol, et j'appellerai le constructeur de base.

Je conserverai les usercontrols pour de vrais usercontrols. De toutes façons, ça me semble plus logique, je n'avais fait que suivre un conseil (mal avisé, ça arrive, ).

Puisque j'ai la chance d'avoir un expert qui répond, j'ai une autre question sur un vrai usercontrol, lui, qui contient plusieurs zones texte.

J'ai besoin d'avoir le comportement suivant :

- Lorsque la form parent reçoit l'événement Validating, elle peut vérifier la valeur retournée (logique), qui dépend de l'ensemble des zones textes (genre de concaténation).

- Si la form refuse les valeurs introduites, elle retourne évidemment e.cancel = true sur CancelEventArgs, c'est fait pour.

- Ensuite, elle dispose de la possibilité d'appeler une méthode publique du usercontrol, genre "SetfocusOn", qui précise le numéro de la zone texte interne en erreur, afin de lui donner le focus et sélectionner le texte. Comme ça, l'utilisateur est bloqué sur la donnée refusée (comportement logique).

genre :

Code :

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

1
2
3
4
5
6
7
8
9
  private void MonControl1_Validating(object sender, CancelEventArgs e)
  {
      .... vérifier si tout est OK
      if (erreur)
        {
            e.cancel = true;   // refus de Validation
            (sender as MonControl).SetFocusOn(numéro_zone_refusée);
        }
  }

Or, je rencontre un problème:
En effet, retourner e.cancel = true bloque évidemment la validation du contrôle (c'est fait pour), et ça empêche le focus de partir sur un autre contrôle (c'est aussi fait pour).
Le problème, c'est que ça empêche aussi le focus de se déplacer à l'intérieur du usercontrol. Moralité, la méthode SetFocusOn est absolument sans effet, et il est impossible d'indiquer à l'utilisateur quelle zone est en erreur, le curseur reste sur la dernière zone texte qui a été utilisée.

J'ai essayé des tas de méthodes en overridant onValidating, mais sans succès.

Et évidemment, si je n'appelle pas "base.onValidating" et que je génère "de force" l'événement Validating, j'ai bien le focus qui se positionne, mais alors le focus n'est pas bloqué et je peux accéder à un autre contrôle. Moralité, je me retrouve avec un texte sélectionné alors que je suis en train d'agir sur un autre contrôle.

Comment puis-je faire pour que mon usercontrol puisse donner le focus à un de ses contrôles fils alors que l'utilisateur a refusé le validating?

J'espère que je me fais bien comprendre.

Merci
Claude

[Pol63]

pour revenir une fois de plus sur la méthode initializecomponent, si tu fais un usercontrol, elle est créée automatiquement dans le fichier designer
ensuite tu transformes ton usercontrol en control
vu que la classe est encore coupée en 2 par le partial, la méthode existe toujours
mais elle ne sert à rien (d'ailleurs en théorie elle doit etre vide si tu as rien posé)
tu pourrais aussi mettre une méthode blabla et l'appeler dans le constructeur, ca aurait le meme effet


pour ton validating, je ne vois pas trop, je ne l'ai jamais utilisé (comme quoi "expert" c'est juste un nombre de post sur le forum ^_^)
nous c'est soit on disabled le bouton valider tant que tout est pas bon et on voit à l'écran ce qui est obligatoire
soit au moment du clic sur valider un message "untel est pas rempli" et là on focus

[ketan]

Bonjour,

apparement, c'est une mauvaise idée de vouloir changer le focus dans un évènement validate, cf msdn :

Caution:
Do not attempt to set focus from within the Enter, GotFocus, Leave, LostFocus, Validating, or Validated event handlers. Doing so can cause your application or the operating system to stop responding. For more information, see the WM_KILLFOCUS topic in the "Keyboard Input Reference" section, and the "Message Deadlocks" section of the "About Messages and Message Queues" topic in the MSDN library at http://msdn.microsoft.com/library

Sinon, je me demandais, si tu utilisait BeginInvoke au lieu d'un appel direct à ta méthode afin de mettre l'appel dans la file de fonction du thread afin qu'elle soit exécuté après la succession d'évènement, cela fonctionnerait-il ?

[ClaudeBg]

mais elle ne sert à rien (d'ailleurs en théorie elle doit etre vide si tu as rien posé)
tu pourrais aussi mettre une méthode blabla et l'appeler dans le constructeur, ca aurait le meme effet

Oui, j'ai vu ça.
Mais réciproquement, puisque ça a le même effet (c'est à dire aucun) que d'appeler la constructeur de base dans le constructeur du contrôle, alors ça voudrait dire qu'il ne sert à rien d'appeler le constructeur de base non plus. Et ça me laisse un peu perplexe parce que j'ai toujours cru qu'il était nécessaire d'appeler le constructeur de base lorsqu'on crée une classe dérivée.

comme quoi "expert" c'est juste un nombre de post sur le forum

Je ne parlais pas du qualificatif automatique, je parlais plutôt de la pertinence des réponses

nous c'est soit on disabled le bouton valider tant que tout est pas bon et on voit à l'écran ce qui est obligatoire
soit au moment du clic sur valider un message "untel est pas rempli" et là on focus

Oui, mais ça impose d'empêcher l'utilisateur final d'utiliser validating normalement.

Il se trouve que je suis en train de regrouper une série de contrôles que j'avaient créés pour des applications diverses qui ne reprenaient que ce qui m'était utile, et que je vais les mettre à disposition sur mon site (je partage toujours toutes mes applications). Du coup, je ne peux pas prévoir comment ils vont être utilisés et je dois les rendre plus "universels". C'est quand même dommage de signaler à l'utilisateur qu'il a entré une donnée erronée et de ne pas pouvoir mettre le focus sur cette donnée (en utilisant validating).

apparement, c'est une mauvaise idée de vouloir changer le focus dans un évènement validate, cf msdn :

Ben oui, ça concerne les contrôles eux-mêmes, et c'est logique puisque le but de renvoyer e.cancel = true dans validating, c'est justement d'empêcher l'utilisateur de donner le focus à un autre contrôle tant qu'il n'a pas solutionner l'anomalie dans le contrôle en cours.

Mon problème à moi, c'est que je n'essaye pas de changer le focus (dans le sens donner à un autre contrôle) dans le validating, mais plutôt de permettre à l'utilisateur de changer la bonne donnée à l'intérieur du usercontrole.

J'ai jeté un oeil sur WM_KILLFOCUS mais ça ne me permet pas de résoudre mon problème.

Sinon, je me demandais, si tu utilisait BeginInvoke au lieu d'un appel direct à ta méthode afin de mettre l'appel dans la file de fonction du thread afin qu'elle soit exécuté après la succession d'évènement, cela fonctionnerait-il ?

Intuitivement, j'aurais tendance à penser que contourner le système de cette façon risque de provoquer des bugs aléatoires dépendant du timing des opérations. Et puis, si j'impose des conditions à l'utilisation des événements standard, mon contrôle cesse d'être un contrôle "standard". Mais je vais essayer.

Merci de votre patience,
Claude

[Pol63]

Oui, j'ai vu ça.
Mais réciproquement, puisque ça a le même effet (c'est à dire aucun) que d'appeler la constructeur de base dans le constructeur du contrôle, alors ça voudrait dire qu'il ne sert à rien d'appeler le constructeur de base non plus. Et ça me laisse un peu perplexe parce que j'ai toujours cru qu'il était nécessaire d'appeler le constructeur de base lorsqu'on crée une classe dérivée.

c'est nécessaire oui, mais tellement que ca en devient implicite
ca se voit d'ailleurs en faisant une classe avec une constructeur privé et un constructeur public avec un paramètre
si on appele pas le contructeur de base, le compilateur dit qu'il faut l'appeler dans le constructeur (là il ne peut pas deviner le paramètre requis et celui sans paramètre n'est pas atteignable)

c'est initializecomponent qui est obsolete pour un control (visual studio le demande pour un UC ou un form par contre)

[ClaudeBg]

Salut
-----

c'est nécessaire oui, mais tellement que ca en devient implicite

Ah, ok. Maintenant je comprends mieux pourquoi ça fonctionne sans l'indiquer, j'avais l'impression d'avoir loupé un épisode

Pour le détail du validating, j'ai bien trouvé des solutions, mais tellement "usine à gaz" que ça n'en vaut pas la peine. Je me suis contenté d'ajouter en commentaire dans le summary qu'on ne pouvait pas utiliser le setzonefocus dans le validating si on renvoie cancel. De la façon dont j'ai réorganisé ce contrôle, maintenant si l'utilisateur ne revoie pas cancel mais utilise setzonefocus, le focus se retrouve de toutes façons bloqué sur la zone correcte, ça permet suffisamment de souplesse.

Donc, toutes mes questions ont eu leur réponse, je peux poursuivre le regroupement de tous mes contrôles.

Merci beaucoup à vous.

Claude