Lier objetctController.content à arrayController.selection
laudema
Membre
Bonjour,
Dans une application multi-documents j'ai dans la fenêtre de chaque document un tableau qui représente des objets de base de mon application. Or je veux pouvoir ouvrir d'autres fenêtres qui me permettront de mieux voir l'une ou l'autre propriété de l'objet sélectionné dans le tableau. Je sais faire les liaisons directement dans mes autres fenêtres en definissant le arrayController du tableau comme objet du windowController de la propriété et en liant de la même manière que si j'étais dans la fenêtre du document.
Sauf que si j'ouvre un autre document avec un autre tableau ça ne se met plus à jour. Bien sûr je peux savoir quand la fenetre de document devient active et en profiter pour aller mettre à jour la fenetre de propriété mais j'envisage de faire plusieurs fenêtre (maintenant que je sais faire:-).
Alors j'ai eu l'idée de mettre un objectController qui me servirait de relais dans mon objet appController qui pour l'instant ne me sert qu'à gérer l'ouverture et la fermeture de l'appli et lancer mes fenêtres. Lui je peux facilement le trouver via [NSApp delegate] et/ou je peux mettre son objectController en paramètre d'un init personnalisé de la fenêtre.
J'y suis presque: après le chargement du nib du document je mets à jour mon objectController appControl monObject] setContent:[objetsController selection et ensuite je lie le content de cet objet à la propriété selection du ArrayController [[appControl monObject] bind:@contentObject toObject:objetsController withKeyPath:@selection options:nil];
Sauf qu'en fait en faisant ça je le lie à la selection du moment mais je n'ai pas de mise à jour quand la sélection change.
Si je mets un objectController dans le nib du document et lie, dans IB, son content à selection de objetsController ça fonctionne mais par programmation comme je le fais ça ne fonctionne pas. Il doit donc y avoir quelque chose dans l'interface qui fait du travail dans mon dos (le côté obscur des bindings ?).
Pas trouvé encore dans Google comment contrer ça.
Peut être parce que je ne devrais pas faire comme ça ?
Dans une application multi-documents j'ai dans la fenêtre de chaque document un tableau qui représente des objets de base de mon application. Or je veux pouvoir ouvrir d'autres fenêtres qui me permettront de mieux voir l'une ou l'autre propriété de l'objet sélectionné dans le tableau. Je sais faire les liaisons directement dans mes autres fenêtres en definissant le arrayController du tableau comme objet du windowController de la propriété et en liant de la même manière que si j'étais dans la fenêtre du document.
Sauf que si j'ouvre un autre document avec un autre tableau ça ne se met plus à jour. Bien sûr je peux savoir quand la fenetre de document devient active et en profiter pour aller mettre à jour la fenetre de propriété mais j'envisage de faire plusieurs fenêtre (maintenant que je sais faire:-).
Alors j'ai eu l'idée de mettre un objectController qui me servirait de relais dans mon objet appController qui pour l'instant ne me sert qu'à gérer l'ouverture et la fermeture de l'appli et lancer mes fenêtres. Lui je peux facilement le trouver via [NSApp delegate] et/ou je peux mettre son objectController en paramètre d'un init personnalisé de la fenêtre.
J'y suis presque: après le chargement du nib du document je mets à jour mon objectController appControl monObject] setContent:[objetsController selection et ensuite je lie le content de cet objet à la propriété selection du ArrayController [[appControl monObject] bind:@contentObject toObject:objetsController withKeyPath:@selection options:nil];
Sauf qu'en fait en faisant ça je le lie à la selection du moment mais je n'ai pas de mise à jour quand la sélection change.
Si je mets un objectController dans le nib du document et lie, dans IB, son content à selection de objetsController ça fonctionne mais par programmation comme je le fais ça ne fonctionne pas. Il doit donc y avoir quelque chose dans l'interface qui fait du travail dans mon dos (le côté obscur des bindings ?).
Pas trouvé encore dans Google comment contrer ça.
Peut être parce que je ne devrais pas faire comme ça ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
C'est bien là l'objet de mon message !
Pour l'instant je lui communique l'information en utilisant WindowDidBecomeMain de la fenêtre de "document" je regarde si la fenetre de "propriété" est ouverte et si oui je change sa valeur de controleur de tableau pour qu'elle pointe sur le arrayController du document. Dans IB mes NSControls sont ainsi liés via arrayController.selection.maPropriete .
J'aurais donc voulu avoir un objet principal dans appController qui serait lié à la selection du tableau et auquel je lierais un objectController dans chaque contrôleur de fenêtre de chaque propriété que j'aurais ouverte en laissant les bindings faire leur travail.
Le tout pour que si je change une propriété dans une fenêtre ça continue à mettre à jour le modèle.
[application].mainWindow.windowController.document
C'est fou, mais ça marche !
Les fous ont souvent leur logique donc ça marche effectivement
En fait je pensais que ça ne marchait pas parce que je ne voyais rien changer à l'écran sauf au premier clic sur une ligne du tableau et je mettais ça sur le compte d'un bout de code resté dans ma méthode WindowDidBecomeMain. Mais je l'ai enlevé et au premier clic dans le tableau la valeur s'est affichée en arrière plan, par contre après elle ne change plus quand je change de sélection. Si je me mets en observateur je suis bien avisé d'un changement mais [mainObjet content] reste le même.
Par contre si je clique sur la fenêtre de détail (qui a objectController dans son nib), alors mon objectController n'a plus de contenu ! Pas rentable si je veux modifier la valeur de ma propriété via l'interface.. D'un autre côté si je fais ça alors quand je reviens dans la fenêtre principale alors s'affiche la bonne valeur mise à jour mais après elle ne veut plus changer sauf à refaire la manip.
Bien content d'avoir progressé mais il me manque encore un petit quelque chose je crois, parce que quand même la selection du tableau est toujours visible en arrière plan (grisée mais visible) alors que j'ai "No selection" dans ma fenêtre accessoire passée en avant plan et que ce contenu revient quand je reprends l'autre fenêtre
Si tu veux disposer de plusieurs fenêtres 'normales' appartenant à ton document (ex. classique: logiciel de 3D avec 3 fenêtres pour afficher les vues de dessus, de gauche et de face), il faut que tu les attaches à ton document (voir la doc de NSDocumentController).
Fenêtre normale, je n'avais pas pensé qu'en mettant une palette j'échapperais à ce phénomène.
En fait je tombe sur un autre: comme la sélection n'est plus remise à zéro alors je reste coincé sur la première valeur apparue au chargement du document qui se charge justement avec un élément du tableau sélectionné.
Au moins avec une fenêtre normale j'avais droit à une mise à jour, retardée seulement.
Je viens enfin de comprendre à quoi sert makeWindowControllers ;-)
Mais dans ce cas elle reste attachée à un document et ça n'est pas ce que je voudrais, seulement une fenêtre quelque soit le nombre de documents ouverts.
Pour l'instant je sèche mais je ne désespère pas de trouver pourquoi il ne se met pas à jour tout seul..
Je ne saisis pas ton problème. Tu écris "la sélection n'est plus remise à zéro". Qu'entends-tu par là ? Quand le NSArray observé par le NSArrayController est vide, il est incapable de maintenir la sélection (logique). Quand tu ajoutes un nouvel objet au NSArray observé, il n'est pas sélectionné, à moins que soit cochée la case "Select Inserted Objects" du NSArrayController (et " je crois " que tu utilises la méthode add: ou insert: du NSArrayController, ce qui n'est pas le cas quand tu charges un document).
ça n'est pas possible. Et ceci à cause de la question: "Quel est le document principal à un instant donné ?". Si tu as plusieurs docs ouverts et que tu amènes ta fenêtre accessoire au 1er plan, l'utilisateur est incapable de dire quel est le document en cours d'édition. Les palettes flottantes sont la réponse à cette problématique.
Je vais tenter d'être plus clair. Au départ j'ouvre la fenêtre accessoire et pas de document. La fenêtre accessoire affiche "No selection". Si j'ouvre un document archivé (pour l'instant je n'ai pas encore tenté création ou suppression) alors la fenêtre accessoire prend la valeur du premier objet sélectionné et n'en bouge plus, quelque clic je fasse dans le tableau. Si je clique sur la fenêtre accessoire, alors le NSArrayController a toujours une sélection, en grisé derrière, mais c'est mainWindow.windowController.document.mesObjetsArrayController.selection qui pointe sur rien et donc mon objectContent devient nil.
Bon, ça je peux le concevoir.. (je pourrais m'en sortir par unbind finalement ) Or si une fois sélectionnée la fenêtre accessoire, et donc ce que j'appelle remis à zéro la sélection ce faisant, je reviens et clique dans une des fenêtre document ouvertes la liaison se refait et je vois enfin le bon objet sélectionné affiché dans la fenêtre accessoire. Si je change de sélection rien n'est mis à jour. Tout ça avec une fenêtre normale.
Si la fenêtre est de type panneau alors je ne la vois plus se vider quand elle devient main mais aussi si je retourne dans le document il n'y a pas de "mise à jour" sur l'objet sélectionné, je reste sur la première sélection qui ait existé dans ce document.
Donc le panneau ne m'avance pas encore puisqu'il m'empêche de "vider" la sélection pour qu'elle se remette à jour.
Pour l'instant j'en suis là avec malheureusement peu de temps à consacrer à mes recherches en ce moment. En plus ma connexion internet n'est pas fiable et je n'ai pas su me connecter avant ce soir.
Ah si: si je mets un log dans observeValue et que je demande [objectController content] j'ai toujours le premier objet (type monObjet) quelque soit celui que je sélectionne par la suite, si je log arrayController.selection (via[[[sharedDocument.document]arraycontroller] selection] j'ai d'ailleurs toujours le même objet mais un *proxy*Object. Il faut que je demande selectedObjects là je journalise le bon. Mais si je bind à mainWindow.leLongChemin.selectedObjects je me retrouve avec no selection toujours dans la fenêtre accessoire.
Bref je tourne en rond
Est il concevable de mettre dans les préférences un dictionnaire qui contiendrait les valeurs par défaut de l'objet que je veux voir dans cette fenêtre accessoire, de lier cet objet des preférences à la selection de mon tableau dans la fenêtre document et de l'utiliser comme source des liaisons à l'intérieur de ma fenêtre accessoire.
Cet objet serait commun aux 2 nibs, il serait toujours le dernier en date des objets sélectionné dans un document, ne bougerait pas quand je change de fenêtre et afficherait des valeurs par défaut en cas de non sélection.
Jusqu'à maintenant j'avais évité d'étudier vraiment les prefs utilisateur car je ne compte jamais vendre, ni même pour l'instant partager, le fruit de mon labeur et donc, seul utilisateur je ne voyais pas l'utilité de pouvoir changer les réglages que j'ai choisi !
Question annexe: Y a t-il avantage à définir son objet comme un dictionnaire ? J'ai vu dans un des exemples sur le net une petite appli conçue autour d'un objet de base qui est un dictionnaire et ça semble bien pratique. http://www.cocoadevcentral.com/articles/000080.php ?
Ce que fait l'exemple que tu cites c'est de mettre un NSDictionary comme variable d'instance d'un objet, ce n'est pas sous-classer NSDictionary, ce n'est pas définir un objet comme un dictionnaire. Cela permet de gérer une collection sans définir l'objet comme une collection. Et là , c'est pile la notion de contrôleur du modèle qu'est le dictionnaire. MVC donc.
Oui je me suis mal exprimé: on peut définir un objet seulement via les clefs d'un dictionnaire et ensuite y accéder par ce dictionnaire. Après on utilise ce dictionnaire qui sert de modele, plus facile à archiver ou à lier. Si oui pourquoi n'est ce pas plus répandu dans les exemples ? Quels sont/seraient les inconvenients avant que je me lance a re écrire mon application ?
Ps: beaucoup de difficulté a me connecter. J'utilise l'iPhone mais c'est pas l'idéal.
Dans les tutos sur les bindings que j'ai déposés sur ce site, je mets toujours le modèle ainsi. Je trouve que cela donne plus de maà®trise que d'essayer de tout faire par IB.
Pour l'instant je fais peu de chose dans IB à part lier les contrôles d'interface a l'objectController Outlet de mon FenetreDetailWindowController (fileOwner).
Finalement je me contente de me mettre observateur du chemin de Céros et quand je suis avisé d'un changement de sélection je setContent de l'objectController à NSDocumentController.sharedDocumentController.currentDocument.mesObjetsController.selectedObjects.object@index.0 (en abrégé ! En fait avec les [[[...]..].] nécessaires).
Mais c'est loin d'être l'équivalent à mes yeux d'un binding que j'ai d'ailleurs supprimé vu qu'il ne me sert à rien.
J'espère avoir un jour plus d'expérience et voir où j'ai pêché, pas de raison de renoncer puisque j'arrive quand même à obtenir ce que je veux..
Je garde ton idée et tes tutoriaux sous le coude pour quand je repartirais une nouvelle fois de zéro (pas avant 2 semaines faute de temps).
Je crois qu'il faut que tu nous envoie des copies d'écran et que tu dises exactement ce que tu veux faire, et nous te dirons si c'est possible, et si oui, comment.
Ok malheureusement pas aujourd'hui ni probablement les jours à venir: j'ai trop de travail qui me tient (très) occupé ailleurs.
Dès que ça se calme j'ouvre un nouveau fil en remettant tout à zéro avec quelques captures d'écran pour illustrer mon propos. Un petit croquis vaut souvent mieux qu'un long discours.
Merci pour ton aide
Finalement on peut en faire des choses avec Cocoa en peu de temps !
Donc dans l'appli que je veux construire j'ai une (ou +) fenêtre(s) "document", contrôlée(s) par MyDocument qui contient un tableau référencé "content" d'un NSArrayController dans IB qui me permet ainsi de visualiser et modifier les valeurs des clés de l'objet de ma classe Meeting. En fait c'est à peine plus compliqué: Meeting référence 2 autres objets (A et
Pour l'instant ça fonctionne sans difficulté
Or j'aimerais pouvoir accéder à nom et prénom de A et B du meeting courant depuis une fenêtre (accessoire) qui n'appartiendrait pas à MyDocument. De sorte que si je change de document le contenu de la fenêtre change et s'adapte au nouveau meeting sélectionné.
Ici, plutôt que de créer un autre nib, je me suis contenté de prendre mainNib et d'y ajouter une fenêtre, un objet de classe AppController, et un objectController myMeetingController. Dans la fenêtre j'ai lié les NSTextfields à la sélection de myMeetingController:
Pour décider du content de MyMeetingController j'utilise la méthode init de AppController et 3 lignes:
NSDocumentController *dc = [NSDocumentController sharedDocumentController];
[dc newDocument:self] ;
[myMeetingController bind:@content toObject:NSApp withKeyPath:@mainWindow.windowController.meetingsController.selection options:nil];
Au début je voulais utiliser awakeFromNib mais j'avais des logs :"Cannot remove an observer <NSKeyValueObservance 0x142f53f0> for the key path "windowController.meetingsController.selection" from <NSWindow 0x142db480> because it is not registered as an observer"
Dans init je suis plus confiant qu'il est enregistré..
En apparté j'ai aussi voulu relacher mon objet dc (sharedDocumentController) mais ça fait planter l'application (BAD_EXEC c'est quand je désalloue trop tôt un objet ça en général).
Pour l'instant ça ne fonctionne pas:
J'ai aussi tenté de créer un objet myMeeting de classe Meeting dans AppController. J'avais même commencé par là .... Que je liais à MyDocNib.meetingsController.selectedObjects comme je lie ici myMeetingController à selection et dans IB le déclarer contentObject de myMeetingController. Sans plus de succès.
le dossier compilé de l'appli est ici http://ideaslb.net/Meetings/Meetings.zip. Il utilise 3 lignes de code pour charger 5 fois 2 personnes différentes depuis Carnet d'adresses mais je n'ai rien prévu au cas où le Carnet serait vide..
Mon idée est peut être une mauvaise idée: avoir dans mon AppController un objet qui serait le meeting de référence disponible pour n'importe quelle fenêtre accessoire que je voudrais ouvrir, ou même le point de départ de création d'un meeting pour décider ensuite à quel document l'affecter ...
Pour l'instant elle me semble surtout mauvaise parce que ça ne fonctionne pas comme je voudrais :-\\
Merci par avance à tous ceux qui voudront/pourront m'aider.
- une (parfois plusieurs) fenêtre qui représentent les données (couche Vue du MVC)
- et ces données (couche Modèle du MVC)
Les NSDocumentController sont prévus pour charger des fenêtres de document uniquement; d'ailleurs je n'en ai jamais instancié un moi-même. Si tu veux charger une fenêtre, utilise un NSWindowController.
Ensuite comme je te l'ai déjà expliqué, le problème quand on utilise une fenêtre "normale", c'est que lorsqu'elle est au premier plan, on ne sait plus quel est le document courant. Pour ce que tu veux faire tu disposes de deux approches:
- utiliser une palette flottante, ainsi le document reste au 1er plan
- placer les contrôles secondaires dans la fenêtre du document
La première solution est en effet assez moyenne. On utilise plutôt ce genre de fenêtres pour les Inspecteurs.
Par contre, la seconde est carrément viable:
- tu peux utiliser des popup buttons plutôt que d'encombrantes tableviews pour choisir les candidats. Les menus Pop-ups ont un défaut: s'ils comportent beaucoup d'éléments, ils sont casse-pied.
- tu peux afficher une Sheet pour choisir les candidats ou pour les contrôles secondaires.
Si, ça c'est relativement clair pour moi : un NSDocument fait le lien entre les objets lyophilisés d'un fichier sur le disque (possiblement en devenir) et ceux d'une fenêtre qui me permettent de manipuler et/ou visualiser le data qui composent le document.
Il permet aussi de gérer la fenêtre principale et, via makeWindowControllers / addWindowController /windowControllers, des fenêtres accessoires qui seront donc liées à chaque document ouvert.
C'est donc (à mes yeux) un double contrôleur.
IB pour moi est un exemple d'application "Document-based"
Une des question de la faq c'est "How can I use multiple NSWindowControllers for a single document?"
Ma question c'est "How can I use a windowController for mutiple documents?"
IB fait ça très bien d'ailleurs avec son inspecteur, donc c'est un inspecteur qu'il me faut.
IB a plusieurs onglets pour ne pas encombrer l'écran, je préférerais plusieurs fenêtres. C'est donc pour ça que je voudrais une référence au dernier objet sélectionné dans myDocument dans mon AppController. AppController lancera les différents inspecteurs fonction de telle ou telle propriété que je voudrais vérifier d'un objet qui sera toujours le dernier sélectionné dans la fenêtre d'un document.
Encore une fois IB fait ça très bien: tant qu'un objet éditable est sélectionné dans un document .nib IB adapte son inspecteur quand on change de document et ne le perd pas quand on clique sur l'inspecteur.
Sauf que pour moi ça sera toujours le même type d'objet dans tous les documents alors que l'inspecteur d'IB se retrouve une fois avec un NStextField une autre avec un menuItem etc. En plus IB peut ouvrir plusieurs fenêtres liées à un même nib alors que je ne cherche pas ça, au moins pour l'instant.
Tes relances me sont très précieuses, le livre d'Hillegass ne détaille pas et la documentation Apple n'est pas toujours simple à comprendre pour moi mais ça vient.
OK. En fait, ce que tu veux, c'est disposer de plusieurs inspecteurs. Ce n'est pas trop difficile:
Pour chaque Inspecteur, tu vas créer un NIB, que tu chargeras avec un NSWindowController. Ils utiliseront des NSPanel flotants. Tu peux instancier tes NSWindowController dans la méthode -applicationWillFinishLaunching: de ton AppDelegate. C'est un bon endroit, parce que l'AppDelegate reçoit en premier les actions sur les menus, en particulier, celles qui servent à montrer/masquer les inspecteurs... C'est pas très clair à ton niveau pour l'instant, mais fais-moi confiance sur ce coup.
Ensuite, tu binderas chaque contrôle de ton inspecteur sur [Application].mainWindow.windowController.document.meetingsArrayController.selection.etc.
-> Il faut que le document dispose d'une outlet meetingsArrayController.
Et c'est tout !
Le livre d'Hillegas est très bon, mais les chapitres sur les bindings et CoreData sont bien trop courts.
Quant à la doc d'Apple... je m'y perds encore parfois.
Jusque là je te suis.
Sauf que là tu me demandes de lier un NSTextField à un long chemin qui commence par [Application] mais comment je fais ?
...
Désolé je n'avais pas vu que je pouvais lier à Application dans le popUp des propriétés onglet bindings de IB.
Ok ça roule
Tant que j'y étais de ma découverte (et un peu obstiné je l'avoue ;+) j'ai mis un objectController dans mon .nib et l'ai lié, comme je venais de faire directement avec les controls, mais ça ça ne fonctionne que quand j'active la fenêtre du document, si je change la sélection dans ce document il n'y a pas mise à jour sauf quand je change de document actif. Peut être comprendrais je plus tard pourquoi ...
Pas certain que ça me rassure finalement ;-/
Encore merci.
Tu as mis le NSObjectController dans le NIB d'un inspecteur ? (ça ne sert à rien)
Quel binding as-tu utilisé ?
Comme ça je suis fixé
Content Object
[Application]mainWindow.windowController.document.meetingsController.selection
ça marche au premier clic qui active la fenêtre ou quand elle s'ouvre, après ça ne marche plus..