Aller au contenu

Cocher une case à cocher


zekiller28
 Share

Messages recommandés

Hello !

 

j'arrive bien à déterminer l'état d'une case à cocher (merci la doc Apple :P ) mais je me demandais comment faire pour forcer une case à se cocher/décocher quand on appui sur un bouton…

 

J'ai bien entendu essayé ça :

 

([_case2 state]= NSOnState);

mais qui ne fonctionne pas…

Lien vers le commentaire
Partager sur d’autres sites

C'est bien c'est bien, tu commences à comprendre :P

 

Note quand même que les state des NSButton ne sont pas des boolean. Normalement tu utilises NSOnState, NSOffState et NSMixedState (et c'est marqué dans la doc :P).

Bon c'est quand même bien fait du côté d'Apple parce que le YES à la même valeur que NSOnState et le NO à la même valeur que NSOffState, donc ça marche quand même.

 

Screen Shot 2013-10-21 at 12.43.16.png

 

 

Note aussi que tu ne peut jamais attribuer de valeur à une méthode (sauf avec les subscriptings mais il convertis l'affectation en un setter).

Lien vers le commentaire
Partager sur d’autres sites

Ha oui c'est vrai que j'avais essayé la première fois de mettre le NSOnState (vu dans la doc) mais avec state (car j'ai réussi et déterminer l'état de mes cases à cocher avec state) et non pas setState et du coup lors de mes tests je suis resté à YES plutôt que NSOnState (je sais pas très bien pourquoi d'ailleurs)…

 

D'ailleurs c'est logique d'utiliser NSOnState et les 2 autres puisqu'il y a 3 états possibles donc en Boolean ça serait compliqué à gérer… Déjà bien sympa d'accepter le YES et le NO (j'imagine que le TRUE et le FALSE fonctionnent aussi, mais j'essaye de me soigner de RB :zz-big-bien: )

Lien vers le commentaire
Partager sur d’autres sites

En Objective-C (et dans bien d'autre langage), l'accès aux variables/propriétés/attribues (ça dépends des langages) de fait par des getter/setter.

Pour une question de sécurité et d'intégrité.

Bien que pour Objective-C, l'accès via des getter/setter (<=> les accesseurs et les mutateurs), soit une obligation (me corriger si je me trompe) car les variables sont toutes confinées dans l'instances de l'objet (ou de la classe, mais uniquement accessible dans une "instance"), et donc le seul moyen d'y accéder c'est d'avoir des méthode pour le faire.

 

Pourquoi faire des getter/setter alors qu'on peu modifier directement la variable me direz vous.

Exemple tout bête (en pseudo code):

Soit la classe suivante:

 

GPS

  • kmPar: Nombre = Km parcouru
  • kmRestant: Nombre = Km restant jusqu'à destination
  • kmTotal : Nombre = Km total du trajet

Si l'augmente le nombre de Km parcouru, il faut évidemment diminuer les Km restant.

Le jour où tu fais ton dev, c'est logique et évident.

Mais si tu partage/reviens plus tard/réutilise ton code il n'ai pas dit que tu y pense.

Alors le plus simple c'est modifier les deux valeurs de façon "transparente" :

Fonction setKmPar(nouvelleValeur)
   kmPar = nouvelleValeur
   kmRestant = kmTotal - nouvelleValeur

Fonction setKmRestant(nouvelleValeur)
   kmRestant = nouvelleValeur
   kmPar = kmTotal - nouvelleValeur

Bien sur, dans code bien pensé, il y a une variable qui aurait été supprimée :P .

 

Ça permet aussi de faire des validations de valeurs, de faire une gestion de mémoire (même si avec avec @synthetize, c'est géré), et d'autre traitements...

 

Donc pour résumé, en Objective-C, à quelque exception près, on passe toujours par un setQuelqueChose: pour modifier une valeur dans une instance.

Modifié par FJA
Lien vers le commentaire
Partager sur d’autres sites

Alors correction : non, tu peux accéder directement aux variables d'une classe, comme en C++, RB ou encore Java. Il y a d'ailleurs le même genre de restriction d'accès avec @public / @private / @protected. Il faut juste que ces variables soient déclarées dans le .h et pas uniquement en extension de classe dans le .m. Pour y accéder, tu utilises l'opérateur "->" (comme en C / C++), du genre monInstance->maIVar. Il n'existe évidemment jamais de cas (et s'ils existent, c'est que le code est mal structuré) qui nécessite de faire ça (la seule exception, c’est dans certain cas où le monInstance est self). Passer par des property ou des méthodes, c'est ce qu'il faut faire. Cette encapsulation est facilitée et renforcée par OC 2.0 & ABI 64.

Après l'encapsulation de la POO n'est pas propre à Objective-C, même si le langage se prête à ce genre de chose. Que ce soit avec RB ou Java, c'est comme ça qu'il faut fonctionner.

Il faut préciser que grâce à Objective-C 2.0 et les property, tu as beaucoup moins de setter / getter à écrire : les variables sont automatiquement créées, ainsi que ses getter / setter associés. J'insiste - quand tu fait un @property, les méthodes xxx et setXxx sont créé, et inversement quand tu écris les getter / setter à la main sous la forme xxx et setXxx tu peut utiliser l'opérateur "." comme avec un @property.

Lien vers le commentaire
Partager sur d’autres sites

ZeKiller : le mieux pour toi c'est d'oublier ce qu'était Objective-C avant l'ABI 64 et la version 2.0.

 

Tu peut voir les @property de ta classe sous Xcode un peu comme les properties de ta classe sous RB. Oublie l'histoire des getter / setter et des ivars. Tu t'y intéressera quand tu maitrisera les bases d'Objective-C, si tu en as le besoin ^^

Lien vers le commentaire
Partager sur d’autres sites

  • 3 weeks later...

J'ajouterais d'ailleurs que écrire

([_case2 state]= NSOnState);

ça revient à écrire (en java ou RB) un truc du genre

case2.state()=TRUE;

, ce qui n'est pas possible : on ne peut affecter le retour d'une fonction (mis à part les pointeurs, mais là ça devient carrément tendancieux...).

Lien vers le commentaire
Partager sur d’autres sites

Oui tout à fait… D'ailleurs je me demande si en RB il existe une solution pour mettre une case à cocher en état indéterminé (le petit trait en plein milieu)… Chose hyper simple en Objective-C

Lien vers le commentaire
Partager sur d’autres sites

Hein ? ? ? Hyper-simple en Objective-C, ça y est ZeKiller est corrompu au dernier degré.... Sniff...

 

Pour Xojo : On utilise dans ce cas state au lieu de value qui ne comprend que deux positions :

ZeSuperbeCheckboxDeLaMortQuiTue.state = checkbox.CheckedStates.Indeterminate

 

C'est quand même bien plus clair... non mais...

Modifié par BorakLeRouge
Lien vers le commentaire
Partager sur d’autres sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

Chargement
 Share

×
×
  • Créer...