Mes petites questions de débutants
JoJoS
Membre
Bonjour, Bonjour !!!
J'aimerais vous posez quelques questions...
Je me "remet" au développement Cocoa / Obj-c après 5 mois pendant lesquels je n'avais plus d'ordi jusqu'à l'arrivé de mon messie : le livreur tnt qui m'a déposer mon iMac !!.
1)
Je voudrais savoir pourquoi mes applications, une fois que l'on ferme la fenêtre principale par la "bubble rouge" de fermeture, il m'est impossible de ré-ouvrir cette fenêtre ??
L'application tourne toujours, mais je n'ai aucun moyen d'afficher à nouveau ma fenêtre. Je viens tout juste de constater ce problème (qui se retrouve d'ailleurs sur une ancienne appli...).
Il me semble pourtant avoir lu, je ne sais plus où dans la doc d'apple, que le fait de cliquer sur l'icône de l'application dans le Dock affichait obligatoirement une fenêtre (un document si "document-based", la "main-frame" sinon...).
Et en effet, cela fonctionne très bien en créant une application de type "document-based"...
2)
Ma deuxième question n'a rien à voir du tout avec la première. En faite, je me la pose à cause de ce fichu livre "Cocoa par la pratique" que, apparemment, beaucoup possède. (Il faut dire que c'est le seul dispo en français...).
Mon problème survient au chapitre 5, exercice 2, quand il est demander de permettre la suppression de plusieurs lignes... Je n'arrive pas à trouver la solution...
Voilà un petit énoncer pour ceux qui n'auraient pas le livre :
Permettre la suppression de plusieurs lignes d'un NSTableView.
Pour cela, l'auteur nous informe la présence de la méthode selectedRowEnumerator qui renvoit une énumération d'index des lignes sélectionnées.
Comme un bleu, j'ai fait une boucle sur les éléments de l'énumération, et je supprime chaque ligne suivant l'index que j'obtiens. Mais comme prévu, ça plante car problème d'index hors tableau...
Bref je bloque... :-\\ Si quelqu'un aurait une solution ?
Par contre j'ai lu dans la doc que cette méthode était dépréciée depuis 10.3, et qu'il fallait désormais utiliser selectedRowIndexes...
Mais c'est encore pire... Je ne comprends pas comment faire non plus avec un NSIndexSet.
D'ailleurs, je n'arrive pas à comprendre comment manipuler un NSIndexSet.
Merci !!!
J'aimerais vous posez quelques questions...
Je me "remet" au développement Cocoa / Obj-c après 5 mois pendant lesquels je n'avais plus d'ordi jusqu'à l'arrivé de mon messie : le livreur tnt qui m'a déposer mon iMac !!.
1)
Je voudrais savoir pourquoi mes applications, une fois que l'on ferme la fenêtre principale par la "bubble rouge" de fermeture, il m'est impossible de ré-ouvrir cette fenêtre ??
L'application tourne toujours, mais je n'ai aucun moyen d'afficher à nouveau ma fenêtre. Je viens tout juste de constater ce problème (qui se retrouve d'ailleurs sur une ancienne appli...).
Il me semble pourtant avoir lu, je ne sais plus où dans la doc d'apple, que le fait de cliquer sur l'icône de l'application dans le Dock affichait obligatoirement une fenêtre (un document si "document-based", la "main-frame" sinon...).
Et en effet, cela fonctionne très bien en créant une application de type "document-based"...
2)
Ma deuxième question n'a rien à voir du tout avec la première. En faite, je me la pose à cause de ce fichu livre "Cocoa par la pratique" que, apparemment, beaucoup possède. (Il faut dire que c'est le seul dispo en français...).
Mon problème survient au chapitre 5, exercice 2, quand il est demander de permettre la suppression de plusieurs lignes... Je n'arrive pas à trouver la solution...
Voilà un petit énoncer pour ceux qui n'auraient pas le livre :
Permettre la suppression de plusieurs lignes d'un NSTableView.
Pour cela, l'auteur nous informe la présence de la méthode selectedRowEnumerator qui renvoit une énumération d'index des lignes sélectionnées.
Comme un bleu, j'ai fait une boucle sur les éléments de l'énumération, et je supprime chaque ligne suivant l'index que j'obtiens. Mais comme prévu, ça plante car problème d'index hors tableau...
Bref je bloque... :-\\ Si quelqu'un aurait une solution ?
Par contre j'ai lu dans la doc que cette méthode était dépréciée depuis 10.3, et qu'il fallait désormais utiliser selectedRowIndexes...
Mais c'est encore pire... Je ne comprends pas comment faire non plus avec un NSIndexSet.
D'ailleurs, je n'arrive pas à comprendre comment manipuler un NSIndexSet.
Merci !!!
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ou alors tu procèdes à l'envers, tu supprimes d'abord le dernier, puis ensuite le précédent, jusqu'au premier. Les index à supprimer ne seront donc pas changer. Pour NSIndexSet, avec la deuxième technique, tu dois utiliser pour l'initialisation -[NSIndexSet lastIndex] puis la méthode -[NSIndexSet indexLessThanIndex:] sachant que ces méthodes retournent NSNotFound s'il n'y a plus rien, tu peux utiliser ça comme condition de sortie.
Voilà ce que ça peut donner :
Voilà ...
Tu as dû mal lire... D'ailleurs pour les "document-based" on peut désactiver cette création de document vide automatique.
Pour réafficher la fenêtre quand l'application devient active, il faut implémenter "applicationWillBecomeActive" ou "applicationDidBecomeActive" dans le delegate de l'application (ou gérer ça avec les notifications "NSApplicationWillBecomeActiveNotification", "NSApplicationDidBecomeActiveNotification")
Faut traiter la liste à l'envers... (cf. "reverseObjectEnumerator", c'est la méthode la plus efficace)
"selectedRowIndexes"
Puis "removeObjectsAtIndexes" de NSMutableArray
En 1 ligne...
Même une seule ligne :
[EDIT] grillé...
Cool merci !! Je n'avais même pas vu cette méthode !!!
Du coup ça simplifie grandement le problème !
Arf, j'ai du mal comprendre ce que je lisais...
Donc c'est tout à fait normal que mon appli ne se ré-ouvre pas.
Si j'ai bien compris, je dois implementer la méthode delegate applicationWillBecomeActive de la manière suivante :
??
Bon, je test ces modifications ce soir !
Merci !!
Super, ca fonctionne niquel pour removeObjectsAtIndexes !!
Par contre je n'ai pas encore tester pour l'ouverture de la fen
Les NSLog que l'on met un peu partout, est ce qu'ils sont supprimés lors de la compilation en mode release ou ils restent dans le code et c'est à nous de les supprimer ?
(Normalement il y a une suite ici... Mais j'ai l'impresson que Safari 3 version Windaube ne veut pas l'afficher... Ca fait déjà 3 fois que je le réecris, donc j'abandonne, tant pis pour la suite...)
Ca reste en Release et ça écrit dans console.log
Une petite discussion intéressante à ce sujet :
http://www.objective-cocoa.org/forum/index.php/topic,2172.0.html
+
Chacha
C'est tout de même dommage qu'il n'y ai rien de prévue. Il me semble qu'en .net il y a un objet Debug qui permet l'écriture sur la console uniquement en mode debug.
J'ai encore une question :
Peut on utiliser les tableaux c ???
Parce que j'ai essayer cela : int[] et ça ne fonctionne pas.
Bon, en réfléchissant un peu j'ai trouvé cela logique puisque les [ sont la pour les messages.
Je ne suis pas hyper calé en c, mais il me semble que l'on peut également déclarer un tableau de cette façon : int*
Mais dans ce cas, comment l'initialiser, et l'interroger ??
En tout cas, merci beaucoup pour votre aide !!!
ps: j'ai oublié de préciser dans les signature de méthodes...
Ca devrait mieux marcher.
Tout le C, sans exception, je crois, fonctionne en ObjC.
Par exemple, dans Xcode, tu ouvres un inspécteur de ton projet, (commande + option + I) tu cliques sur Build, tu choisis la configuration Debug et tu recherches "Preprocessor".
Tu devrais avoir quelque chose du genre "Preprocessor Macros", écrit simplement DEBUG dedans.
Ensuite, dans ton code, tu fais un fichier MyDefines.h où tu mettras tes macros de debug. Pour intégrer NSLog tu peux par exemple mettre :
Si tu ne mets pas les points de suspension ça ne marchera pas, puisque NSLog() peut prendre un nombre infini de paramètres.
Avec ce code que je t'ai donné au-dessus, tu pourras écrire ceci dans ton code :
Pour afficher la méthode appelée et la classe de l'objet qui a reçu le message. Après le passage du préprocesseur en mode DEBUG tu auras le code normal :
En mode Release tu auras simplement ceci :
Ce qui ne pose aucun problème au compilateur, tu peux donc faire des appels à NSLog() de façon à avoir toutes les informations que tu souhaites lors du débogage sans pour autant surcharger l'application en mode normal.
En ce qui concerne les tableaux. Objective-C est un stricte surensemble du C, donc tout ce qui est possible en C est possible en Objective-C. Le compilateur fait très bien la différence entre un appel de message : [receveur message] et un tableau : int tab[5], et heureusement d'ailleurs !
À mon avis tu t'es simplement trompé dans l'écriture de ton tableau. Pour finir, oui on peut "remplacer" un tableau d'entier par un pointeur sur entier, dans le premier cas il s'agira d'un tableau statique, dans le deuxième cas ce sera plutôt un tableau dynamique.
Donc dans la signature d'une méthode c'est le même principe qu'en C pour les fonctions. Tu peux mettre un tableau en paramètre mais tu ne peux pas retourner de tableau.
À la définition d'un tableau, soit tu ne précises pas la taille et tu le remplis, soit tu précises la taille.
Y a un problème là , tu zappes tous les arguments optionnels, non ?
J'aurais dit :
C'est quand même génial ces instructions que l'on peut donner au preprocesseur !
Par contre c'est étrange pour les tableaux...
Mon erreur erreur venait certainement de là : - (int[])methode; // faux
Donc si j'ai bien compris, il faut une signature comme cela : - (int*)methode;
Bin en fait, j'ai une classe qui a des attributs qui sont des tableaux de int.
Mais je ne sais pas à l'avance la taille des ces tableaux.
Si tu le dis...
Moi j'ai préprocessé ça :
Et j'obtiens ça :
Mais bon, je dis ça, je dis rienÂ
Si "__VA_ARGS__" existe, c'est pas pour rien... ???
[Edit] Bon, évidemment, quand je rajoute __VA_ARGS__, ça ne passe qu'au préprocess, la compilation ne se fait pas, parce que [self class]Â dans le main... :P
Et là t'auras be beaux NSLog() rien que pour le debug.
http://www.objective-cocoa.org/forum/index.php/topic,2172.0.html
Et je reporte encore votre attention sur __FILE__ et __LINE__, vraiment super pratique pour savoir retrouver immédiatement où a eu lieu un log :P
Par exemple :
<br />
(houlà , pas testé, j'espère que ça fonctionne )
Vous les trouvez où ces variables du preprocesseur ?? (__VA_ARGS__, __FILE__, ...).
Pour ce qui est de ##, chez moi j'en ai pas besoin, et le mettre ne change rien... ça signifie la concaténation de deux chaà®nes... Mais l'intérêt je vois pas.
Elles sont inscrites dans la norme du langage C
C'est plutôt spécifique à GCC non?