NSTableView et édition de cellule

RocouRocou Membre
22:49 modifié dans API AppKit #1
Mes NSTAbleView ont un comportement étrange en édition.
Certaines lignes sont inéditables. J'ai beau double-cliquer comme un fou, rien à  faire. Pas moyen de savoir pourquoi telle ligne refuse l'édition.
Pour celles qui l'acceptent, si je ne saisi rien j'obtiens le message d'erreur suivant:
*** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value (key: poids)

("poids, c'est l'identifiant de la colonne)
Or je ne fais aucun contrôle de contenu, je n'ai pas activé les "binding", je n'utilise pas core data.
Une fois que j'ai eu cette erreur, plus rien n'est éditable.  B)

Réponses

  • ClicCoolClicCool Membre
    22:49 modifié #2
    dans 1256023000:
    .../...si je ne saisi rien j'obtiens le message d'erreur suivant:
    *** -[NSCFDictionary setObject:forKey:]: attempt to insert nil value (key: poids)

    ("poids, c'est l'identifiant de la colonne)
    Or je ne fais aucun contrôle de contenu, je n'ai pas activé les "binding", je n'utilise pas core data.
    Une fois que j'ai eu cette erreur, plus rien n'est éditable.  B)


    C'est écrit noir sur blanc.
    Faut juste que ton code de datasource test si il y a une valeur saisie à  enregister.
    - S'il y en a une tu l'insères dans ton NSDictionary.
    - S'il y en a pas tu choisis entre ignorer l'évènement ou, plus judicieusemet, vérifier s'il y avait une valeur et alors la supprimer.













  • RocouRocou Membre
    22:49 modifié #3
    dans 1256024245:

    - S'il y en a pas tu choisis entre ignorer l'évènement

    Merci, c'est ce qu'il me semble de plus judicieux dans mon cas mais comment "ignorer l'évènement"?
  • ClicCoolClicCool Membre
    22:49 modifié #4
    dans 1256025350:
    .../...
    Merci, c'est ce qu'il me semble de plus judicieux dans mon cas mais comment "ignorer l'évènement"?


    Ben, dans ton code datasource, tu ne fais rien, et surtout pas tenter d'inclure nil dans ton NSDictionary.

    Une collection d'objets (NSDictionary, NSArray etc...) ne peut raisonablement pas pointer sur nil et ne peut de toutes façons accepter que des objets (ce que nil n'est pas)
    Si tu veux explicitement avoir nil comme valeur (par exemple pour que la key d'un dictionnaire existe même si aucun objet n'y est associé, ou comme placeholder pour un index au sein d'un array ...) tu dois alors utiliser le singleton NSNul.
  • AliGatorAliGator Membre, Modérateur
    22:49 modifié #5
    NB : Il me semble que la méthode [tt]setValue:forKey:[/tt] de NSDictionary accepte la valeur nil comme valeur, et dans ce cas supprime la clé associée du dictionary (contrairement à  [tt]setObject:forKey:[/tt] qui lui refuse une valeur nil et plante le cas échéant)
  • ClicCoolClicCool Membre
    octobre 2009 modifié #6
    dans 1256032991:

    NB : Il me semble que la méthode [tt]setValue:forKey:[/tt] de NSDictionary accepte la valeur nil comme valeur, et dans ce cas supprime la clé associée du dictionary (contrairement à  [tt]setObject:forKey:[/tt] qui lui refuse une valeur nil et plante le cas échéant)


    En effet, j'avais oublié cette subtilité !
    Merci.

    Ce qui ne change pas le problème, à  savoir qu'on ne peut pas mettre un nil dans une collection.
    Si on veut garder la clef associée il faut utiliser NSNul...
  • RocouRocou Membre
    22:49 modifié #7
    dans 1256033906:

    dans 1256032991:

    NB : Il me semble que la méthode [tt]setValue:forKey:[/tt] de NSDictionary accepte la valeur nil comme valeur, et dans ce cas supprime la clé associée du dictionary (contrairement à  [tt]setObject:forKey:[/tt] qui lui refuse une valeur nil et plante le cas échéant)


    En effet, j'avais oublié cette subtilité !
    Merci.

    Ce qui ne change pas le problème, à  savoir qu'on ne peut pas mettre un nil dans une collection.
    Si on veut garder la clef associée il faut utiliser NSNul...

    Bon, merci, je vais étudier la doc à  ce niveau.
    Bon, j'ai "résolu" mon problème sans vraiment comprendre pourquoi. J'avais glissé un NSFormater dans les cellules d'une colonne. C'est lui qui apparemment n'apprécie pas un null.
  • ClicCoolClicCool Membre
    22:49 modifié #8
    dans 1256049795:
    .../...J'avais glissé un NSFormater dans les cellules d'une colonne. C'est lui qui apparemment n'apprécie pas un null.


    Un NSFormater qui plante quand il reçoit un nil ?
    ça me semble pas classique comme comportement ça.

    C'est un NSFormater "maison" que t'as codé ?


    Sinon, t'as bien implémenté un datasource pour fournir les données à  la tableView et pour traiter les modifications non ?
  • RocouRocou Membre
    22:49 modifié #9
    dans 1256054389:

    dans 1256049795:
    .../...J'avais glissé un NSFormater dans les cellules d'une colonne. C'est lui qui apparemment n'apprécie pas un null.


    Un NSFormater qui plante quand il reçoit un nil ?
    ça me semble pas classique comme comportement ça.

    C'est un NSFormater "maison" que t'as codé ?

    Non, créé à  partir d'IB. Je n'ai rien fait de spécial. Je l'ai viré et l'édition fonctionne de nouveau parfaitement.
    dans 1256054389:

    Sinon, t'as bien implémenté un datasource pour fournir les données à  la tableView et pour traiter les modifications non ?

    J'ai effectivement un datasource qui fournit les données à  la tableview mais je ne traite pas les modifs.
    Le datasource est alimenté à  partir du base de données. C'est cette dernière qui est modifiée en fonction de ce qui est édité dans la tableview. Puis je réalimente le datasource avec la base de données mise à  jour.
    C'est indispensable en environnement multi-utilisateurs.
  • wiskywisky Membre
    22:49 modifié #10
    Comment est-tu au courant des modifications apporté si tu ne les traitent pas ?

    Tu n'as pas ajouter cette méthode dans l'objet qui traite le data sources ?
    - (void)tableView:(NSTableView *)aTableView setObjectValue:(id)anObject forTableColumn:(NSTableColumn *)aTableColumn row:(NSInteger)rowIndex
  • RocouRocou Membre
    22:49 modifié #11
    dans 1256297184:

    Comment est-tu au courant des modifications apporté si tu ne les traitent pas ?

    Tu n'as pas ajouter cette méthode dans l'objet qui traite le data sources ?
    - (void)tableView:(NSTableView *)aTableView setObjectValue:(id)anObject forTableColumn:(NSTableColumn *)aTableColumn row:(NSInteger)rowIndex

    :)

    Je viens de me rendre compte a quoi servait cette méthode.

    En d'autres termes à  chaque fois que l'on édite une cellule, le NSMutableArray associé à  la tableview est modifié automatiquement?
    Je n'ai donc pas besoin de récupérer le contenu de chaque cellule modifiée afin de le transmettre à  mon NSMutableArray associé puisque c'est déjà  fait?
  • wiskywisky Membre
    22:49 modifié #12
    dans 1256297651:

    dans 1256297184:

    Comment est-tu au courant des modifications apporté si tu ne les traitent pas ?

    Tu n'as pas ajouter cette méthode dans l'objet qui traite le data sources ?
    - (void)tableView:(NSTableView *)aTableView setObjectValue:(id)anObject forTableColumn:(NSTableColumn *)aTableColumn row:(NSInteger)rowIndex

    :)

    Je viens de me rendre compte a quoi servait cette méthode.

    En d'autres termes à  chaque fois que l'on édite une cellule, le NSMutableArray associé à  la tableview est modifié automatiquement?
    Je n'ai donc pas besoin de récupérer le contenu de chaque cellule modifiée afin de le transmettre à  mon NSMutableArray associé puisque c'est déjà  fait?

    Presque. Cette méthode est appelé à  chaque fin d'édition (la nouvelle valeur est dans la variable "anObject") pour que tu puisse vérifier les données et les modifier dans le tableau source. ensuite un reloadData permettra de réafficher correctement la liste.

    Si il y bien un différence entre REALbasic et Cocoa c'est que REALbasic stocke les données d'une liste dans la liste et Cocoa utilise la liste uniquement pour l'affichage. L'accès aux cellules pour y trouver les données est à  proscrire en Cocoa. ;)
Connectez-vous ou Inscrivez-vous pour répondre.