Discussion :

[qltmi]

Bonjour,

je voudrais si c'est possible de surcharger des opérateurs classiques (+,-,==,...) pour des classes qui existent déjà?

Dans la plupart des tutoriaux, on ne parle des surcharges que pour des classes que l'on crée, or moi je voudrais par exemple créer la fonction "+" pour le type "object". Si c'est possible, où mettre la nouvelle définition.

J'ai mis le code

Code :

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

public static object operator+ (object O1,object O2)

dans la classe où j'ai besoin, mais j'ai l'erreur suivante:

Un des paramètres d'un operateur binaire doit être le type conteneur.

Merci pour votre aide.

[StormimOn]

Ce n'est pas possible et cela n'aurait pas de sens de toute façon.

[Kistrof]

Bonjour,

J'ai la même erreur en écrivant ça :

Code :

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

1
2
3
4
public static DelegateMouse operator +(DelegateMouse a, DelegateMouse b)
{
...
}

Vous aurez compris qu'il s'agit de délégués et que j'aimerais surcharger l'opérateur +
Pourquoi ? Parce que je ne veux pas ajouter une fonction dans le délégué si elle y est déjà !

Si on a ça :

Code :

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

1
2
eventMouseDown += mouseDown;
eventMouseDown += mouseDown;

Je ne veux pas que le second fonctionne, il doit rester sans effet. J'ai la fonction qui cherche mais c'est une simple fonction, il faudrait que je remplace tous mes += sur mes délégués
Alors qu'avec une surcharge, je serais tranquille.

La doc MSDN indique ceci pour cette erreur de compilation :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class iii
{
    public static implicit operator int(iii x)
    {
        return 0;
    }
    public static implicit operator iii(int x)
    {
        return null;
    }
    public static int operator +(int aa, int bb)   // CS0563 
    // Use the following line instead:
    // public static int operator +(int aa, iii bb)    
    {
        return 0;
    }
    public static void Main()
    {
    }
}

Mais ça reste peu compréhensible pour moi ... qu'est ce que c'est que ce type "iii" ? Je vois bien que c'est la classe dans laquelle on se trouve mais bon ... je ne comprends pas, alors que le C++ accepte parfaitement ce genre d'opérateur

Quelqu'un a une idée pour faire fonctionner ma surcharge ?
Serait-ce impossible du fait que ce sont des délégués ?

[theMonz31]

salut

si tu veux faire cela pour un delegate (enfin, un evenement) regardes du coté de add/remove.. tu verras, pas besoin de surcharge pour arriver à n'avoir qu'un seul delegate d'enregistrer à ton evenement

[Kistrof]

Mes délégués ne m'offrent pas ces méthodes, ils semblent en lecture seule
Je peux récupérer la liste des fonctions enregistrée avec getInvocationList() mais aucune méthode d'ajout ou de suppression là dedans !
Cette liste d'invocation peut me fournir un énumérateur mais toujours aucune opération de modification disponible

[MetalGeek]

Salut,
tu peux déclarer des corps "add" et "remove" pour tes évènements ; de toute façon "surcharger" les opérateurs des types clr que tu n'as pas créés, si cela était possible, serait à bannir.

[Kistrof]

A ce jour, j'ai ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public delegate void DelegateMouse(MouseEventArgs e);
 
public DelegateMouse addDelegate(DelegateMouse a, DelegateMouse b)
{
    bool present = false;
    IEnumerator it = a.GetInvocationList().GetEnumerator();
    while (it.MoveNext())
    {
        Object o = it.Current;
        if (b.Equals(o))
        {
            present = true;
            break;
        }
    }
    if (!present) a += b;
    return a;
}

Et au lieu de faire

Code :

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

a += b;

je fais

Code :

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

a = addDelegate(a, b);

mais je trouve pas ça terrible
Si je pouvais faire

Code :

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

a.add(b);

ça serait mieux (plus court et plus logique)

Aurais-je le droit de créer une classe " DelegateMouse " tout en ayant la déclaration du delegué ? (premier ligne ci-dessus)
Mais il me semble qu'on ne peut pas dériver un délégué ... enfin bon, tout ça pour ne pas avoir de redondance dans mes délégués ^^

[ketan]

Bonjour,

pour pouvoir utiliser a.add(b), essaye d'utiliser les extensions.
Une déclaration comme celle la devrait marcher:

Code :

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

1
2
3
4
5
6
7
8
 
public static class DelegateMouseExtension
{
  public static DelegateMouse Add(this DelegateMouse a, DelegateMouse b)
  {
    // ta fonction ici
  }
}

ensuite tu met just el using vers ta classe si besoin et ça devrais rouler.

[Guulh]

Hello,

