comment passer une instance à une autre classe (toujours sans IB)
bofy
Membre
Bonjour
J'arrive à faire à peu près ce que je veux, mais j'ai l'impression que mon code est une horreur du point de vue MVC (merci NO ...).
Dans ce que je pense être une View vivi, je définis un bouton, dont l'action est de remplir un textfield fifi par une valeur par défaut. La méthode correspondant à cette action est dans une classe toto. Problème : il faut que l'instance de la classe toto ait connaissance de fifi. Je ne sais pas comment passer fifi à toto ? A moins de déclarer vivi dans toto et réciproquement, ce qui me paraà®t peu orthodoxe.
En C, pas de problème, les variables globales font ça très bien. Mais en O-C c'est une hérésie, alors comment faire ?
En fait, j'aimerais bien savoir comment IB implante les outlets, qui semblent la solution à mon problème ?
J'arrive à faire à peu près ce que je veux, mais j'ai l'impression que mon code est une horreur du point de vue MVC (merci NO ...).
Dans ce que je pense être une View vivi, je définis un bouton, dont l'action est de remplir un textfield fifi par une valeur par défaut. La méthode correspondant à cette action est dans une classe toto. Problème : il faut que l'instance de la classe toto ait connaissance de fifi. Je ne sais pas comment passer fifi à toto ? A moins de déclarer vivi dans toto et réciproquement, ce qui me paraà®t peu orthodoxe.
En C, pas de problème, les variables globales font ça très bien. Mais en O-C c'est une hérésie, alors comment faire ?
En fait, j'aimerais bien savoir comment IB implante les outlets, qui semblent la solution à mon problème ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
toto est apparemment ton contrôleur ; il faut qu'il soit instancié dans le .nib, et qu'il ait des outlets effectivement pour pouvoir papoter avec eux.
Comme dit Schlum, toto est ton controller. Un controller, cela contrôle, et doit donc définir à la fois vivi, fifi, (et pourquoi pas loulou ?) .
Je confirme cette invitation !
La dernière version (en Américain) est encore mieux que les précédentes.
Un IBOutlet, c'est une simple référence par pointeur
@interface vivi : NSView {
IBOutlet NSTextField * fifi;
}
signifie que la variable d'instance fifi de vivi contient l'adresse du NSTextField. Rien de plus.
Si vivi connaà®t toto , toto connaà®t fifi , fifi connaà®t riri, riri connaà®t loulou, alors vivi connaà®t loulou à l'aide de valueForKey.
vivi --> toto --> fifi --> riri --> loulou
Raz le bol. Vous êtes payés pour faire la pub de Hillegrass ou quoi ?
Hillegrass fonctionne exclusivement avec IB, du moins pour les choses importantes, pour le reste c'est une paraphrase de la doc des classes Cocoa. Comme qui disait, mieux vaut l'original. J'ai son bouquin à côté de moi en permanence. Et en dehors d'un détail, il ne m'a jamais rien apporté.
Merci Eaglelouk : mais des petits (et des gros projets), j'en ai à revendre et qui marchent...
Désolé de ce mouvement d'humeur. J'essaie de construire mon application sur MVC, et ce n'est pas aussi simple que le "convertisseur de monnaie" le laisse entendre. Bon, j'y arriverai. Pour l'instant je suis sur la piste de property.
Bien à tous
Et désolé si certains passages dans ton post laissent à penser que tu n'y a rien compris et que tu devrais le relire... :P
" Dans ce que je pense être une View "
" j'aimerais bien savoir comment IB implante les outlets "
Un .nib c'est rien qu'un archiveur d'instances ; il contient une collection d'objets instanciés, et les liens (outlets, actions) entre eux et avec les singletons ou first responders (NSApp, NSDocuments etc.)
Il n'y a rien de compliqué dans le fonctionnement d'un .nib
Si tu veux, c'est un peu comme si tu avais un NSArray d'instances (NSWindow win, NSButton button, Controller controller...), et un autre NSArray de liens (win's delegate = controller, button's target = controller, button's action = selector blabla of controller, controller's window outlet = win...)
Mais je l'ai relu 1 ou 2 ans plus tard, pendant ce temps j'avais fait que des tutos. Et là c'est beaucoup plus clair. N'empêche qu'on reste souvent sur sa première impression ;D
Mais bon si des projets t'en a... alors je comprend pas pourquoi tu pêches sur le modèle MVC cocoa.. c'est que t'as aucun projet en cocoa sous la main. C'est pour ça que je te dis de prendre un ptit projet cocoa de rien du tout et tu verras par toi même.
Mais faut pas en faire une montagne de IB, c'est qu'un archiveur ; ça ne fait qu'enregistrer des modèles tout faits qu'on peut faire à la main dans des fichiers pour les ressortir facilement derrière.
Bien sûr c'est faisable, mais avant de faire ça il faut peut-être essayer et maà®triser la réalisation de la recette de baba au rhum avec les ingrédients déjà prêts, maà®triser les proportions, le temps de cuisson, etc...
Une fois que tu maà®triseras tous les principes de cuisine qui vont bien, tu pourras te mettre à faire toi-même tes ingrédients à partir des matières premières, mais c'est p'tet pas la peine d'essayer d'aller trop vite en besogne...
Et personnellement je connais peu de monde parmi ceux qui aiment cuisiner (dont moi-même) qui font leur propres ingrédients à partir de leur matière première... et peu de bouquins de cuisine qui expliquent comment les faire lorsqu'ils expliquent la recette du baba au rhum... alors que c'est plus simple et tout aussi plaisant et bon de prendre du sucre, beurre et rhum déjà fait...
---
Alors c'est pas étonnant non plus que peu de bouquins expliquent comment créer tout son projet Cocoa sans IB (et pourquoi pas sans Xcode) et que les bouquins qui expliquent à tout le monde comment faire une appli Cocoa comme ceux d'Hillegass ne t'expliquent pas les détails du fonctionnement sous-jacent d'un NIB, compliquant la choses pour les débutants, alors que c'est pour apprendre Cocoa par la pratique et que tout le monde (à part toi) utilise les NIB puisqu'ils sont faits pour ça et pour faciliter la vie...
Et puis ouais, t'as raison, ras le bol.... d'ailleurs pourquoi tu utilises Xcode et Cocoa tant que tu y es ? C'est vrai, on ne sais pas trop ce qu'il y a sous les méthodes Cocoa non plus, tu devrais préférer les refaire toi-même pour comprendre ce qu'il y a dessous...
Plus sérieusement, je veux bien qu'on cherche à comprendre comment ça marche "sous le capot", mais faut p'tet savoir conduire avant, non ? Si tu as du mal à identifier le contrôleur et comment fonctionnent les IBOutlet, c'est qu'il manque encore p'tet un peu de pratique, non ? Faut p'tet bien maà®triser IB et son fonctionnement avant d'essayer de faire sans ?
Soyons clair : "toto contrôle".
@interface TotoClass : ??
{
  NSView * vivi;
  NSTextField * fifi;
  NSButton * button;
}
-(void) initMyViews;
-(void) initMyActions;
-(void) doSomething:(id) sender;
@end
@implementation TotoClass
-(id) init {
  self=[super init];
  if(self != nil) {
    [self initMyViews];
    [self initMyActions];
  }
-(void) initMyViews{
   NSRect viviRect=NSMakeRect(0.,0.,200.,200.);
   vivi=[[NSView alloc] initWithFrame:viviRect];
   NSWindow * mainWindow=[NSApp mainWindow];
   [[mainWindow contentView] addsubview:vivi];
 // idem avec les textField et le bouton
}
-(void) initMyActions {
   [button setTarget:self];
   [button setAction:@selector(doSomething
   // autres actions ...
}
-(void) doSomething:(id) sender {
  // au choix
}
Raison de plus pour comprendre déjà comment fonctionne IB & Xcode entre eux :fouf):
Je ne pense pas que ça soit très MVC de faire créer la vue par le contrôleur :P
ça serait plutôt à une instance au-dessus d'initialiser le modèle, la vue et le contrôleur, depuis l'intialisation d'un singleton...
Oui bon, mais j'ai quand même l'impression ici qu'il ne faut pas faire trop compliqué comme architecture. Alors dans un cas d'application simple, le contrôleur de l'application sert en même temps de contrôleur pour l'interface graphique. Sinon, il faudrait rajouter un étage ...
Comme Bofy veut faire sans nib, le moment de la mise en place de l'interface graphique reste indéterminé.