[Résolu] TableView : que se passe-t-il quand on appuie sur tab / entrée / esc

MickMick Membre
septembre 2010 modifié dans API AppKit #1
Bonjour à  tous,

Je suis encore avec des tableView, et j'aimerais que quelqu'un m'explique l'ordre des appels lors d'une fin d'édition.
En effet, j'ai écrit des méthodes delegate du style - (BOOL)control:(NSControl *)control textShouldEndEditing:(NSText *)textObject pour intercepter des choses, et là  je suis en train d'essayer d'intercepter - (void)controlTextDidEndEditing:(NSNotification *)aNotification. Ces méthodes sont implémentées dans le delegate de la tableView.

Ma colonne a en plus un numberFormatter perso dont les méthodes getObjectValue:forString.. et stringForObjectValue sont overridées.

Enfin, quand les méthodes dataSource sont elles appelées ?

Voilà , je suis perdu sur l'ordre des appels des méthodes déléguées etc... des tableView. C'est bizarre à  comprendre (plein d'objets imbriqués les uns dans les autres)

De même, j'ai du mal à  comprendre ce qu'est le field editor courant et ce qu'on peut en faire (retrouver par exemple la colonne et la ligne de la cellule qui vient d'être éditée : est-ce possible ?)

Réponses

  • devulderdevulder Membre
    septembre 2010 modifié #2
    dans 1283715075:

    Bonjour à  tous,

    Je suis encore avec des tableView, et j'aimerais que quelqu'un m'explique l'ordre des appels lors d'une fin d'édition.
    En effet, j'ai écrit des méthodes delegate du style - (BOOL)control:(NSControl *)control textShouldEndEditing:(NSText *)textObject pour intercepter des choses, et là  je suis en train d'essayer d'intercepter - (void)controlTextDidEndEditing:(NSNotification *)aNotification. Ces méthodes sont implémentées dans le delegate de la tableView.

    De même, j'ai du mal à  comprendre ce qu'est le field editor courant et ce qu'on peut en faire (retrouver par exemple la colonne et la ligne de la cellule qui vient d'être éditée : est-ce possible ?)


    Mets des NSLogs différents pour connaitre l'ordre d'appels
    exemple :

    - (BOOL)control:(NSControl *)control textShouldEndEditing:(NSText *)textObject
    {
      NSLog(@appel 1);
    }

    - (void)controlTextDidEndEditing:(NSNotification *)aNotification
    {
      NSLog(@appel 2);
    }



    Pour connaitre la colonne et la ligne de cellule tu as les méthodes suivantes dans la classe NSTableView :
    - (int) selectedColumn;
    - (int) selectedRow;

    Le field editor sert pour connaitre les evénements du clavier
  • MickMick Membre
    16:54 modifié #3
    Bonjour,

    Effectivement, je vais logger pour voir l'ordre, mais j'aimerais connaà®tre précisément le mécanisme depuis le keyDown jusqu'au changement du modèle de données, et surtout quels sont les objets qui réceptionnent les messages, d'autant plus quand il y a un NSFormatter associé à  la dataCell.

    De même, les méthodes du style didEndEditing peuvent être implémentée dans une subClasse ou alors cela peut-être un délégué (controlDidEndEditing).... Quesaquo ? quel est le plus "propre" ?

    Je pose ces questions parce que je suis toujours à  mon problème de gestion de l'édition dans une tableView => comment, après une édition, donner la main à  une cellule donnée : à  chaque fois la main est redonnée à  la prochaine vue de la keyloop. (en fait, furtivement la cellule que je veux est bien éditée, mais dès la fin de la méthode, une autre doit être appelée (mais laquelle ?) qui parasite le comportement. C'est pour ça que j'aimerais bien comprendre clairement l'ordre des choses et les objets en jeu.
  • mpergandmpergand Membre
    septembre 2010 modifié #4
    Essai avec une table (MyTableView) dont la 1ere col possède un NSNumberFormatter.
    L'ordre d'appel est le suivant:

    selector insertTab:
    control textShouldEndEditing
    controlTextDidEndEditing
    tableView setObjectValue

    Ce qui donne dans le debugger: (voir picture 1)

    Voici le code ajouté à  MyTableView qui permet l'édition de toutes les cellules:
    - (BOOL)textView:(NSTextView *)textView doCommandBySelector:(SEL)commandSelector;<br />{printf(&quot;selector %s&#092;n&quot;,commandSelector);<br />	if (commandSelector == @selector(insertTab:))<br />		{<br />		int editedRow=[self editedRow];<br />		int editedCol=[self editedColumn];<br />	<br />		editedCol++;<br />		<br />		if(editedCol&gt;=[self numberOfColumns])<br />			{<br />			editedCol=0;<br />			editedRow++;<br />			}<br />		<br />		if(editedRow&lt;[self numberOfRows])<br />			{<br />			[[self selectedCell] endEditing:textView];<br />			[self selectRow:editedRow byExtendingSelection:NO];<br />			[self editColumn:editedCol row:editedRow withEvent:nil select:YES];<br />			return YES;	<br />			}<br />		}<br />	else if (commandSelector==@selector(insertBacktab:))<br />		{<br />		int editedRow=[self editedRow];<br />		int editedCol=[self editedColumn];<br />		<br />		editedCol--;<br />		<br />		if(editedCol&lt;0)<br />			{<br />			editedCol=0;<br />			editedRow--;<br />			<br />			if(editedRow&gt;=0)<br />				{<br />				[[self selectedCell] endEditing:textView];<br />				[self selectRow:editedRow byExtendingSelection:NO];<br />				[self editColumn:editedCol row:editedRow withEvent:nil select:YES];<br />				return YES;<br />				}<br />			}<br />		<br />		}<br />	<br />	return [super textView:textView doCommandBySelector:commandSelector];<br />}<br /><br />
    


    Le field editor (il en existe un par fenêtre) est un NSTextView qui est utilisé pour l'édition d'un control, et celui-ci devient délégué du field editor.
    Donc ici, dans ma classe MyTableView, je peux implémenter les méthodes délégués suivantes:

    Text delegate methods
    – textShouldBeginEditing: 
    – textDidBeginEditing: 
    – textDidChange: 
    – textShouldEndEditing: 
    – textDidEndEditing: 

    et aussi toutes les méthodes déléguées de NSTextView, dont doCommandBySelector, ce qui nous arrange bien  :)


  • MickMick Membre
    16:54 modifié #5
    Merci mpergand!
    Je commence à  y voir un peu plus clair. Je vais tester tout ça cet après-midi.

    Désolé pour ces questions "basiques" (encore que...) mais je trouve que la doc n,'est pas super claire en ce qui concerne les événements qui se produisent dans les tableView. (ou alors je ne sais pas chercher, ce qui est aussi fort possible...)

  • MickMick Membre
    septembre 2010 modifié #6
    Re- bonjour ...
    Bah.... ça ne marche pas !!
    J'ai créé une subclass et intercepté le doCommandBySelector, mais rien n'y fait : ma tableView perd le focus (ligne sélectionnée grisée)
    Si ça marche chez toi mpergand, je ne comprend pas. la méthode est bien appelée, entre deux (au endEditing:) ma méthode shouldEndEditing est bien appelée, mais quand tout est fini, la tableView n'est plus la priorité nationale !  :'(

    edit : je viens de m'apercevoir qu'à  l'issu de l'édition, vu que mon controleur est observateur du moc, il remet à  jour un champ d'une zone de texte, et qu'un makeFirstResponder:maTable remettait la table "en bleu...". Voilà  le problème donc : après l'édition, des vues sont mises à  jour et donc ma table perd le focus.

    je vais tenter des bidouilles maintenant que j'ai compris le problème.
  • MickMick Membre
    16:54 modifié #7
    :D Yoouh HOuuuu enfin !!
    Le fin mot de l'histoire :
    dans le delegate, j'implémente le command:textView:doCommandBySelector:. Je ne force pas l'édition ici car ma méthode appelée au changement des données parasite le comportement. Du coup, j'ai créé un BOOL toEdit (variable d'instance du delegate), et deux int rowToEdit et colToEdit que je mets à  jour dans le doCommandBySelector.

    Ensuite, ce n'est qu'à  la fin de la méthode appelée après tout changement du moc que je teste si toEdit est vrai, auquel cas je le rends faux, et je force l'édition de la cellule correcte.

    En tous cas, un grand merci à  mPergand qui m'a sauvé de ce mauvais pas....  o:)
Connectez-vous ou Inscrivez-vous pour répondre.