Merci pour toutes ces explications mais même si c'est possible, IBOutlet est avant tout fait pour les objets disons graphiques et intencier ceux-ci au chargement du NIB ?
Un IBOutlet est fait pour que tu puisses connecter des objets de ton NIB à ces outlets (donc à tes variables d'instance de ta classe qui sont précédés du mot IBOutlet) dans IB. Or en général, dans un NIB on a surtout des éléments graphiques, que l'on connecte aux IBOutlets.
Dans ce cas ton IBOutlet est en effet connecté à par exemple un NSTextField ou une NSTextView, etc. Mais dans un NIB il n'y a pas que des éléments graphiques, il y a aussi le File's owner (objet qui a "désarchivé" le NIB), et souvent on met un objet qu'on appelle "App Controller" par exemple et qui nous sert de contrôlleur d'application qui centralise tout et permet de faire le lien entre les éléments de notre NIB et le code dans Xcode. Et rien ne t'empêche de relier un IBOutlet d'un objet de ton NIB à cet AppController, qui est aussi dans ton NIB même si ce n'est pas un objet graphique.
Donc certes dans 80% des cas un IBOutlet est connecté à un élément graphique, mais y'a des fois où c'est à un objet. En fait c'est pas lié, puisque l'IBOutlet dit juste que ça te permet de connecter ta variable d'instance à un objet de ton NIB dans IB, que cet objet soit visuel ou non.
Ensuite l'IBOutlet n'instancie pas les objets au chargement du NIB. Les fichiers NIB sont comme une "collection d'objets reliés entre eux" (par des IBOutlets justement), une sorte d'archive d'objets (que tu pourrais créer par ligne de code mais ça ferait 3km de code). C'est quand le NIB est chargé (soit le NIB principal de ton application chargé automatiquement au lancement de cette dernière, soit un NIB chargé manuellement par code) que les objets qu'il contient (graphiques ou non) sont instanciés... et que les variables d'instances notées IBOutlet qui ont été connectées dans ce NIB sont associées aux objets instanciés.
Quant on déclare IBOutlet un membre ( on va dire ) dans le .h c'est bien pour qu' IB le reconnaisse et que généralement on le connecte a un objet d'une vue ( d'une fenêtre )...
Par contre une classe AppController ( par exemple ) est spécifiée pour une objet NIB, déclarer une classe IBOutlet même si c'est possible ne présente pas forcément grand intérêt...
Quant on déclare IBOutlet un membre ( on va dire ) dans le .h c'est bien pour qu' IB le reconnaisse et que généralement on le connecte a un objet d'une vue ( d'une fenêtre )...
Oui tout à fait. généralement on le connecte à un objet d'une vue, mais on peut aussi le connecter à un objet non graphique. Et c'est très précisément très souvent le cas pour un dataSource ou un delegate qui ne sont bien souvent pas des objets graphiques, eux. Par exemple bien souvent le delegate, le target ou le dataSource d'un objet de ton NIB (qui sont tous trois des IBOutlets) sera connecté au File's Owner ou plus souvent encore le AppController (95% des cas on vas dire). Il y a aussi certains cas où avec les IBOutlets dans IB on connecte deux objets non graphiques ensemble, genre le IBOutlet de ton AppController qui pointe vers un UIViewController dans les applis iPhone, ou un IBOutlet de ton AppController qui est connecté à un objet Drawer dans une appli OSX (l'objet Drawer n'est pas graphique, il contient lui-même un IBOutlet vers sa NSView contenant les objets graphiques à afficher)
dans 1229004940:
Par contre une classe AppController ( par exemple ) est spécifiée pour une objet NIB, déclarer une classe IBOutlet même si c'est possible ne présente pas forcément grand intérêt...
Heu j'ai pas compris ta phrase là ... "déclarer une classe IBOutlet" ??!
Par contre une classe AppController ( par exemple ) est spécifiée pour une objet NIB, déclarer une classe IBOutlet même si c'est possible ne présente pas forcément grand intérêt...
Heu j'ai pas compris ta phrase là ... "déclarer une classe IBOutlet" ??!
J'avoue patauger un peu... Je voulais dire IBOutlet AppController * mon controleur ;
Ah bah si ça c'est utile aussi. Moins souvent rencontré certes mais utilisé.
Justement par exemple si tu as un Drawer dans ta fenêtre (un objet Drawer c'est un objet non graphique, associé à une NSView qui correspond à ce que tu veux afficher dans ta fenêtre tiroir), en général ton AppController pointe dessus. Ou en iPhone, les UIViewControllers qui traà®nent vraiment partout, là ça arrive assez souvent que dans ton AppController tu aies un "IBOutlet UIViewController* viewController" pour pointer sur le ViewController principal... ou encore si tu sous-classes UIViewController comme c'est quasiment le cas à chaque fois, rajouter dedans un IBOutlet qui va te permettre de pointer sur un autre ViewController ou sur un autre objet non graphique...
De toute façon je ne vois pas ce qui te gène, un IBOutlet est juste une variable d'instance mais qu'on peut affecter à un objet via une connexion dans IB, que cet objet soit graphique ou non ne rentre pas dans la définition d'un IBOutlet. Dans une appli simple à 95% ce sont des objets graphiques sauf les delegate, dataSource et target qui sont souvent ton AppController, dans une appli plus complexe ou une appli iPhone ce sont bien plus souvent des objets non graphiques, genre 70%/30%, et alors ça change quoi ? tu fais juste pointer ta variable d'instance sur un objet se trouvant dans ton NIB dans IB quel qu'il soit graphique ou non ça n'entre pas en ligne de compte
De toute façon je ne vois pas ce qui te gène, un IBOutlet est juste une variable d'instance mais qu'on peut affecter à un objet via une connexion dans IB......
Rien ne me gène j'étais simplement surpris et plutôt ravis de toutes ces précisions.
C'est quoi la question ? Chaque %@ appelle la méthode "description" de la classe pour afficher. Pour NSObject ça affiche juste l'adresse hexa Pour NSArray, ça affiche la liste des "description" du contenu ...
On peut redéfinir la méthode description d'une classe...
Je me demandais ( sans trop y croire ) s'il était possible de redéfinir la méthode description d'une instance d'une classe sans forcément surcharger celle-ci ?
avec une méthode du genre [monInstance setDescription:@ma description];
On peut redéfinir la méthode description d'une classe...
Non, description est une méthode d'instance. Donc chaque instance est libre de renvoyer ce qu'elle veut lors de l'appel de cette méthode. La valeur retournée n'est qu'une NSString, donc il est facile de modifier le contenu de cette NSString en fonction du contenu (properties) de l'instance qui reçoit ce message.
Même à des fins de debug, j'avoue ne rien comprendre à ta demande... Que voudrais tu que [tt]NSLog(@Ajout de ... à %@",employes);[/tt] te renvoie comme description ?
Astuce : [tt]NSLog(@%x, employes)[/tt] pour avoir uniquement l'adresse hexa, [tt]NSLog(@%@", [employes className])[/tt] pour avoir le nom de la classe.
L'exercice demande l'utilisation d'une TableView sans NSArrayController, bref a l'ancienne... ça correspond a l'exemple du chapitre 5 de l'ancien livre page 107 à 124 que j'exécute au pas, a pas http://gercofis.free.fr/Cocoa/Essais.zip La création d'une ligne pose un problème avec le [size=12pt]datasource[/size]
Dans le nib tu n'as pas défini les "identifier" des tableColumn. Dans createEmploye: il faut faire [newEmployes release]; et non [employes release] qui te détruit ta NSMutableArray .
Je venais de trouvé ça en même temps, les identifiers sur un précédent essai... en fait aucun projet n'était correct. ça m'aura bien initié a toutes ces manipulations en tous cas et normalement c'est le but, J'étais tellement sûr que c'était un problème de connexion. voici l'exercice correct : http://gercofis.free.fr/Cocoa/RaiseManExercice.zip... En tous cas merci beaucoup
Sans rentrer dans le détail, le codage spécifié réalisé ça a fonctionné nickel la première fois... Depuis impossible le menu édition correspondant reste grisé...
En fait le problème de Undo/Redo est que le menu ne suit pas ???
Pour l'occasion j'ai modifié le menu Apropos,Fichier,et Edition
A l'utilisation A-Propos et Fichier apparaissent bien, mais Edition nom, j'ai bien du mal a comprendre pourquoi ?
Précision les items du menu édition ne sont pas ceux que j'ai modifié, je n'ai donc pas mes items Undo/Redo et c'est pour ça que ça ne marche pas NSUndoManager est bien actif ( phrase rajoutée vu le post suivant ! )
Tu peux compléter ton zip, les classes n'y sont pas ? Si le menu reste grisé, c'est sans doute que tu n'as pas mis la bonne définition du undo à faire sur la pile.
Je viens de m'en apercevoir, j'ai honte, je remets comme il faut dans la soirée... Je me demande si un grand coup de balais ne solutionnes pas les choses...
Il y a un Untitled.xib dans ton projet. Quand on le vire, le document ne s'ouvre plus, c'est sans doute qu'il a pris la place de MyDocument.xib lors d'une erreur de manip.
Il y a un Untitled.xib dans ton projet. Quand on le vire, le document ne s'ouvre plus, c'est sans doute qu'il a pris la place de MyDocument.xib lors d'une erreur de manip.
ça confirme bien ce que je pensais, mais si tu me précises comment on trouve ça ? Parce que même maintenant que je la sais je ne parviens pas a le trouver, a moins qu'il soit en fichier caché ? Encore merci de toutes façons...
Réponses
id toto -> reconnu
IBOutlet id _toto -> reconnu
Or en général, dans un NIB on a surtout des éléments graphiques, que l'on connecte aux IBOutlets.
Dans ce cas ton IBOutlet est en effet connecté à par exemple un NSTextField ou une NSTextView, etc.
Mais dans un NIB il n'y a pas que des éléments graphiques, il y a aussi le File's owner (objet qui a "désarchivé" le NIB), et souvent on met un objet qu'on appelle "App Controller" par exemple et qui nous sert de contrôlleur d'application qui centralise tout et permet de faire le lien entre les éléments de notre NIB et le code dans Xcode. Et rien ne t'empêche de relier un IBOutlet d'un objet de ton NIB à cet AppController, qui est aussi dans ton NIB même si ce n'est pas un objet graphique.
Donc certes dans 80% des cas un IBOutlet est connecté à un élément graphique, mais y'a des fois où c'est à un objet. En fait c'est pas lié, puisque l'IBOutlet dit juste que ça te permet de connecter ta variable d'instance à un objet de ton NIB dans IB, que cet objet soit visuel ou non.
Ensuite l'IBOutlet n'instancie pas les objets au chargement du NIB. Les fichiers NIB sont comme une "collection d'objets reliés entre eux" (par des IBOutlets justement), une sorte d'archive d'objets (que tu pourrais créer par ligne de code mais ça ferait 3km de code). C'est quand le NIB est chargé (soit le NIB principal de ton application chargé automatiquement au lancement de cette dernière, soit un NIB chargé manuellement par code) que les objets qu'il contient (graphiques ou non) sont instanciés... et que les variables d'instances notées IBOutlet qui ont été connectées dans ce NIB sont associées aux objets instanciés.
Quant on déclare IBOutlet un membre ( on va dire ) dans le .h c'est bien pour qu' IB le reconnaisse et que généralement on le connecte a un objet d'une vue ( d'une fenêtre )...
Par contre une classe AppController ( par exemple ) est spécifiée pour une objet NIB, déclarer une classe IBOutlet même si c'est possible ne présente pas forcément grand intérêt...
Après peut-importe les liaisons....
Par exemple bien souvent le delegate, le target ou le dataSource d'un objet de ton NIB (qui sont tous trois des IBOutlets) sera connecté au File's Owner ou plus souvent encore le AppController (95% des cas on vas dire).
Il y a aussi certains cas où avec les IBOutlets dans IB on connecte deux objets non graphiques ensemble, genre le IBOutlet de ton AppController qui pointe vers un UIViewController dans les applis iPhone, ou un IBOutlet de ton AppController qui est connecté à un objet Drawer dans une appli OSX (l'objet Drawer n'est pas graphique, il contient lui-même un IBOutlet vers sa NSView contenant les objets graphiques à afficher)
Heu j'ai pas compris ta phrase là ... "déclarer une classe IBOutlet" ??!
J'avoue patauger un peu...
Je voulais dire IBOutlet AppController * mon controleur ;
Justement par exemple si tu as un Drawer dans ta fenêtre (un objet Drawer c'est un objet non graphique, associé à une NSView qui correspond à ce que tu veux afficher dans ta fenêtre tiroir), en général ton AppController pointe dessus. Ou en iPhone, les UIViewControllers qui traà®nent vraiment partout, là ça arrive assez souvent que dans ton AppController tu aies un "IBOutlet UIViewController* viewController" pour pointer sur le ViewController principal... ou encore si tu sous-classes UIViewController comme c'est quasiment le cas à chaque fois, rajouter dedans un IBOutlet qui va te permettre de pointer sur un autre ViewController ou sur un autre objet non graphique...
De toute façon je ne vois pas ce qui te gène, un IBOutlet est juste une variable d'instance mais qu'on peut affecter à un objet via une connexion dans IB, que cet objet soit graphique ou non ne rentre pas dans la définition d'un IBOutlet. Dans une appli simple à 95% ce sont des objets graphiques sauf les delegate, dataSource et target qui sont souvent ton AppController, dans une appli plus complexe ou une appli iPhone ce sont bien plus souvent des objets non graphiques, genre 70%/30%, et alors ça change quoi ? tu fais juste pointer ta variable d'instance sur un objet se trouvant dans ton NIB dans IB quel qu'il soit graphique ou non ça n'entre pas en ligne de compte
La dernière ligne sert au debug et affiche les adresses de p et employes...
Pour le p on s'en sort comme suit ( en supposant qu'il y ait une erreur ! )
NSLog(@Ajout de %@ à %@",p.personName,employes);
Mais pour employes comment fait-on ?
La question peut-être plus générale on peut fixer une description pour une classe, comment peut-on la modifier pour une instance
Chaque %@ appelle la méthode "description" de la classe pour afficher.
Pour NSObject ça affiche juste l'adresse hexa
Pour NSArray, ça affiche la liste des "description" du contenu
...
Je me demandais ( sans trop y croire ) s'il était possible de redéfinir la méthode description d'une instance d'une classe sans forcément surcharger celle-ci ?
avec une méthode du genre
[monInstance setDescription:@ma description];
Enfin tu peux avoir une variable de classe "desc" modifiable avec "setDesc", et faire que "description" renvoie "desc" hein ???
Non, description est une méthode d'instance.
Donc chaque instance est libre de renvoyer ce qu'elle veut lors de l'appel de cette méthode.
La valeur retournée n'est qu'une NSString, donc il est facile de modifier le contenu de cette NSString en fonction du contenu (properties) de l'instance qui reçoit ce message.
Même à des fins de debug, j'avoue ne rien comprendre à ta demande...
Que voudrais tu que [tt]NSLog(@Ajout de ... à %@",employes);[/tt] te renvoie comme description ?
Astuce :
[tt]NSLog(@%x, employes)[/tt] pour avoir uniquement l'adresse hexa,
[tt]NSLog(@%@", [employes className])[/tt] pour avoir le nom de la classe.
L'idée de className est bien et je retiens...
ça correspond a l'exemple du chapitre 5 de l'ancien livre page 107 à 124 que j'exécute au pas, a pas
http://gercofis.free.fr/Cocoa/Essais.zip
La création d'une ligne pose un problème avec le [size=12pt]datasource[/size]
Il faut faire un [aTableView reloadData] pour mettre à jour.
Rien dans les 2 exemples et ça ne fonctionne pas, en tous cas chez moi...
Dans createEmploye: il faut faire [newEmployes release]; et non [employes release] qui te détruit ta NSMutableArray .
voici l'exercice correct : http://gercofis.free.fr/Cocoa/RaiseManExercice.zip...
En tous cas merci beaucoup
Depuis impossible le menu édition correspondant reste grisé...
J'ai essayé ceci :
Il n'a pas aimé du tout, rien de plus n'est précisé, j'ai donc raté qqch ???
Pour l'occasion j'ai modifié le menu Apropos,Fichier,et Edition
A l'utilisation A-Propos et Fichier apparaissent bien, mais Edition nom, j'ai bien du mal a comprendre pourquoi ?
Précision les items du menu édition ne sont pas ceux que j'ai modifié, je n'ai donc pas mes items Undo/Redo et c'est pour ça que ça ne marche pas NSUndoManager est bien actif ( phrase rajoutée vu le post suivant ! )
[url=http://gercofis.free.fr/Cocoa/RaiseManExercice 2.zip]http://gercofis.free.fr/Cocoa/RaiseManExercice 2.zip[/url]
Je télécharge ton code, je vais regarder.
Si le menu reste grisé, c'est sans doute que tu n'as pas mis la bonne définition du undo à faire sur la pile.
Voilà c'est fait [url=http://gercofis.free.fr/Cocoa/RaiseManExercice 2.zip]http://gercofis.free.fr/Cocoa/RaiseManExercice 2.zip[/url]
Quand on le vire, le document ne s'ouvre plus, c'est sans doute qu'il a pris la place de MyDocument.xib lors d'une erreur de manip.
Parce que même maintenant que je la sais je ne parviens pas a le trouver, a moins qu'il soit en fichier caché ?
Encore merci de toutes façons...