[RESOLU] Tool tip : réglages et bindings
Philippe49
Membre
Pour le splendide tool tip ci-dessous, j'ai fait un binding sur le bouton, et j'ai mis le code ci-dessous dans le controleur de l'application
Deux questions :
1) Le binding fonctionne sans qu'aucune variable "tip" ne soit déclarée dans le contrôleur. Cela marche uniquement par les "accessor methods", ce qui me semble compatible avec le KVC. Ai-je raison de penser ainsi , et ce style de binding est-il robuste ?
2) Le fichier d'entête des classes NSToolTip... ne sont pas dans le framework, (ni dans la distribution des Developer Tools) alors la compilation me provoque un Warning. On pourrait rajouter ce(s) fichier(s) d'en-tête au projet, mais est-ce nécessaire ?
#import "ApplicationControler.h"
@class NSToolTipManager;
@implementation ApplicationControler
-(void) awakeFromNib
{
[[NSToolTipManager sharedToolTipManager] setInitialToolTipDelay:0.1];
}
-(NSString*) tip
{
return @What a beautiful tip;
}
-(void) setTip:(NSString*)aTip
{
}
@end
Cherchant des informations sur les tool tip, j'ai retrouvé ce post de Bru
[Fichier joint supprimé par l'administrateur]
Deux questions :
1) Le binding fonctionne sans qu'aucune variable "tip" ne soit déclarée dans le contrôleur. Cela marche uniquement par les "accessor methods", ce qui me semble compatible avec le KVC. Ai-je raison de penser ainsi , et ce style de binding est-il robuste ?
2) Le fichier d'entête des classes NSToolTip... ne sont pas dans le framework, (ni dans la distribution des Developer Tools) alors la compilation me provoque un Warning. On pourrait rajouter ce(s) fichier(s) d'en-tête au projet, mais est-ce nécessaire ?
#import "ApplicationControler.h"
@class NSToolTipManager;
@implementation ApplicationControler
-(void) awakeFromNib
{
[[NSToolTipManager sharedToolTipManager] setInitialToolTipDelay:0.1];
}
-(NSString*) tip
{
return @What a beautiful tip;
}
-(void) setTip:(NSString*)aTip
{
}
@end
Cherchant des informations sur les tool tip, j'ai retrouvé ce post de Bru
dans 1125827156:
Je m'en vais vous conter l'histoire fabuleuse des tooltips sour OS X :
Il était une fois une classe (partiellement undocumented) nommée NSToolTipManager.
Cette classe est une singleton, donc il n'existe qu'une instance par application. Le rôle de cette classe est de contrôler l'affichage des tooltips (on peut y régler les délais des timers d'apparition/disparition, récupérer l'id de la fenêtre affichant le texte du tooltip, ajouter/retirer les views affichant des tooltips, etc.).
Cette classe est secondée par NSToolTipPanel, qui est la fenêtre qui affiche le texte du tooltip. Il n'existe qu'une fenêtre pour l'application (elle est créée au premier tooltip à afficher, puis ensuite, tout au long de la vie de l'application, elle est masquée -orderOut- ou non -orderFront-).
Chaque tooltip déclaré dans chaque view (via la méthode setToolTip: ) créé une instance d'une classe NSToolTip dont le rôle est de stocker la NSString à afficher, ainsi qu'un pointeur sur une structure de donnée.
Enfin, une dernière classe NSToolTipStringDrawingLayoutManager (une singleton elle aussi) permet de stocker les attributs d'affichage de la NSString du tooltip.
On peut toujours surcharger (par une catégorie) telle ou telle méthode de chacune de ces classes. Le problème est que cela affecte l'application entière, ce qui peut être génant.
Le plus simple (et croyez moi, c'est simple) est de gérer sa propre fenêtre tooltip pour le cas particulier dont à besoin notre ami.
[Fichier joint supprimé par l'administrateur]
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
La doc sur les bindings dit les choses suivantes :
[size=12pt]Ensuring KVC Compliance[/size]
In order for a class to be considered KVC compliant for a specific property, it must implement the methods required for valueForKey: and setValue:forKey: to work for that property.
Il me semble clair que le stockage de l'info dans une variable n'est pas nécessaire. Ce qui est en cause c'est ce qu'Apple appelle une "property", pas une variable.
For properties that are an attribute or a to-one relationship, this requires that:
• Your class implements a method named -<key>, -is<Key>, [glow=yellow,2,300]or[/glow] has an instance variable <key> or _<key>.
• If the property is mutable, then it should also implement -set<Key>:.
• Your implementation of the -set<Key>: method should not perform validation.
• Your class should implement -validate<Key>
For to-many relationships, KVC compliance requires that:
.......
Bouclé pour la question du KVC Compliance
[glow=yellow,2,300]Conséquence :[/glow]
La technologie des bindings ouvre la porte à faire exécuter du code qui n'a peut-être rien à voir avec la mise à jour d'une variable ...
Obj-C étant totalement dynamique, dans ce cas précis, le warning peut être ignoré.
Mais, si comme moi, tu fais partie des développeurs qui:
- n'aiment pas les warnings,
- aiment jouer avec les undocumented,
Alors, soit tu importes un "NSToolTip.h" (récupéré par class-dump par exemple), mais je trouve cela pas très clean.
Mais tu peux aussi ruser avec le fait que Obj-C soit complètement dynamique, et donc jouer a[size=10pt][/size]vec son runtime.
Remplace :
par :
Résultat : même fonctionnalité, mais plus de warning à la compil.
.
joli ...
D'autant plus que le risque avec les undocumented, c'est de voir ces classes/méthodes être modifiées par Apple dans les futures version de OSX.
Or, dans ce cas, tu peux tout tester :
- NSClassFromString renvoie Nil si la classe n'existe pas/plus.
- via la méthode instancesRespondToSelector:, tu peux tester l'existence de la méthode avant de l'exécuter.
Donc, tu rends ton code stable, version après version de l'OS (même si certaines fonctionnalités ne seront plus disponibles, et laisseront place à celle par défaut).
.
Ici par exemple, on laisserait tomber cette fonctionnalité, qui est comme on dit à la sécurité sociale, un médicament de confort ...
Tout cela me fait penser qu'une lecture approfondie de Objective_C Run Time devient urgente.