›

lier textfield outlet erreur NSUnknownKeyException

yodarkyodark Membre
05:59 modifié dans API AppKit #1
Bonjour à  tous,

J'ai un petit problème il doit surement être très classique.
J'ai créé un interface avec deux textfield. J'ai ensuite créer un classe controller pour controller la vue. J'ai créer deux variables outlet pour récupérer la valeur du textfield.

IBOutlet UITextField *txtnom;

J'ai lié la vue au controller. Tout va bien sauf quand je tente de de lier les textfields aux variables j'ai une erreur

Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<UIApplication 0x44ae90> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key txtnom.


Comment faire?

Réponses

  • Philippe49Philippe49 Membre
    05:59 modifié #2
    setStringValue, méthode de NSControl/UIControl
  • yodarkyodark Membre
    05:59 modifié #3
    ce qui est bizzare c'est que j'ai utilisé nulle part set value... pour l'instant aucune action ne défini la valeur

    par contre j'ai un avertissement que j'avais pas vu et que je comprends pas...

    The delegate outlet of file&#39;s owner is connected to myapp delgate but delegate is no longer defined on UserOptionsController
  • Philippe49Philippe49 Membre
    05:59 modifié #4
    dans 1220172412:

    The delegate outlet of file's owner is connected to myapp delgate but delegate is no longer defined on UserOptionsController

    Tu as du donner comme classe UserOptionsController au File's owner, et ta classe UserOptionsController n'a pas de delegate. Ainsi la connection ne peut pas se faire.

    dans 1220172412:

    ce qui est bizzare c'est que j'ai utilisé nulle part set value... pour l'instant aucune action ne défini la valeur

    D'ailleurs c'est UIApplication qui râle dans le message
    [<UIApplication 0x44ae90> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key txtnom.
    UIApplication n'est pas compatible avec le KVC pour la clé "txtnom".
    C'est-à -dire que tu n'as pas de variable ou d'accesseur pour txtnom pour la classe UIApplication.

    Revois les connections dans le nib. J'ai l'impression que tu n'as pas fait ce que tu croyais faire.

  • yodarkyodark Membre
    05:59 modifié #5
    effectivement ça doit être ça... Mais le problème c'est que je ne vois pas trop ce que je dois lier avec quoi...
    Si je regarde l'exemple de la vue FirstView généré automatiquement elle n'est pas lié à  un delgate. C'est en fait tab bar qui est lié a la vue qui est lié au delgate.

    Il me semblait avoir compris que pour faire marcher une vue il faut la lier au controller ? Il faut faire encore quelque chose d'autre?
  • Philippe49Philippe49 Membre
    05:59 modifié #6
    dans 1220253279:

    Il me semblait avoir compris que pour faire marcher une vue il faut la lier au controller ? Il faut faire encore quelque chose d'autre?

    C'est le contraire, c'est l'outlet "view" du Controller que l'on met sur la vue.
  • GreensourceGreensource Membre
    05:59 modifié #7
    Je Up ce sujet car je me trouve dans une situation similaire.
    Je voudrais ajouter une barre d'outils à  mon jeu.
    J'ai donc fait:
    • Un UIViewController pour gérer la UIToolBar
    • Un .xib avec la UIToolBar

    Voici les bindings que j'ai fait:
    picture1ezb.png

    Donc ensuite j'initialise ou il faut la toolBar:
    <br />statusBarController = [[UIViewController alloc] initWithNibName:@&quot;Status&quot; bundle:nil];<br />[self.view addSubview:statusBarController.view];

    Mais quand ça passe la dedans j'ai l'erreur suivante:

    2009-04-05 02:46:11.166 GreenWar[20549:20b] *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<UIViewController 0x538050> setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key info.'

    Je ne comprends pas parce qu'il me semble déjà  avoir eu cette erreur mais c'est quand on a oublier de binder quelques choses normalement non?
  • Philippe49Philippe49 Membre
    05:59 modifié #8
    Cela peut être aussi lorsqu'on met l'IBOutlet en property sans faire @synthesize.

    (rq le terme de bindings est délicat à  employer car cela correspond à  une technologie bien spécifique sur Cocoa qui n'est pas disponible sur iPhone)
  • GreensourceGreensource Membre
    05:59 modifié #9
    dans 1238906863:

    Cela peut être aussi lorsqu'on met l'IBOutlet en property sans faire @synthesize.

    Non je n'ai fait aucun @property. Je me disais (en dormant  :)) que cela venait peut-être du fait que mon UIToolBar est une UIView que je ne l'ai pas attacher à  une UIWindow? Mais en même temps je me dit qu'on doit bien pouvoir faire une UIView avec IB sans l'attaché à  quoi que ce soit dans IB et le faire ensuite par code?

    [quote author=Philippe49 link=topic=2875.msg34925#msg34925
    (rq le terme de bindings est délicat à  employer car cela correspond à  une technologie bien spécifique sur Cocoa qui n'est pas disponible sur iPhone)
    [/quote]
    Ah bon? Mais les bindings c'est pas juste le fait de faire les Target-Actions via IB?
  • Philippe49Philippe49 Membre
    avril 2009 modifié #10
    ce serait pas :
    statusBarController = [[StatusBarController alloc] initWithNibName:@Status bundle:nil];

    dans 1238920359:

    Ah bon? Mais les bindings c'est pas juste le fait de faire les Target-Actions via IB?

    Non cela ce sont les connections.
    Le binding (ONE to ONE) c'est un mécanisme d'observation entre une variable x d'un objet A et une variable y d'un objet B. Dès que x change, y change automatiquement et vice versa.

  • GreensourceGreensource Membre
    05:59 modifié #11
    dans 1238922352:

    ce serait pas :
    statusBarController = [[StatusBarController alloc] initWithNibName:@Status bundle:nil];

    Exact! Merci. J'espère m'habituer vite au message d'erreur parce que c'est un peu poster des messages pour rien ça ::)

    dans 1238922352:

    dans 1238920359:

    Ah bon? Mais les bindings c'est pas juste le fait de faire les Target-Actions via IB?

    Non cela ce sont les connections.
    Le binding (ONE to ONE) c'est un mécanisme d'observation entre une variable x d'un objet A et une variable y d'un objet B. Dès que x change, y change automatiquement et vice versa.

    Ah ok, bas je savais pas du alors ^^. Pourtant c'est pas fautes d'avoir entendu des gens parler de bindings sur le forum  ;)
  • AliGatorAliGator Membre, Modérateur
    avril 2009 modifié #12
    dans 1238920359:

    Non je n'ai fait aucun @property. Je me disais (en dormant  :)) que cela venait peut-être du fait que mon UIToolBar est une UIView que je ne l'ai pas attacher à  une UIWindow? Mais en même temps je me dit qu'on doit bien pouvoir faire une UIView avec IB sans l'attaché à  quoi que ce soit dans IB et le faire ensuite par code?
    Alors oui on peut, mais sous iPhone les root-objects d'un XIB ne sont pas "retained" par défaut. Donc si dans ton XIB (dont le File's Owner est un UIViewController par exemple) tu as une UIView qui est connectée à  l'IBOutlet "view" du File's Owner, alors là  c'est ok car si tu regardes dans la doc de UIViewController, l'IBOutlet "view" est défini en "[tt]@property(nonatomic, retain) UIView* view[/tt]", autrement dit la UIView que tu vas associer à  cet IBOutlet recevra un "retain".
    Mais si tu as une UIView dans ton XIB qui est toute seule, reliée à  rien du tout, ou que tu as un IBOutlet dessus, mais qu'il n'est pas déclaré en property "retain", alors ta UIView ne sera pas "retain" et donc ne sera pas gardée en mémoire. Il faut absolument que tu aies un IBOutlet dessus et qu'il soit déclaré en property "retain".

    La doc Apple à  ce sujet
    Outlets
    When a nib file is loaded and outlets established, the nib-loading mechanism always uses accessor methods if they are present (on both Mac OS X desktop and iPhone). Therefore, whichever platform you develop for, you should typically declare outlets using the Objective-C declared properties feature as illustrated in this example:
    @property (nonatomic, retain) IBOutlet UserInterfaceElementClass *anOutlet;

    You should then either synthesize the corresponding accessor methods, or implement them according to the declaration, and then release the corresponding variable in dealloc.

    Following this pattern gives you a consistent way of dealing with outlets regardless of platform. It ensures that object referenced by outlets remain valid for as long as is necessary, and that the general memory management semantics are made clear.

    [...]
    Top-Level Objects in NIB files on iPhone
    Objects in the nib file are created with a retain count of 1 and then autoreleased. As it rebuilds the object hierarchy, UIKit reestablishes connections between the objects using setValue:forKey:, which uses the available setter method or retains the object by default if no setter method is available. This means that (assuming you follow the pattern shown in “Outlets”) any object for which you have an outlet remains valid. If there are any top-level objects you do not store in outlets, however, you must retain either the array returned by the loadNibNamed:owner:options: method or the objects inside the array to prevent those objects from being released prematurely.
Connectez-vous ou Inscrivez-vous pour répondre.