Soucis avec le notification center
muqaddar
Administrateur
Salut cocoaMembers,
J'ai un soucis avec une notification :
Pas d'erreur à la compil.
Seulement le champ "textLengthField" ne se met pas à jour quand je tape mon texte
Quand j'affiche le panel info, ça marche, ça me donne bien le nombre de caractères.
Le textDidChange a pas l'air de faire effet.
une idée ?
J'ai un soucis avec une notification :
- (void)awakeFromNib<br />{<br /> NSNotificationCenter* center = [NSNotificationCenter defaultCenter];<br /> [center addObserver:self selector:@selector(textDidChange) name:NSTextDidChangeNotification object:textView];<br />}<br /><br />- (void)textDidChange:(NSNotification *)notification<br />{<br /> [textLengthField setIntValue:[[textView textStorage] length]];<br />}<br /><br />- (IBAction)showInfoPanel:(id)sender<br />{<br /> if (!infoPanelController) {<br /> [NSBundle loadNibNamed:@"InfoPanel" owner:self];<br /> infoPanelController = [[NSWindowController alloc] initWithWindow:infoPanel];<br /> }<br /> [textLengthField setIntValue:[[textView textStorage] length]];<br /> [infoPanelController showWindow:self];<br />}
Pas d'erreur à la compil.
Seulement le champ "textLengthField" ne se met pas à jour quand je tape mon texte
Quand j'affiche le panel info, ça marche, ça me donne bien le nombre de caractères.
Le textDidChange a pas l'air de faire effet.
une idée ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
ça colle?
J'ai oublié les 2 points à la fin du sélecteur.
D'ailleurs qui peut me dire pourquoi je ne prends pas de warning avec ce genre d'erreurs ?
C'est pénible que dans ce cas on ait pas de warning !
Mais ça doit s'expliquer quelque part ...
C'est fou le nombre d'erreur de frappe qui ne donnent pas lieu à un warning et qui nous font perdre des cheveux avant l'âge !.
PS: QUI a dit que j'ai l'âge ? >:(
Cela ne vient il pas du fait que la méthode possède un argument ?
Par exemple, une fonction ayant 2 arguments, son nom (d'après l'objC) est maFonctionArg1:Arg2:
Ce qui fait que - (void) awakeFromNib a pour nom awakeFromNib car aucun argument.
PS: je vérifierai pendant le week end dans mon livre d'objective C
Tu cherches la bagarres ?
J'attend à la récré
Oui, une méthode sans argument n'a pas les 2 points.
Mais en théorie une "méthode de notification" est censée avoir une NSNotification comme argument genre:
fautReagirA:(NSNotification*)laNotification
Donc toujours avec un argument et donc toujours avec une écriture "à 2 points" façon:
@selector(fautReagirA
un sélecteur sans point est acceptable d'une façon générale mais pas en théorie dans la méthode addObserver: selector: name: object:
Mais il semble que cette subtilité de contexte ne soit pas gérable à la compil
Et c'est le même souci lors des fonctions "action". Il y a toujours un argument (appelé sender la plupart des fois) mais il faut tout de même mettre les ":".
On va dire que c'est le respect strict de la norme, il faut juste un peu de rigueur
(aahhh le nombre de fois où j'ai oulbié les ":" pour mes actions >:( )
Le runtime d'Objective-C est profondemment dynamique, c'est à dire que la situation au moment du linkage n'est absolument pas la même que celle lors de l'exécution.
Un exemple : il est tout à fait possible de charger et d'utiliser une classe extérieure au programme pendant l'exécution de ce dernier (voir -[NSBundle bundleWithPath:] et -[NSBundle principalClass]). Toujours dynamiquement, il est possible ensuite de faire d'un objet de cette classe le target d'une action, et de choisir une des méthodes d'instance de la classe pour en faire l'action elle même.
Or à la compil, cette classe n'existant pas, il ne faut surtout pas que le linker vérifie ce genre de dépendance...
Il y a quelque temps, j'avais donné sur MacBidouille un bout de code pour charger dynamiquement dans un programme un module de screen saver (le lien est ici :http://forum.macbidouille.com/index.php?showtopic=46621&view=findpost&p=438561). Or à la compil, il est clair que le module en question n'existe pas.
.
Et cela nous rend tellement et souvent service qu'on ne veut pas lui en vouloir de devoir ajouter les ":" ;D
Merci à vous.
Tu as raison Bru, mais là peut-être aurait-il pu y avoir une vérification, non pas sur la cible et sa méthode, mais sur le fait que le centre de Notification (bien connu à la compil) attend à la base une méthode avec un argument de type notification.
Il pourrait en être de même sur les méthodes actions qui devraient prendre un argument (le sender)
Un petit warning sur une construction qui s'écarte des spécifications attendues aurait été bienvenu dans bien des cas s'il avait été possible :-\
Je pense que cela ne doit pas être évident. En effet, la fonction prend comme argument un "selector" et non le nom de la fonction. C'est un peu comme le (void*). Si tu déclares une fonction avec comme argument un void*, tous les appels de cette fonction passera à la compilation quelque soit le type de paramètre passé.
exemple (en C):
Par contre à l'exécution, rien n'est garanti ;D
Que nenni !
Le NSNotificationCenter est une implémentation puremment Apple qui n'a rien avoir avec le compilateur ou le linker qui eux sont multi plateforme. C'est Apple qui a décidé de transmettre un argument à la méthode appelée par le center, alors que la société Pear ou la société Cherry, elles, ont fait une implémenation du NotificationCenter sans utiliser l'argument...
.
Je savais bien que j'arriverai à te faire cracher ton 200 ème post ;D
:trinque: