[dataList valueForKeyPath:@"@max.image.size.height"]
Philippe49
Membre
Je n'arrive pas à trouver l'astuce pour faire fonctionner quelque chose comme :
CGFloat height=[[dataList valueForKeyPath:@"@max.image.size.height"]
dataList est un array de dictionnaires, chaque dictionnaire ayant une clé image correspondant à une UIImage
La key path fonctionne jusqu'à size car size est une property des UIImage, mais après j'ai l'os
'[<NSConcreteValue 0x45b3d0> valueForUndefinedKey:]: this class is not key value coding-compliant for the key height.'
Une idée ?
CGFloat height=[[dataList valueForKeyPath:@"@max.image.size.height"]
dataList est un array de dictionnaires, chaque dictionnaire ayant une clé image correspondant à une UIImage
La key path fonctionne jusqu'à size car size est une property des UIImage, mais après j'ai l'os
'[<NSConcreteValue 0x45b3d0> valueForUndefinedKey:]: this class is not key value coding-compliant for the key height.'
Une idée ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Et une struct, ce n'est pas un objet, donc ce n'est pas KVC-compliant, donc c'est normal, non ?
En fait le truc c'est qu'il est aisé de confondre le "." utilisé dans le KeyPath et signifiant implicitement un "valueForKey" et le "." du C pour accéder à un élément d'une struct...
Donc moi j'écrirai : [tt]CGFloat height=[[dataList valueForKeyPath:@"@max.image.size"].height[/tt]
Ce n'est pas une question de savoir si c'est un objet ou non, c'est le fait de disposer d'accessors rendant la property KVC compliant. Cela marche avec la structure size parce que c'est une property, donc les accessors sont prêts. Mais cela ne marche pas avec height car il n'y a pas d'accessor.
[EDIT] Je me rends compte que je dis la même chose que toi Ali, c'est utile de se relire !
Donc je vois bien pourquoi cela ne marche pas, et je suis à la recherche d'une astuce pour contourner le problème.
Oui j'y ai pensé, mais là c'est le @max qui ne va pas marcher sur la structure size
En relisant la doc sur le KVC, je suis tombé là dessus, peut-être une piste à explorer ?
Du coup avec "sizeValue" et le wrapping de cette size dans un NSValue, tu peux peut-être t'en sortir côté KVC ? Bon j'ai pas exploré plus loin, je te laisse voir si ça peut aider...
S'il n'y a rien de directement prévu par Cocoa pour récupérer le paramètre "height" de ton NSSize encapsulé dans un NSValue par KVC, tu peux peut-être voir à créer une catégorie de NSValue qui supporterait le KVC, en implémentant valueForKey: qui vérifie si ta NSValue est une NSSize et si oui retourne la width ou la height selon la key demandée... ça doit pas être méchant à faire et à mon avis la façon la plus simple de contourner le problème et arriver à tes fins en gardant cette construction de ton KeyPath, non ?
Je serais toi, je définirais float width, et float height dans mon modèle.
Ce n'est pas un problème de scalaire ou d'objet, c'est un problème d'accesseur. C'est à dire que ce qui est renvoyé par le valueForKeyPath ne répond pas à un objc_msgSend() correspondant à la valeur de width.
En fait le valueForKeyPath renvoie bien un objet comme l'a dit Ali de type héritant de NSValue, mais Apple n'a pas prévu de "spécialiser" cet objet pour qu'il ait les accesseurs qui m'intéresse : "Apple, Apple Lama Sabachtani"Â
D'où l'indication d'Ali de les construire via une catégorie
Oui c'est ce que j'ai fait : construire un model qui calcule et met à jour les champs maxWidth et maxHeight : c'est plus propre et plus économique.
En fait, nous disons la même chose, mais différemment. Le KVC est capable de convertir le type scalaire NSSize en un NSValue, mais du coup, la plus petite unité manipulable devient une NSSize.
Tu pourrais avoir des accesseurs setSize: et size: dans ton modèle, mais pas setHeight: et height:.