›

Application Controller

LeLaidLeLaid Membre
08:17 modifié dans API AppKit #1
Salut à  vous,

Je suis occupé à  faire quelques tutoriels trouvé sur ce forum. La plus part des tutos sont basés sur xcode 2 alors que je suis sur xcode 3. Je suis donc parfois un peu perdu (je parviens en général quand même à  trouver le chemin...).

J'ai une question super basique. Comme je suis dans le coin débutant... je me lance  :fouf):

J'ai un peu de mal à  comprendre ce qu'est un app controller  :o   :-\\

Quand je suis le tuto Cacao, je comprends bien (sous xcode 2) que l'objet CacaoControl est mon controleur. On le construit dans un onglet "class" sous IB 2 mais cet onglet n'existe pas sous IB 3 (ou du moins je ne l'ai pas trouvé).

Je ne vois pas bien où sous IB 3 je peux créer ce controler.

Pour m'en soritir j'ai créer le controler via l'identity inspector au niveau de la NSWindow. J'ai ensuite remis "NSWindow" comme class pour la window.....

Bref, ça me parraà®t un peu scabreux (mais ça marche).

Pascal

Réponses

  • Philippe49Philippe49 Membre
    08:17 modifié #2
    dans 1235559614:

    J'ai un peu de mal à  comprendre ce qu'est un app controller  :o   :-\\


    Toute entreprise a besoin d'un patron.
    Dans une appli simple, on dédie ce rôle à  un objet .
    Dans une appli plus riche on peut démultiplier ce Contrôleur général en plusieurs étages (Application Delegate, ViewController, NSDocument, ...)

    dans 1235559614:

    Je ne vois pas bien où sous IB 3 je peux créer ce controler.


    Tu prends un cube bleu dans la library, et tu le mets dans la fenêtre pricipale d'IB.
    Ensuite tu règles sa classe.
    Lors du désarchivage du nib, l'objet sera créé, ainsi que les connections qui auront été faites dans IB 
  • LeLaidLeLaid Membre
    08:17 modifié #3
    Ah, ok!
    Je croyais que le cube bleu était une instance de la classe en question....
    Donc, le cube peut être à  la fois une instance et la classe elle même? Je dois en avoir deux (cubes) pour le controller? Un pour la classe et l'autre pour l'instance de la classe?

    Pascal
  • Philippe49Philippe49 Membre
    08:17 modifié #4
    dans 1235560451:

    Ah, ok!
    Je croyais que le cube bleu était une instance de la classe en question....
    Donc, le cube peut être à  la fois une instance et la classe elle même? Je dois en avoir deux (cubes) pour le controller? Un pour la classe et l'autre pour l'instance de la classe?

    Pascal

    Non, un seul cube bleu , la classe est initialisée par les fichiers existant dans XCode.

    Donc
    1) Créer les fichiers de ta classe CacaoControl.h et CacaoControl.m  dans ton projet XCode, XCode notifie alors automatiquement l'existence de ces classes à  Interface Builder.
    2) Dans IB amener un cube bleu et lui attribuer la classe CocoaControl dans l'inspecteur.


    remarque : on peut également créer les classes dans IB , mais bon ... peut-être pour plus tard.
  • AliGatorAliGator Membre, Modérateur
    08:17 modifié #5
    Non non tu avais bien compris, un "cube bleu" dans IB c'est bien une instance de ta classe et pas la classe elle-même.
    Mais quand on fait comme te l'a dit philippe ensuite, à  savoir qu'on va dans l'inspecteur dans IB et qu'on modifie la classe de ce cube bleu (de cette instance) pour remplacer le "NSObject" par défaut par un truc perso genre "MaClasseAMoi", ça ne crée pas la classe à  proprement parler, ça change juste la classe de ton instance, de ton cube bleu donc.

    La classe, elle, est définie dans Xcode par les fichiers MaClasseAMoi.h et MaClasseAMoi.m... fichiers que tu peux au passage demander à  IB de te créer, du moins de te créer des bases/modèles pour ces fichiers qu'il te restera plus qu'à  compléter (sélectionner le cube bleu pour lequel tu as indiqué la classe et choisir dans le menu File -> Write Files..." pour générer les fichiers .h et .m de la classe correspondante)
  • tabliertablier Membre
    08:17 modifié #6
    Si vous continuez comme cela, je vais me sentir obligé de mettre à  jour le tutoriel.
    Il est vrai que si les principes restent (classe -> instanciation), la présentation de IB et sa méthodologie ont bien evolué! Il y a même des fois ou je m'y perds!
      :-\\ Bon faut que j'y réflechisse car reprendre ça c'est un gros boulot!
  • LeLaidLeLaid Membre
    08:17 modifié #7
    dans 1235587785:

    Si vous continuez comme cela, je vais me sentir obligé de mettre à  jour le tutoriel.
    Il est vrai que si les principes restent (classe -> instanciation), la présentation de IB et sa méthodologie ont bien evolué! Il y a même des fois ou je m'y perds!
      :-\\ Bon faut que j'y réflechisse car reprendre ça c'est un gros boulot!


    Je suis preneur  :o

    Bon, je crois que je comprends 
    Merci pour vos réponses.

    Pascal
    PS. Ce site est vraiment top.
  • LeLaidLeLaid Membre
    08:17 modifié #8
    Hum, tant que j'y suis j'ai une autre question en relation avec ce super tuto (merci tablier):

    Je ne comprends pas pourquoi on crée des outlets o_Convertir, o_Sortir et o_Version.
    En effet, pourquoi ne pas appliquer la méthode a_Convertir directement sur self? Comme ceci (ça marche):

    - (IBAction)a_Convertir:(id)sender <br />{<br />&nbsp; &nbsp; float total, rate, dollr;<br />	BOOL rz;<br />	int nbr;<br />	<br />	rate = [o_Taux floatValue];<br />	dollr = [o_Dollar floatValue];<br />	rz = [o_Raz state];<br />	nbr = [o_Coef selectedRow];<br />	<br />	total = [self LaCOnversion: dollr atRate: rate zero: rz Coref: nbr];<br />	<br />	[o_Euro setFloatValue: total];<br />	[o_Dollar selectText: self];<br />}


    (pour rappel LaConversion renvoie un float)..

    Et faire de même avec Sortir et version...

    Pascal
Connectez-vous ou Inscrivez-vous pour répondre.