Débutant sur Xcode/Interf Build

yduc

Membre confirmé
2 Avril 2006
77
6
50
Paris
Bonjour,

je viens de faire mes premiers pas en Objective-C et en Cocoa grâce au tutoriel d'Apple. Prolongeant le convertisseur de devise créé à l'aide du tutoriel, j'ajoute un deuxième bouton "Conversion inversée" qui divise au lieu de multiplier. Surprise : lorsque dans IB je choisis le menu "Classes | Create Files for ConverterController", celui-ci écrase mon travail précédent !!! (après m'avoir averti, là n'est pas le problème)

J'hallucine.

IB n'est-il pas capable d'ajouter la nouvelle action créée dans le couple de fichiers .h et .m, sans perturber l'existant ? C'est un énorme handicap pour faire évoluer une interface... Y a-t-il une astuce qui m'a échappé ?

Ensuite, et toujours dans le prolongement du tutoriel, je tente de faire en sorte que la conversion intervienne automatiquement :
- lorsqu'on quitte un champ (méthode 1),
- lorsqu'on change une valeur (méthode 2).
Je n'y parviens pas. Lorsque je tente de connecter le NSTextField à l'action "convert" de mon contrôleur (ConverterController), les éléments disponibles côté NSTextField sont delegate, formatter, menu et nextKeyView (ce dernier étant déjà connecté). Pas de "exitField" ni de "fieldChanged". De même, au niveau fenêtre, pas d'élément "keyField" qui pourrait m'indiquer que le champ actif a changé.

Du côté des Bindings (Pomme-4 dans la palette Info), là non plus je ne vois rien qui ressemble. Les bindings proposent bien la "value", qui peut convenir à ma méthode 2 (??), mais pas la sortie de champ (pour la méthode 1).

Comment faire ?

Merci de votre aide.

Yves
 
yduc a dit:
Bonjour,


Ensuite, et toujours dans le prolongement du tutoriel, je tente de faire en sorte que la conversion intervienne automatiquement :
- lorsqu'on quitte un champ (méthode 1),
- lorsqu'on change une valeur (méthode 2).
Je n'y parviens pas. Lorsque je tente de connecter le NSTextField à l'action "convert" de mon contrôleur (ConverterController), les éléments disponibles côté NSTextField sont delegate, formatter, menu et nextKeyView (ce dernier étant déjà connecté). Pas de "exitField" ni de "fieldChanged". De même, au niveau fenêtre, pas d'élément "keyField" qui pourrait m'indiquer que le champ actif a changé.


Comment faire ?

Merci de votre aide.

Yves

Regarde du coté des méthodes déléguées:

Text delegate methods
– textShouldBeginEditing:
– textDidBeginEditing:
– textDidChange:
– textShouldEndEditing:
– textDidEndEditing:
 
Sur le premier point, j'ai finalement trouvé dans la doc Apple une réponse explicite à ma question : il n'y a pas d'astuce. Interface Builder génère les fichiers .h et .m des classes à la création ; c'est tout. Les évolutions sont à faire à la main dans Xcode, puis ne pas oublier de faire "Read Files..." aussitôt après dans IB, pour le synchroniser.

Inversement, s'il n'y a pas encore de code perso dans le .m et que l'on choisit de faire re-générer les fichiers par IB, il faut forcer Xcode à les recharger car celui-ci ne se rend pas compte que les fichiers ont changé ! (si on enregistre, on écrase ce qu'a fait IB)

mpergand a dit:
Regarde du coté des méthodes déléguées:
Sur le deuxième point, je m'amuse beaucoup car il y a une débauche de concepts savants pour reproduire ce qui serait en C un simple pointeur sur fonction... Mais trêve d'ironie, je suis néanmoins parvenu à faire transmettre par un objet visuel une notification à l'objet délégué. Mais ça ne marche pas tout à fait :
1 - je réussis à intercepter les notifications de la fenêtre,
2 - je n'y parviens pas pour les NSTextField (indiquées par mpergand),
3 - par contre, j'y parviens au travers de NSControl.

Autrement dit :
1 - - (BOOL)windowShouldClose:(id)sender; fonctionne,
2 - - (void)textDidChange:(NSNotification *)aNotification; ne fonctionne pas,
3 - - (void)controlTextDidChange:(NSNotification *)aNotification; fonctionne.
Pourtant, tous mes NSTextField (ainsi que la fenêtre elle-même) ont la même connexion pour leur outlet "delegate", à savoir le contrôleur de la fenêtre ("ConverterController"). Il y a là un mystère pour moi.

J'ai plusieurs autres petites questions mais je vais essayer de trouver par moi-même... ;-)

