Une dernière modif : j'ai mis nil à toutes les options, sauf à [popUp bind:@content...] Du coup, la fenêtre affiche untitled lorsque jamais est sélectionné. Parfait.
Pas idiot du tout. Pour ma part je préférais que la fenêtre affiche jamais mais bon c'est TON appli de gestion des ravioli après tout ;D
Bon, la présence d'une instance du popUp controller n'a donc plus aucun intérêt en terme de réglage sous IB d'accord. Quel seul et unique service te rend-elle qu'il va faloir remplacer par une ligne de code ?
Attends ! Je n'ai pas le temps de faire des essais ! J'ai essayé la méthode forte : supprimer le controleur dans I.B. et virer IBOutlet dans AppController.h. Bon, ça ne marche pas, normal, puisque je fais appel à un controleur qui n'existe plus. Faut-il initialiser le controleur dans AppController.m ?
Pour ma part je préférais que la fenêtre affiche jamais.
Oui, mais du coup l'intérêt du NullPlaceholder ? Dans ce cas, "jamais" se comporte comme un huitième jour, que l'on aurait pu mettre dans la NSArray *jours.
le popUpController est lié à la liste des jours le pop-up est lié au popUpController C'est bien le controller qui fait l'intermédiaire entre la liste et le menu ?
Indice: que se passe-t-il quand le nib est chargé ?
C'est un indice, ça ?
Ben oui, dans la doc sur les nib on peut lire qu'au chargement du nib toutes les instances d'objets inclus sont crées. La présence du ArrayContrôller ne te serts plus ici qu'à créer une instance de la classe NSArrayController. Et en plus il te faut un outlet pour te permettre d'y accéder.
Tu peux donc, non pas virer l'outlet mais le transformer en variable d'instance de l'AppController en remplaçant:
C'est bien le controller qui fait l'intermédiaire entre la liste et le menu ?
Le pb c'est que tu dis controller et je sais jamais si tu parles du popUpController ou de l'AppController En ton cas le nib ne joue plus aucun rôle dans le lien dès lors que l'AppController crée lui même le popUpController. 8)
C'était aussi simple que ça ? [EDIT] Je parle de la modif dans mon code. Mais à lire ton dernier message, j'ai l'impression d'avoir oublié quelque chose.
Indice: que se passe-t-il quand le nib est chargé ?
C'est un indice, ça ?
Ben oui, dans la doc sur les nib on peut lire qu'au chargement du nib toutes les instances d'objets inclus sont crées. La présence du ArrayContrôller ne te serts plus ici qu'à créer une instance de la classe NSArrayController. Et en plus il te faut un outlet pour te permettre d'y accéder.
Tu peux donc, non pas virer l'outlet mais le transformer en variable d'instance de l'AppController en remplaçant:
Il te reste plus qu'à instancier ton popUpController dans awakeFromLib
Oh là , nos messages se croisent ! Bon effectivement, quand je dis que j'a viré IBOutlet, ce n'est pas toute la ligne, mais seulement le mot IBOutlet. Et effectivement je pensais à instancier le popUpController. Mais j'ai pris le parti de le court-circuiter, et ça marche. Quel est le problème si on se passe de ce popUpController ?
Je crains que non, il te faut tout de même un contrôleur
Ben si ça marche.
Pour un simple popUp y'a pas de problèmes rééls, mais tu ne bénéficies plus de la puissance d'un arryController. Pas de tri etc... Selon comment évolue ton code c'est pas conseillé. Si tu dois créer d'autre binding sur le même tableau tu risque de télescopper les valeurs. Mais c'est bien rigolo en tout cas Pour ma part je préfère faire sauter le tableau des jours (supprimmer la variable jours quoi)
M.... il a trouvé la faille ! Oui, bien sûr, c'est valable ici car le pop-up ne renvoie qu'une chaà®ne, que l'on dépose dans le titre de la fenêtre ou dans un champ quelconque. Pas besoin de contrôleur pour ça. Mais dans d'autres cas, c'est bien utile ces bêtes là !
Comment peut-on supprimer jours ? Tu m'en avais parlé lundi, mais je ne vois pas où stocker les jours.
Voila ce que c'est de ne pas lire la doc sur les ArrayContr. Très bien cette méthode addObjects. Bon, on va se coucher. On peut encore améliorer l'appli ? (demain alors )
Malheureusement, s'il y a bien un accesseur type Getter pour obtenir le "titleOfSelectedItem" d'un NSPopupButton, il n'y a pas de Setter (setTitleOfSelectedItem). On peut sans doute dire ici que pour la propriété titleOfSelectedItem, les NSPopupButton ne sont pas Key Value Observing compliants. Le titre de la fenêtre sera donc bien initialisée à la première valeur installée du PopUp ("item1) mais ne sera pas mis à jour (pas de possibilité d'observer le changement de valeur par le setter)
Ben les gars ca donne pas envie de se mettre aux bindings tout ce remue-ménage !!!
Salut Eddy Tu te moques là ?
Au contraire on s'est bien amusés à torturer ses malheureux bindings pour voir ce qu'ils ont dans le ventre ;D Et ils se sont montrés bien coopératifs au bout du compte. Par le binding à la volée nous obtenons une souplesse d'utilisation inexploitée la plupart du temps 8)
Au départ Tiff cherchait à éviter l'usage d'un NSObjectController passerelle (dénomé alias dans certains tuto) et il y a parfaitement réussi en 5 minutes avec 1 ligne de code de binding à la volée ("on the fly"). Nous avons par la suite essayé de pousser au maximum les possibilités offertes par cette méthode du binding à la volée tout en explorant un peu les options offertes. Moralité on est passé d'un binding entièrement établi sous I.B. avec un NSObjectController et un NSArrayController, à un nib dépouillé de tout contrôleur avec des bindings entièrement faits dans le code. Ces 2 extrèmes, ainsi que les étapes intermédiaires, étant parfaitement fonctionnelles. :rose!:
Réponses
Pas idiot du tout.
Pour ma part je préférais que la fenêtre affiche jamais mais bon c'est TON appli de gestion des ravioli après tout
Quel seul et unique service te rend-elle qu'il va faloir remplacer par une ligne de code ?
J'ai essayé la méthode forte : supprimer le controleur dans I.B. et virer IBOutlet dans AppController.h. Bon, ça ne marche pas, normal, puisque je fais appel à un controleur qui n'existe plus. Faut-il initialiser le controleur dans AppController.m ?
Bon, je lis tes messages maintenant.
Oui, mais du coup l'intérêt du NullPlaceholder ? Dans ce cas, "jamais" se comporte comme un huitième jour, que l'on aurait pu mettre dans la NSArray *jours.
Non ?
Elle fait le lien entre le pop-up et la NSArray *jours.
Pour la ligne de code, euh, je peux réfléchir ? :P
Tu as raison
C'est un indice, ça ?
[EDIT]
Bon, avant que je ne m'égare, doit-on conserver trace du ArrayController dans le code ? ou peut-on purement et simplement le virer ?
ben non, ce lien est déjà établi dans ton code.
Comment ça ?
le popUpController est lié à la liste des jours
le pop-up est lié au popUpController
C'est bien le controller qui fait l'intermédiaire entre la liste et le menu ?
Ben oui, dans la doc sur les nib on peut lire qu'au chargement du nib toutes les instances d'objets inclus sont crées.
La présence du ArrayContrôller ne te serts plus ici qu'à créer une instance de la classe NSArrayController.
Et en plus il te faut un outlet pour te permettre d'y accéder.
Tu peux donc, non pas virer l'outlet mais le transformer en variable d'instance de l'AppController en remplaçant:
par:
Il te reste plus qu'à instancier ton popUpController dans awakeFromLib
Le pb c'est que tu dis controller et je sais jamais si tu parles du popUpController ou de l'AppController
En ton cas le nib ne joue plus aucun rôle dans le lien dès lors que l'AppController crée lui même le popUpController. 8)
[EDIT]
Je parle de la modif dans mon code.
Mais à lire ton dernier message, j'ai l'impression d'avoir oublié quelque chose.
Je crains que non, il te faut tout de même un contrôleur
Oh là , nos messages se croisent !
Bon effectivement, quand je dis que j'a viré IBOutlet, ce n'est pas toute la ligne, mais seulement le mot IBOutlet.
Et effectivement je pensais à instancier le popUpController. Mais j'ai pris le parti de le court-circuiter, et ça marche. Quel est le problème si on se passe de ce popUpController ?
Ben si ça marche.
Alors, tu trouves un défaut à ma méthode ?
[EDIT]
Bon, je te laisse toute la nuit pour réfléchir, chacun son tour ;D
À demain ! :adios!:
Pour un simple popUp y'a pas de problèmes rééls, mais tu ne bénéficies plus de la puissance d'un arryController. Pas de tri etc...
Selon comment évolue ton code c'est pas conseillé.
Si tu dois créer d'autre binding sur le même tableau tu risque de télescopper les valeurs.
Mais c'est bien rigolo en tout cas
Pour ma part je préfère faire sauter le tableau des jours (supprimmer la variable jours quoi)
Oui, bien sûr, c'est valable ici car le pop-up ne renvoie qu'une chaà®ne, que l'on dépose dans le titre de la fenêtre ou dans un champ quelconque. Pas besoin de contrôleur pour ça. Mais dans d'autres cas, c'est bien utile ces bêtes là !
Comment peut-on supprimer jours ? Tu m'en avais parlé lundi, mais je ne vois pas où stocker les jours.
[EDIT]
Ou plutôt dans toObject:[NSArray...] ? mais alors, quel keyPath ?
8)
Très bien cette méthode addObjects.
Bon, on va se coucher. On peut encore améliorer l'appli ? (demain alors )
encore juste un mot magique qui vote contre la suppression pure et simple du NSArrayController: Le Model View Controller Paradygm 8)
Bonne nuit Tiff :adios!:
Entièrement d'accord.
À plus
Oui quelle horreur !!!
Ben les gars ca donne pas envie de se mettre aux bindings tout ce remue-ménage !!!
Tant qu'à faire : peut-on se passer de la variable leJour pour lier la fenêtre sur le pop-up ?
en théorie, on aurait pu s'amuser à écrire:
Malheureusement, s'il y a bien un accesseur type Getter pour obtenir le "titleOfSelectedItem" d'un NSPopupButton, il n'y a pas de Setter (setTitleOfSelectedItem).
On peut sans doute dire ici que pour la propriété titleOfSelectedItem, les NSPopupButton ne sont pas Key Value Observing compliants.
Le titre de la fenêtre sera donc bien initialisée à la première valeur installée du PopUp ("item1) mais ne sera pas mis à jour (pas de possibilité d'observer le changement de valeur par le setter)
Salut Eddy
Tu te moques là ?
Au contraire on s'est bien amusés à torturer ses malheureux bindings pour voir ce qu'ils ont dans le ventre ;D
Et ils se sont montrés bien coopératifs
Au départ Tiff cherchait à éviter l'usage d'un NSObjectController passerelle (dénomé alias dans certains tuto) et il y a parfaitement réussi en 5 minutes avec 1 ligne de code de binding à la volée ("on the fly").
Nous avons par la suite essayé de pousser au maximum les possibilités offertes par cette méthode du binding à la volée tout en explorant un peu les options offertes.
Moralité on est passé d'un binding entièrement établi sous I.B. avec un NSObjectController et un NSArrayController, à un nib dépouillé de tout contrôleur avec des bindings entièrement faits dans le code.
Ces 2 extrèmes, ainsi que les étapes intermédiaires, étant parfaitement fonctionnelles. :rose!: