[Résolu] extern pour une méthode Objective C
Philippe49
Membre
Voilà , j'ai fait une Custom View élémentaire avec une méthode
-(void) mouseDown:(NSEvent*)event{
[[self superview] mouseDown:event inView:self];
}
Problème logique j'ai un Warning comme quoi cette méthode n'est pas reconnue et gnagangna et gnagnagna.
Solutions envisagées :
1) je mets (UneAutreCustomView*) devant [self superview] , et un #import "UneAutreCustomView.h" d'une classe qui contient la méthode.
2) Je mets (id) comme cast, mais il faut quand même faire un #import
3) Je crée un protocole et je mets (id <monProtocole>)
Mais Bonsoir, et c'est là ma question :
N'y a t-il pas moyen d'utiliser extern ou quelque chose d'identique ?
Autrement dit, est-il possible de faire quelque chose qui dans l'idée serait :
extern -(void) mouseDown:(NSEvent *) event inView:(NSView) aView
-(void) mouseDown:(NSEvent*)event{
[[self superview] mouseDown:event inView:self];
}
Problème logique j'ai un Warning comme quoi cette méthode n'est pas reconnue et gnagangna et gnagnagna.
Solutions envisagées :
1) je mets (UneAutreCustomView*) devant [self superview] , et un #import "UneAutreCustomView.h" d'une classe qui contient la méthode.
2) Je mets (id) comme cast, mais il faut quand même faire un #import
3) Je crée un protocole et je mets (id <monProtocole>)
Mais Bonsoir, et c'est là ma question :
N'y a t-il pas moyen d'utiliser extern ou quelque chose d'identique ?
Autrement dit, est-il possible de faire quelque chose qui dans l'idée serait :
extern -(void) mouseDown:(NSEvent *) event inView:(NSView) aView
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
if( .. respondsToSelector
et objc_msgSend( ... )
J'utilise plusieurs "superview" différentes, et de plus, pour pouvoir réutiliser dans d'autres programmes ...
une idée ?
Ceci provient du fait que la gestion des événements utilisateur (clavier, souris, tablette) est à la charge du window-server. Or ce dernier ne manipule que des structures fenêtre (au sens le plus simple du terme).
C'est ensuite les couches plus hautes (window manager pour Carbon, Appkit pour Cocoa) qui rajoute des éléments plus complexes dans ces simples fenêtres.
NSEvent (et son grand frère CGEvent) sont des produits du window-server, donc, il n'y a pas de connaissance des éléments complexes (tel que NSView entre autre) ajoutés.
C'est pourquoi, un NSEvent te donne la fenêtre à laquelle il est attaché, mais par la sous-classe NSResponder qui va recevoir l'événement (ceci est déterminé par le dispatcher de NSWindow - voir méthode sendEvent: -)
D'accord pour le Window Server, mais la vue est déterminée lors de la gestion de l'événement lorsqu'elle est définie pour l'envoi initial du message.
Peut-être peut-on chercher du côté du run time.
Non rien à voir.
L'événement suit (à peu de chose près) ce chemin :
- window-server créée une structure CGEvent, puis appelle le handler d'événement de la fenêtre ciblée.
- sous Appkit, ce handler fait partie du runtime d'une appli cocoa.
- ce runtime transforme le CGEvent en NSEvent.
- le NSEvent est transmis à NSApp via sa méthode sendEvent:.
- sendEvent: de NSApp recherche la fenêtre cocoa cible.
- une fois trouvée, la méthode sendEvent: de la NSWindow cible est appelée.
- sendEvent: de NSWindow parcourt les NSResponder afin de déterminer lequel est la cible.
- le NSResponder trouvé, la méthode ad'hoc (mouseDown, keyUp, etc) est appelée.
Donc, si ce schéma n'est pas cassé, logiquement, firstResponder de NSWindow doit te donner le dernier NSResponder qui a répondu à l'événement.
Donc NSApp est au courant, nous sommes d'accord, c'est comme cela que je voyais les choses.
C'est ce que j'avais essayé, mais firstResponder n'est pas changé avec mes mouse events.
En résumé
Donc pour que l'on puisse savoir dans quelle vue s'est produit le clic de souris,
il faut que la ou les vues candidates implémentent les méthodes
-(BOOL) resignFirstResponder
-(BOOL) becomeFirstResponder
-(BOOL) acceptsFirstResponder
On peut alors récupérer cette info par [window firstResponder]Â