Enfin, j'ajoute que non seulement Xcode plante, mais qu'il a aussi bousillé mon projet et sa propre aide en ligne. Je ne peux plus ouvrir ni l'un ni l'autre, même en supprimant le dossier "build". C'est certainement la première fois de ma vie que je vois ça... :-(

Sur ce, je vous quitte car je dois réinstaller Xcode !
Merci pour les tuyaux.

Yves

PS : Et je viens de perdre ma boîte e-mail !!! Mais peut-être qu'un redémarrage suffira, comme les fois précédentes.
Avant, je disais à tout le monde que j'avais un Mac pour éviter ce genre de tracas...
 
Salut,

Pour bien débuter en Cocoa, le premier conseil que je donnerais, c'est d'éviter, absolument, toutes références à d'autres environnement de programmation. Cocoa est vraiment particulier et essayer d'appliquer des pratiques/techniques apprises avec d'autres langages/environnements ne peut qu'engendrer erreurs et frustation.

Ensuite, il y a certains concepts fondamentaux qu'il faut bien assimiler:
- le principe Model-View-Controller
- la notion de delegate
- le Key Value Coding (KVC)

( Google est ton ami )


Pour le KVC, c'est ce mécanisme qui est à la base des Bindings (avec le Key Value Observing et le Key Value Binding).
C'est le KVC qui est aussi utilisé pour initialiser les Outlets définies dans IB, ex:

IBOutlet NSButton* monBouton;


Mais l'astuce, c'est que tu n'es pas obligé de définir une variable mais une méthode (un setter):
Bloc de code:
-(void) setMonButton:(id) object
{
  theButton=object;
}

Le principe est que si la variable monBouton n'est pas définie, une méthode du genre setNomDeVariable sera appelée, idem en lecture, la méthode (un getter) appelée sera alors:
Bloc de code:
-(id) monButton
{
  return theButton;
}


Bloc de code:
3 - - (void)controlTextDidChange:(NSNotification *)aNotification; fonctionne.

Oui, extact, d'ailleurs j'ai jamais rien compris à cette histoire:
About Delegate Methods
The NSControl class provides several delegate methods for its subclasses that allow text editing, such as NSTextField and NSMatrix. Note that although NSControl defines delegate methods, it does not itself have a delegate. Any subclass that uses these methods must have a delegate and the methods to get and set it.

Enfin, j'ajoute que non seulement Xcode plante, mais qu'il a aussi bousillé mon projet et sa propre aide en ligne. Je ne peux plus ouvrir ni l'un ni l'autre, même en supprimant le dossier "build". C'est certainement la première fois de ma vie que je vois ça... :-(

Une méthode souvent efficace, c'est de mettre le fichier des préférences d'Xcode à la poubelle.

Xcode a toujours été archi buggé, pour moi la version la plus stable est la 2.1

Pour en revenir au principe de la délégation, il est omni présent dans Cocoa (voir le WebKit) ; Le problème, je trouve, c'est que ça casse la hiérarchie des objets. A ce sujet, le concept des Adapters en java est plus puissant je trouve, car on peut faire, par ex:

Bloc de code:
class MonAdapter extends doSomethingAdapter
{
boolean shouldDoSomething()
  {
  if(someCondition)
     return true;

  return super.shouldDoSomething();
  }
}


En résumé, Cocoa est très puissant, à condition que le comportement standard soit adapté à ce que tu veux faire, sinon ça peut devenir la grosse galère (les bindings ?)

Même chose, si tu veux créer ton NSControl perso, en fait dans ce cas Apple n'a pas documenté les méthodes nécessaires (volontairement ?) pour que se soit simple, ex:
http://www.cocoadev.com/index.pl?MailStyleGradientSelection

Il faut donc utiliser des méthodes privées et non officiellement documentées (celles dont le nom commence par un _) :eek:
 
yduc a dit:
PS : Et je viens de perdre ma boîte e-mail
Bon, finalement un redémarrage a tout résolu ! Oufff. Néanmoins c'est la preuve, et pour rebondir sur la robustesse d'OS X en discussion dans "Utilisation InterfaceBuilder + Xcode", que l'étanchéité entre les applications et le système n'est pas parfaite, puisqu'en l'occurrence un plantage de Xcode a entraîné un mauvais fonctionnement de Mail. En d'autres occasions, j'avais déjà observé que le plantage d'une application, Safari par exemple, avait perturbé d'autres applications (Mail par ex.), voire le système lui-même et qu'il valait mieux redémarrer. Par exemple, après plantage de Safari, l'ouverture d'une application quelconque soit devenait extrêmement lent, soit produisait une roue multicolore "infinie" (icône rebondissant éternellement dans le Dock).