ce que je me demande, quand même, c'est dans quel cas on peut se retrouver à abonner deux fois la même méthode à un event. Les abonnements d'event, ça se fait pas souvent : en général peu après la création de l'objet en question. Je vois pas trop comment on peut se retrouver à un moment donné avec un objet entre les pattes sans savoir s'y on s'est déjà abonné à un de ses events ou pas.

Donc je vois pas trop quel genre de cas un projet est confronté au problème des abonnements multiples suffisamment de fois pour envisager une solution systématique.

[Kistrof]

Je vais tester ta solution ketan

Guulh, je modifie mes event très souvent vu que je dois gérer 3 événements de la souris (down, move et up) et qu'absolument tout dans le projet doit se faire à la souris !

[Guulh]

Guulh, je modifie mes event très souvent vu que je dois gérer 3 événements de la souris (down, move et up) et qu'absolument tout dans le projet doit se faire à la souris !

Euh, je vois pas le rapport. En quoi le fait de concevoir une UI qui fait fortement usage de la souris te force a abonner / désabonner des méthodes aussi souvent ?
Le scénario le plus simple, c'est la création de l'objet, et l'abonnement a ses méthodes dans la foulée. Ça suffit probablement 95% des besoins, et je me demandais juste ce que ton projet avait de particulier pour justifier de s'écarter de ces cas simples.

[olibara]

Bonjour

Moi aussi je plussoie Guuhl, je ne comprends pas cette nécessité d'abonner / desabonner de maniere systématique
Soit c'est un contexte tres particulier que j'aimerais comprendre pour ma culture générale
Soit c'est une erreur dans la conception du traiterment

[Kistrof]

Peut-être une erreur dans la conception ... je débute en C# mais pas en développement en général donc je ne suis pas très bien familiarisé avec les spécificités du C#

Je dois réaliser un éditeur de circuits électriques simples (fil, résistance, pile, lampe et interrupteur) et on me demande de pouvoir tout faire avec la souris, à savoir :
- placer un fil en "tracé élastique" avec le clic gauche (clic enfoncé, déplace et relache le clic)
- placer un composant de la meme manière avec le clic droit (aboutit à un menu contextuel qui demande quel composant mettre)
- pouvoir lancer un mode de simulation en déplaçant la souris vers la droite tout en maintenant les 2 boutons de la souris enfonçés
- pouvoir revenir en mode d'édition en faisant pareil vers la gauche

Donc quand je passe en mode simulation, je vire toutes les méthodes des événements pour mettre celles qui gèrent les événements de ce mode. Et inversement quand on repasse en mode édition.

De plus, j'ai différencié en plusieurs méthodes les différentes actions possibles (mouseUp après un déplacement avec le clic gauche, pareil avec le clic droit, ...)

[olibara]

Salut

Ca deviens plus clair
Mais a priori je ne vois pas vraiment la nécessité de désabonner / réabonner tout tes event surtout tenant compte de ce que tu dis ici

pouvoir revenir en mode d'édition en faisant pareil vers la gauche

Il faut donc que tu continue a gerer les event

Personnelement je gererais le contexte a l'aide de proprieté qui te permetront de savoir ce qu'il faut faire dans chacun des event

[Guulh]

Personnelement je gererais le contexte a l'aide de proprieté qui te permetront de savoir ce qu'il faut faire dans chacun des event

Je suis d'accord Il n'y a pas une façon unique et sacrée de coder, mais en l'occurrence il ma parait plus simple d'avoir un booléen / une enum indiquant le mode d'édition actuel, et des méthodes qui se comportent différemment selon le mode courant.

[olibara]

pouvoir lancer un mode de simulation en déplaçant la souris vers la droite tout en maintenant les 2 boutons de la souris enfonçés

Ca me semble aussi un peu bizare
Pourquoi pas le menu contextuel (puisque tu en a un) ou simplement un checkbox a coté de ton plan de dessin ?
C'est certainement plus simple a réaliser et aussi plus facile a comprendre pour l'utilisateur (qu'il ne faut quand meme pas oublier )

[Kistrof]

Parce que c'est pas moi qui ait fait le cahier des charges et que peux pas le changer !

[olibara]

Parce que c'est pas moi qui ait fait le cahier des charges et que peux pas le changer !

Et bien entendu je suppose que c'est celui qui a fait le cahier des charges qui va utiliser et vendre cette application

[Kistrof]

Mais le pire ... c'est que c'est un put*** de projet de fac

[olibara]

Ah bon !

Et moi qui m'inquietait pour les utilisteurs

Mais dans ce cas il n'y a plus qu'a suivre sagement le cahier des charges et te preparer une liste d'enum ou quelques booleens pour determoner le contexte et savoir quoi faire dans chaque event !

Au final tu verra c'est pas tres compliqué.
Une chose importante pour tes tracés est aussi de garder parmis tes propriérés le point de la position de reference que tu determine sur l'event voulu dans le CC