Je commence à lire quelques doc sur l'Obj-C afin de commencer
(peut-être) à découvrir Cocoa. (Jusqu'à présent, je n'ai toujours
programmé qu'avec InterfaceLib puis Carbon)
Je n'ai pas trouvé de forum fr dédié à l'Obj-C. Je poste donc ici.
Question :
Peut-on définir pour un objet des opérateurs +, *, etc. comme en C++ ?
Si oui, comment ?
SI non, la solution usuelle est-elle Obj-C++ ?
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Je ne parles pas Anglais et je ne suis pas programmeur...
Mais je trouve qu'on utilise ça très facilement
Tu parles d'InterfaceBuilder, de Cocoa ou de l'Objective-C ?
les remarques sur IB me semblent ridicules...
Lesquelles ?
On est pas obliger de l'utiliser...
Je débute avec Cocoa. Je me contente donc de lire les docs.
Developing Cocoa Objective-C Applications: A Tutorial Page 24: « Every Cocoa application with a graphical user interface has at least one nib file. »
Je ne pensais pas que l'on pouvait créer des fichiers nib sans InterfaceBuilder.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Gilles <gilles-.robert@wanadoo.fr> wrote:
J'ai lu ce qui suit...
Tu parles de ce qui précède ?
Je ne parles pas Anglais et je ne suis pas programmeur...
Mais je trouve qu'on utilise ça très facilement
Tu parles d'InterfaceBuilder, de Cocoa ou de l'Objective-C ?
les remarques sur IB me semblent ridicules...
Lesquelles ?
On est pas obliger de l'utiliser...
Je débute avec Cocoa. Je me contente donc de lire les docs.
Developing Cocoa Objective-C
Applications: A Tutorial
Page 24:
« Every Cocoa application with a graphical user interface has at least
one nib file. »
Je ne pensais pas que l'on pouvait créer des fichiers nib sans
InterfaceBuilder.
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Je ne parles pas Anglais et je ne suis pas programmeur...
Mais je trouve qu'on utilise ça très facilement
Tu parles d'InterfaceBuilder, de Cocoa ou de l'Objective-C ?
les remarques sur IB me semblent ridicules...
Lesquelles ?
On est pas obliger de l'utiliser...
Je débute avec Cocoa. Je me contente donc de lire les docs.
Developing Cocoa Objective-C Applications: A Tutorial Page 24: « Every Cocoa application with a graphical user interface has at least one nib file. »
Je ne pensais pas que l'on pouvait créer des fichiers nib sans InterfaceBuilder.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
DINH Viêt Hoà
Developing Cocoa Objective-C Applications: A Tutorial Page 24: « Every Cocoa application with a graphical user interface has at least one nib file. »
heu ... tu crois qu'on ne peut pas créer des fenêtres et des boutons en n'utilisant que du code ? et que, les fichiers nib seraient des informations sur la façon de recréer ces objets en mémoire ? Enfin, ce ne sont que des suppositions ... ne connaissant pas très bien Cocoa ...
-- DINH V. Hoa,
"le vin c'est pas de l'alcool" -- MAB
Developing Cocoa Objective-C
Applications: A Tutorial
Page 24:
« Every Cocoa application with a graphical user interface has at least
one nib file. »
heu ... tu crois qu'on ne peut pas créer des fenêtres et des boutons en
n'utilisant que du code ?
et que, les fichiers nib seraient des informations sur la façon de
recréer ces objets en mémoire ?
Enfin, ce ne sont que des suppositions ... ne connaissant pas très bien
Cocoa ...
Developing Cocoa Objective-C Applications: A Tutorial Page 24: « Every Cocoa application with a graphical user interface has at least one nib file. »
heu ... tu crois qu'on ne peut pas créer des fenêtres et des boutons en n'utilisant que du code ? et que, les fichiers nib seraient des informations sur la façon de recréer ces objets en mémoire ? Enfin, ce ne sont que des suppositions ... ne connaissant pas très bien Cocoa ...
-- DINH V. Hoa,
"le vin c'est pas de l'alcool" -- MAB
lists
DINH Viêt Hoà wrote:
heu ... tu crois qu'on ne peut pas créer des fenêtres et des boutons en n'utilisant que du code ?
Je pense qu'on peut.
Mais ils disent qu'il faut au moins un nib... Sinon, je ne pense pas qu'il y ait un intérêt quelconque à vouloir se passer totalement d'InterfaceBuilder.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
DINH Viêt Hoà <dinh.viet.hoa@free.fr> wrote:
heu ... tu crois qu'on ne peut pas créer des fenêtres et des boutons en
n'utilisant que du code ?
Je pense qu'on peut.
Mais ils disent qu'il faut au moins un nib...
Sinon, je ne pense pas qu'il y ait un intérêt quelconque à vouloir se
passer totalement d'InterfaceBuilder.
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
heu ... tu crois qu'on ne peut pas créer des fenêtres et des boutons en n'utilisant que du code ?
Je pense qu'on peut.
Mais ils disent qu'il faut au moins un nib... Sinon, je ne pense pas qu'il y ait un intérêt quelconque à vouloir se passer totalement d'InterfaceBuilder.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Gilles
J'ai lu ce qui suit...
Tu parles de ce qui précède ?
oui
Je ne parles pas Anglais et je ne suis pas programmeur...
Mais je trouve qu'on utilise ça très facilement
Tu parles d'InterfaceBuilder, de Cocoa ou de l'Objective-C ?
les 3
les remarques sur IB me semblent ridicules...
Lesquelles ?
Toutes, IB est très facile a utiliser, dans le code en fait on importe l'objet .nib en question et il est utilisé directement....
pour localiser c'est un + indiscutable...
Je ne pensais pas que l'on pouvait créer des fichiers nib sans InterfaceBuilder.
la création d'un fichier nib n'est pas indispensable
au cas ou mon AIM/iChat 'Gercofis"
J'ai lu ce qui suit...
Tu parles de ce qui précède ?
oui
Je ne parles pas Anglais et je ne suis pas programmeur...
Mais je trouve qu'on utilise ça très facilement
Tu parles d'InterfaceBuilder, de Cocoa ou de l'Objective-C ?
les 3
les remarques sur IB me semblent ridicules...
Lesquelles ?
Toutes, IB est très facile a utiliser, dans le code en fait on importe
l'objet .nib en question et il est utilisé directement....
pour localiser c'est un + indiscutable...
Je ne pensais pas que l'on pouvait créer des fichiers nib sans
InterfaceBuilder.
la création d'un fichier nib n'est pas indispensable
Je ne parles pas Anglais et je ne suis pas programmeur...
Mais je trouve qu'on utilise ça très facilement
Tu parles d'InterfaceBuilder, de Cocoa ou de l'Objective-C ?
les 3
les remarques sur IB me semblent ridicules...
Lesquelles ?
Toutes, IB est très facile a utiliser, dans le code en fait on importe l'objet .nib en question et il est utilisé directement....
pour localiser c'est un + indiscutable...
Je ne pensais pas que l'on pouvait créer des fichiers nib sans InterfaceBuilder.
la création d'un fichier nib n'est pas indispensable
au cas ou mon AIM/iChat 'Gercofis"
lists
Gilles wrote:
Toutes, IB est très facile a utiliser,
Quelqu'un a dit le contraire dans le thread ?
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était surprenant de définir dans InterfaceBuilder des choses que j'aurais typiquement défini dans le code (Par exemple, dans le cas du CurrencyConverter, la classe « CurrencyController »).
dans le code en fait on importe l'objet .nib en question et il est utilisé directement....
Je suis au courant. De plus, je le faisais déjà dans Carbon donc ce n'est pas la raison de mon étonnement.
pour localiser c'est un + indiscutable...
À l'époque des ressources, si on utilisait les ressources CNTL, DLOG, MENU, STR# et consors, on pouvait très bien traduire exactement de la même façon. (cf. MacSOUP par exemple)
En outre, on pourrait très bien traduire un logiciel grâce à un fichier qui contient des strings. Carbon et Cocoa utilisent également cette technique (cf. Localizable.strings).
Je suis d'accord qu'InterfaceBuilder puisse simplifier la traduction d'un logiciel mais c'est loin d'être l'unique but de la chose.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Gilles <gilles-.robert@wanadoo.fr> wrote:
Toutes, IB est très facile a utiliser,
Quelqu'un a dit le contraire dans le thread ?
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était
surprenant de définir dans InterfaceBuilder des choses que j'aurais
typiquement défini dans le code (Par exemple, dans le cas du
CurrencyConverter, la classe « CurrencyController »).
dans le code en fait on importe
l'objet .nib en question et il est utilisé directement....
Je suis au courant.
De plus, je le faisais déjà dans Carbon donc ce n'est pas la raison de
mon étonnement.
pour localiser c'est un + indiscutable...
À l'époque des ressources, si on utilisait les ressources CNTL, DLOG,
MENU, STR# et consors, on pouvait très bien traduire exactement de la
même façon. (cf. MacSOUP par exemple)
En outre, on pourrait très bien traduire un logiciel grâce à un fichier
qui contient des strings. Carbon et Cocoa utilisent également cette
technique (cf. Localizable.strings).
Je suis d'accord qu'InterfaceBuilder puisse simplifier la traduction
d'un logiciel mais c'est loin d'être l'unique but de la chose.
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était surprenant de définir dans InterfaceBuilder des choses que j'aurais typiquement défini dans le code (Par exemple, dans le cas du CurrencyConverter, la classe « CurrencyController »).
dans le code en fait on importe l'objet .nib en question et il est utilisé directement....
Je suis au courant. De plus, je le faisais déjà dans Carbon donc ce n'est pas la raison de mon étonnement.
pour localiser c'est un + indiscutable...
À l'époque des ressources, si on utilisait les ressources CNTL, DLOG, MENU, STR# et consors, on pouvait très bien traduire exactement de la même façon. (cf. MacSOUP par exemple)
En outre, on pourrait très bien traduire un logiciel grâce à un fichier qui contient des strings. Carbon et Cocoa utilisent également cette technique (cf. Localizable.strings).
Je suis d'accord qu'InterfaceBuilder puisse simplifier la traduction d'un logiciel mais c'est loin d'être l'unique but de la chose.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Gilles
Toutes, IB est très facile a utiliser, Quelqu'un a dit le contraire dans le thread ?
il a faux...
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était surprenant de définir dans InterfaceBuilder des choses que j'aurais typiquement défini dans le code (Par exemple, dans le cas du CurrencyConverter, la classe « CurrencyController »).
je ne connais pas ce truc...
Mais pourquoi se priver d'un telle simplicité, en plus il suffit de regarder....
Toutes, IB est très facile a utiliser,
Quelqu'un a dit le contraire dans le thread ?
il a faux...
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était
surprenant de définir dans InterfaceBuilder des choses que j'aurais
typiquement défini dans le code (Par exemple, dans le cas du
CurrencyConverter, la classe « CurrencyController »).
je ne connais pas ce truc...
Mais pourquoi se priver d'un telle simplicité, en plus il suffit de
regarder....
Toutes, IB est très facile a utiliser, Quelqu'un a dit le contraire dans le thread ?
il a faux...
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était surprenant de définir dans InterfaceBuilder des choses que j'aurais typiquement défini dans le code (Par exemple, dans le cas du CurrencyConverter, la classe « CurrencyController »).
je ne connais pas ce truc...
Mais pourquoi se priver d'un telle simplicité, en plus il suffit de regarder....
lists
Gilles wrote:
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était surprenant de définir dans InterfaceBuilder des choses que j'aurais typiquement défini dans le code (Par exemple, dans le cas du CurrencyConverter, la classe « CurrencyController »).
je ne connais pas ce truc... Mais pourquoi se priver d'un telle simplicité, en plus il suffit de regarder....
Comment peux-tu juger de la simplicité si tu ne sais pas de quel « truc » on parle ?
Si ta remarque porte sur l'utilisation d'InterfaceBuilder pour créer une fenêtre et mettre des boutons. Je ne vois pas pourquoi on s'en priverait, moi non plus. Je me sers d'ailleurs de cette fonctionnalité dans mes applications Carbon.
Ce n'est pas de ça que je parle.
Ce que je trouvais surprenant (je n'ai pas dit que c'était « mal », juste « surprenant ») c'était de définir des classes qui relèvent plus de l'architecture du programme que de l'interface utilisateur proprement dite à partir d'InterfaceBuilder.
En outre, personne n'a dit dans ce thread, à aucun moment, qu'il souhaitait se passer totalement d'InterfaceBuilder. J'ai simplement répondu à la remarque « On n'est pas obligé de s'en servir ».
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Gilles <gilles-.robert@wanadoo.fr> wrote:
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était
surprenant de définir dans InterfaceBuilder des choses que j'aurais
typiquement défini dans le code (Par exemple, dans le cas du
CurrencyConverter, la classe « CurrencyController »).
je ne connais pas ce truc...
Mais pourquoi se priver d'un telle simplicité, en plus il suffit de
regarder....
Comment peux-tu juger de la simplicité si tu ne sais pas de quel
« truc » on parle ?
Si ta remarque porte sur l'utilisation d'InterfaceBuilder pour créer une
fenêtre et mettre des boutons. Je ne vois pas pourquoi on s'en
priverait, moi non plus. Je me sers d'ailleurs de cette fonctionnalité
dans mes applications Carbon.
Ce n'est pas de ça que je parle.
Ce que je trouvais surprenant (je n'ai pas dit que c'était « mal »,
juste « surprenant ») c'était de définir des classes qui relèvent plus
de l'architecture du programme que de l'interface utilisateur proprement
dite à partir d'InterfaceBuilder.
En outre, personne n'a dit dans ce thread, à aucun moment, qu'il
souhaitait se passer totalement d'InterfaceBuilder.
J'ai simplement répondu à la remarque « On n'est pas obligé de s'en
servir ».
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était surprenant de définir dans InterfaceBuilder des choses que j'aurais typiquement défini dans le code (Par exemple, dans le cas du CurrencyConverter, la classe « CurrencyController »).
je ne connais pas ce truc... Mais pourquoi se priver d'un telle simplicité, en plus il suffit de regarder....
Comment peux-tu juger de la simplicité si tu ne sais pas de quel « truc » on parle ?
Si ta remarque porte sur l'utilisation d'InterfaceBuilder pour créer une fenêtre et mettre des boutons. Je ne vois pas pourquoi on s'en priverait, moi non plus. Je me sers d'ailleurs de cette fonctionnalité dans mes applications Carbon.
Ce n'est pas de ça que je parle.
Ce que je trouvais surprenant (je n'ai pas dit que c'était « mal », juste « surprenant ») c'était de définir des classes qui relèvent plus de l'architecture du programme que de l'interface utilisateur proprement dite à partir d'InterfaceBuilder.
En outre, personne n'a dit dans ce thread, à aucun moment, qu'il souhaitait se passer totalement d'InterfaceBuilder. J'ai simplement répondu à la remarque « On n'est pas obligé de s'en servir ».
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
testuz73
Julien Salort wrote:
Gilles wrote:
Toutes, IB est très facile a utiliser,
Quelqu'un a dit le contraire dans le thread ?
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était surprenant de définir dans InterfaceBuilder des choses que j'aurais typiquement défini dans le code (Par exemple, dans le cas du CurrencyConverter, la classe « CurrencyController »).
Si je vois bien l'exemple, IB ne fait que créer les fichiers .h et .m avec la définition de la classe. Tu peux rajouter certaines définitions d'outlet et d'action pour éviter des aller-retour avec Xcode, mais après tu dois quand même passer par Xcode. Ca n'est qu'un moyen pour faciliter la vie. Mais perso, je préfère définir d'abord dans Xcode, puis utiliser la classe ainsi crééer dans IB.
-- Frédéric Testuz <mailto:
Julien Salort <lists@juliensalort.org> wrote:
Gilles <gilles-.robert@wanadoo.fr> wrote:
Toutes, IB est très facile a utiliser,
Quelqu'un a dit le contraire dans le thread ?
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était
surprenant de définir dans InterfaceBuilder des choses que j'aurais
typiquement défini dans le code (Par exemple, dans le cas du
CurrencyConverter, la classe « CurrencyController »).
Si je vois bien l'exemple, IB ne fait que créer les fichiers .h et .m
avec la définition de la classe. Tu peux rajouter certaines définitions
d'outlet et d'action pour éviter des aller-retour avec Xcode, mais après
tu dois quand même passer par Xcode. Ca n'est qu'un moyen pour faciliter
la vie. Mais perso, je préfère définir d'abord dans Xcode, puis utiliser
la classe ainsi crééer dans IB.
En ce qui me concerne, la remarque que j'ai émise, c'était qu'il était surprenant de définir dans InterfaceBuilder des choses que j'aurais typiquement défini dans le code (Par exemple, dans le cas du CurrencyConverter, la classe « CurrencyController »).
Si je vois bien l'exemple, IB ne fait que créer les fichiers .h et .m avec la définition de la classe. Tu peux rajouter certaines définitions d'outlet et d'action pour éviter des aller-retour avec Xcode, mais après tu dois quand même passer par Xcode. Ca n'est qu'un moyen pour faciliter la vie. Mais perso, je préfère définir d'abord dans Xcode, puis utiliser la classe ainsi crééer dans IB.
-- Frédéric Testuz <mailto:
lists
Frédéric Testuz wrote:
Si je vois bien l'exemple, IB ne fait que créer les fichiers .h et .m avec la définition de la classe. Tu peux rajouter certaines définitions d'outlet et d'action pour éviter des aller-retour avec Xcode, mais après tu dois quand même passer par Xcode. Ca n'est qu'un moyen pour faciliter la vie. Mais perso, je préfère définir d'abord dans Xcode, puis utiliser la classe ainsi crééer dans IB.
Tu instanties aussi la classe depuis IB. Que les fenêtres et les boutons soient alloués automatiquement, ça n'est pas nouveau. Même du temps de MacOS pré-X, si on chargeait une ressource MBAR, les ressources MENU idoines étaient chargées automatiquement, si on utilisait une ressources DLOG ou ALRT, les contrôles qui le/la constituaient étaient créés automatiquement.
En revanche, définir une classe (qui semble pouvoir être tout à fait quelconque) et instantier des objets (non graphiques) directement avec IB, c'est assez nouveau pour moi.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
Si je vois bien l'exemple, IB ne fait que créer les fichiers .h et .m
avec la définition de la classe. Tu peux rajouter certaines définitions
d'outlet et d'action pour éviter des aller-retour avec Xcode, mais après
tu dois quand même passer par Xcode. Ca n'est qu'un moyen pour faciliter
la vie. Mais perso, je préfère définir d'abord dans Xcode, puis utiliser
la classe ainsi crééer dans IB.
Tu instanties aussi la classe depuis IB.
Que les fenêtres et les boutons soient alloués automatiquement, ça n'est
pas nouveau. Même du temps de MacOS pré-X, si on chargeait une ressource
MBAR, les ressources MENU idoines étaient chargées automatiquement, si
on utilisait une ressources DLOG ou ALRT, les contrôles qui le/la
constituaient étaient créés automatiquement.
En revanche, définir une classe (qui semble pouvoir être tout à fait
quelconque) et instantier des objets (non graphiques) directement avec
IB, c'est assez nouveau pour moi.
--
R: Parce que ça renverse bêtement l'ordre naturel de lecture!
Q: Mais pourquoi citer en fin d'article est-il si effroyable?
R: Citer en fin d'article
Q: Quelle est la chose la plus désagréable sur les groupes de news?
Si je vois bien l'exemple, IB ne fait que créer les fichiers .h et .m avec la définition de la classe. Tu peux rajouter certaines définitions d'outlet et d'action pour éviter des aller-retour avec Xcode, mais après tu dois quand même passer par Xcode. Ca n'est qu'un moyen pour faciliter la vie. Mais perso, je préfère définir d'abord dans Xcode, puis utiliser la classe ainsi crééer dans IB.
Tu instanties aussi la classe depuis IB. Que les fenêtres et les boutons soient alloués automatiquement, ça n'est pas nouveau. Même du temps de MacOS pré-X, si on chargeait une ressource MBAR, les ressources MENU idoines étaient chargées automatiquement, si on utilisait une ressources DLOG ou ALRT, les contrôles qui le/la constituaient étaient créés automatiquement.
En revanche, définir une classe (qui semble pouvoir être tout à fait quelconque) et instantier des objets (non graphiques) directement avec IB, c'est assez nouveau pour moi.
-- R: Parce que ça renverse bêtement l'ordre naturel de lecture! Q: Mais pourquoi citer en fin d'article est-il si effroyable? R: Citer en fin d'article Q: Quelle est la chose la plus désagréable sur les groupes de news?
testuz73
Julien Salort wrote:
Frédéric Testuz wrote:
Si je vois bien l'exemple, IB ne fait que créer les fichiers .h et .m avec la définition de la classe. Tu peux rajouter certaines définitions d'outlet et d'action pour éviter des aller-retour avec Xcode, mais après tu dois quand même passer par Xcode. Ca n'est qu'un moyen pour faciliter la vie. Mais perso, je préfère définir d'abord dans Xcode, puis utiliser la classe ainsi crééer dans IB.
Tu instanties aussi la classe depuis IB. Que les fenêtres et les boutons soient alloués automatiquement, ça n'est pas nouveau. Même du temps de MacOS pré-X, si on chargeait une ressource MBAR, les ressources MENU idoines étaient chargées automatiquement, si on utilisait une ressources DLOG ou ALRT, les contrôles qui le/la constituaient étaient créés automatiquement.
En revanche, définir une classe (qui semble pouvoir être tout à fait quelconque) et instantier des objets (non graphiques) directement avec IB, c'est assez nouveau pour moi.
La définition de la classe par IB est alternative. IB peut très reprendre une classe déjà définie. Par contre tu as raison pour l'instantiation (???? ça existe çe mot), on peut faire instantier des objets lors du chargement du .nib qui ne sont pas graphiques.
Si je vois bien l'exemple, IB ne fait que créer les fichiers .h et .m
avec la définition de la classe. Tu peux rajouter certaines définitions
d'outlet et d'action pour éviter des aller-retour avec Xcode, mais après
tu dois quand même passer par Xcode. Ca n'est qu'un moyen pour faciliter
la vie. Mais perso, je préfère définir d'abord dans Xcode, puis utiliser
la classe ainsi crééer dans IB.
Tu instanties aussi la classe depuis IB.
Que les fenêtres et les boutons soient alloués automatiquement, ça n'est
pas nouveau. Même du temps de MacOS pré-X, si on chargeait une ressource
MBAR, les ressources MENU idoines étaient chargées automatiquement, si
on utilisait une ressources DLOG ou ALRT, les contrôles qui le/la
constituaient étaient créés automatiquement.
En revanche, définir une classe (qui semble pouvoir être tout à fait
quelconque) et instantier des objets (non graphiques) directement avec
IB, c'est assez nouveau pour moi.
La définition de la classe par IB est alternative. IB peut très
reprendre une classe déjà définie. Par contre tu as raison pour
l'instantiation (???? ça existe çe mot), on peut faire instantier des
objets lors du chargement du .nib qui ne sont pas graphiques.
Si je vois bien l'exemple, IB ne fait que créer les fichiers .h et .m avec la définition de la classe. Tu peux rajouter certaines définitions d'outlet et d'action pour éviter des aller-retour avec Xcode, mais après tu dois quand même passer par Xcode. Ca n'est qu'un moyen pour faciliter la vie. Mais perso, je préfère définir d'abord dans Xcode, puis utiliser la classe ainsi crééer dans IB.
Tu instanties aussi la classe depuis IB. Que les fenêtres et les boutons soient alloués automatiquement, ça n'est pas nouveau. Même du temps de MacOS pré-X, si on chargeait une ressource MBAR, les ressources MENU idoines étaient chargées automatiquement, si on utilisait une ressources DLOG ou ALRT, les contrôles qui le/la constituaient étaient créés automatiquement.
En revanche, définir une classe (qui semble pouvoir être tout à fait quelconque) et instantier des objets (non graphiques) directement avec IB, c'est assez nouveau pour moi.
La définition de la classe par IB est alternative. IB peut très reprendre une classe déjà définie. Par contre tu as raison pour l'instantiation (???? ça existe çe mot), on peut faire instantier des objets lors du chargement du .nib qui ne sont pas graphiques.