En conclusion, il va falloir reprendre l'habitude de redémarrer mon poste après un plantage, habitude que j'avais totalement perdue. :-(

Je ne suis pas loin de penser que depuis Mac OS X, en termes de qualité (c-à-d bugs et plantages) le Mac est redescendu à peu près au niveau de Windows. Ce qui leur vaut à tous les deux... un bêtisier sur mon site perso ! Pas de jaloux. ;-) ( http://yves.ducourneau.club.fr/povbill.htm )

Le choix d'un framework et d'un outil de développement n'est à mon avis pas neutre dans cet état de choses (pour revenir au thème de ce forum).


mpergand a dit:
il y a certains concepts fondamentaux qu'il faut bien assimiler:
- le principe Model-View-Controller
- la notion de delegate
- le Key Value Coding (KVC)
Merci pour ce cours.
Corrige-moi si je me trompe : concernant le M-V-C et le délégué, le principe n'est pas bien méchant. Le M-V-C consiste à dire qu'il faut une classe qui fasse l'interface entre les objets graphiques (fenêtres, boutons...) et le moteur. C'est évident ; tous les frameworks fonctionnent ainsi. Le délégué, lui, est spécifique à Cocoa et consiste à référencer un objet applicatif auprès de l'objet graphique. Ce n'est rien d'autre que la mise en pratique du principe précédent ! (M-V-C) En fait, à mon humble avis de débutant, la difficulté réside dans la mise en pratique de tout ça.
Concernant le KVC, là je n'ai pas encore lu la doc Apple. Je n'ai lu que l'intro et... je n'ai rien compris. ;-) Faudra remonter à l'assaut. ;-)

mpergand a dit:
Xcode a toujours été archi buggé
Purée !!! C'est rassurant... :-(

mpergand a dit:
Pour en revenir au principe de la délégation, [...] ça casse la hiérarchie des objets.
Oui mais est-ce choquant ? Je dérive l'objet bouton si j'ai l'intention de créer un bouton particulier, mais qui reste purement graphique. Mais je délègue l'objet bouton pour le connecter à mon application. Ce sont deux intentions bien distinctes. Le premier réflexe du programmeur objet est certes de dériver l'objet bouton dans les deux cas, mais est-ce bien conforme au modèle M-V-C ?
Je ne connais pas les adapteurs de Java mais ça revient à ma dernière question, non ?

mpergand a dit:
si tu veux créer ton NSControl perso, [...] Apple n'a pas documenté
Aïe aïe aïe... Cette possibilité me paraît pourtant essentielle ! A moins que l'on puisse suffisamment remanier les contrôles existants par d'autres voies ? (dérivation...) J'avais éventuellement besoin de cette fonctionnalité pour l'un de mes projets pharaoniques-que-je-ne-bouclerai-jamais. ;-)

Merci, à+.

Yves
 
Ce n'est rien d'autre que la mise en pratique du principe précédent ! (M-V-C) En fait, à mon humble avis de débutant, la difficulté réside dans la mise en pratique de tout ça.
En prog vaut mieux passer à la pratique assez rapidement :)

Concernant le KVC, là je n'ai pas encore lu la doc Apple. Je n'ai lu que l'intro et... je n'ai rien compris. ;-)
Le principe des setter/getter existe aussi en java et on utilise la réflection (voir les JavaBeans)


Aïe aïe aïe... Cette possibilité me paraît pourtant essentielle ! A moins que l'on puisse suffisamment remanier les contrôles existants par d'autres voies ? (dérivation...) J'avais éventuellement besoin de cette fonctionnalité pour l'un de mes projets pharaoniques-que-je-ne-bouclerai-jamais. ;-)

Ca dépend de ce que tu veux faire, ça peut être facile ou très galère, on en parle ICI ou encore LA
 
yduc a dit:
Bon, finalement un redémarrage a tout résolu ! Oufff. Néanmoins c'est la preuve, et pour rebondir sur la robustesse d'OS X en discussion dans "Utilisation InterfaceBuilder + Xcode", que l'étanchéité entre les applications et le système n'est pas parfaite, puisqu'en l'occurrence un plantage de Xcode a entraîné un mauvais fonctionnement de Mail. En d'autres occasions, j'avais déjà observé que le plantage d'une application, Safari par exemple, avait perturbé d'autres applications (Mail par ex.), voire le système lui-même et qu'il valait mieux redémarrer. Par exemple, après plantage de Safari, l'ouverture d'une application quelconque soit devenait extrêmement lent, soit produisait une roue multicolore "infinie" (icône rebondissant éternellement dans le Dock).

En conclusion, il va falloir reprendre l'habitude de redémarrer mon poste après un plantage, habitude que j'avais totalement perdue. :-(

Je ne suis pas loin de penser que depuis Mac OS X, en termes de qualité (c-à-d bugs et plantages) le Mac est redescendu à peu près au niveau de Windows. Ce qui leur vaut à tous les deux... un bêtisier sur mon site perso ! Pas de jaloux. ;-) ( http://yves.ducourneau.club.fr/povbill.htm )

Le choix d'un framework et d'un outil de développement n'est à mon avis pas neutre dans cet état de choses (pour revenir au thème de ce forum).
J'ai jamais constaté cela, après des années sur Mac OSX :nailbiting: Et pourtant XCode et Safari ont déjà crashé une paire de fois :siffle:
 
yduc a dit:
IB n'est-il pas capable d'ajouter la nouvelle action créée dans le couple de fichiers .h et .m, sans perturber l'existant ? C'est un énorme handicap pour faire évoluer une interface... Y a-t-il une astuce qui m'a échappé ?

Si, si c'est possible. Je trouve que xCode et Interface Builder ne sont pas très intégrés, mais voilà comment on fait:
- tu es obligé de faire Read File pour qu'IB prenne en compte les ajouts d'Outlets ou Actions que tu aurais fait dans ton code sous xCode. Tu peux aussi glisser le .h dans la fenêtre d'IB, ça doit marcher.
- Quand tu fais Create Files..., IB te propose normalement soit de remplacer le code existant, soit (en cliquant sur Merge) de le fusionner. Bref, c'est possible, dommage que le FileMerge soit aussi peu convivial.


Cocoa est un bon outil. IB est très bien. xCode est mauvais mais s'améliore grandement à chaque version... Bienvenue parmis nous!
 
ntx a dit:
J'ai jamais constaté cela, après des années sur Mac OSX. Et pourtant XCode et Safari ont déjà crashé
Pourtant, je "triture" très, très peu mon Mac et je me vante d'avoir en général des machines qui fonctionnent bien. Ainsi, au boulot c'est traditionnellement mon disque qui sert de miroir aux nouvelles machines.

Céroce a dit:
Je trouve que xCode et Interface Builder ne sont pas très intégrés, [...]
- tu es obligé de faire Read File
C'est bien ce que je craignais : ça repose sur ma vigilance...

Céroce a dit:
soit (en cliquant sur Merge) de le fusionner.
J'ai pas réussi. FileMerge a bien comparé les fichiers avant/après mais je n'ai pas réussi à lui faire enregistrer la réconciliation (et je ne savais pas qu'il en était capable). Faut que j'y retourne voir...

Céroce a dit:
xCode est mauvais mais s'améliore grandement à chaque version
Ça y est, j'ai compris : vous voulez me décourager... :)))
Bon sang, pourquoi Apple est-il si bon pour certaines choses et si contrasté pour d'autres ?

Yves
 
yduc a dit:
Ça y est, j'ai compris : vous voulez me décourager... :)))
Bon sang, pourquoi Apple est-il si bon pour certaines choses et si contrasté pour d'autres ?
Et encore tu n'as pas vu MPW apparemment ? Ca c'était du soft à la portée de M. Tout Le Monde :D :D :D
En fait il faut faire une différence entre les logiciels Apple pour le grand public et ceux pour les professionnels avertis, et XCode est plutôt dans la deuxième catégorie. Mais la doc est assez complète, il faut juste prendre le temps de la consulter quand on rencontre une difficulté.
 
yduc a dit:
J'ai pas réussi. FileMerge a bien comparé les fichiers avant/après mais je n'ai pas réussi à lui faire enregistrer la réconciliation (et je ne savais pas qu'il en était capable). Faut que j'y retourne voir...

Oui, il faut cliquer sur les flêches pour choisir le côté (droit, gauche ou les deux) à conserver, puis choisir dans le pop-up en bas à droite lequel tu conserves. Pas convivial du tout, je te disais.

L'équipe qui développe xCode se rend bien compte qu'il y a des problèmes généraux d'ergonomie, d'intégration et de stabilité. Il faut dire, que beaucoup de développeurs même aguéris le font remarquer à longueur de forums. Simplement, l'équipe semble très occupée par l'ajout de nouvelles fonctionnalités nécessaires aux nouveaux développements (comme CoreData), ce qui laisse moins de temps à l'amélioration globale du logiciel.
Perso, j'attends toujours, entre autres, des diagrammes de classes qui ressemblent à quelque chose, et un système de recherche dans la doc plus performant, pour éviter d'avoir recours à des logiciels externes comme AppKiDo.