Je voulais associer un ensemble de rectangles avec des actions correspondantes, j'ai donc essayé de faire mais je reçois l'erreur "L'élément Initializer n'est pas constant". Y a-t-il une raison pour que ce que j'essaie de faire n'est pas autorisé en général ou n'est pas autorisé à la portée mondiale, ou est-ce que j'ai une sorte d'erreur mineure de ponctuation?
3 Réponses :
Du: au moment de l'exécution, enregistrez les sélecteurs: sortie: plus sur sél_registername () au Référence d'exécution de l'objectif-C 2.0 .
Oui, j'étais au courant de sel_registername, mais de nouveau en principe, il semble faux de faire cette étape à l'exécution quand elle est vraiment déterminée à la compilée. Peut-être que la réponse à ma question est vraiment juste "non, tu ne peux pas", et je devrais poser une autre question comme "Quelle est la meilleure façon de construire une table de répartition de la fonction dans l'objectif-C" ...
Je ne voulais pas assumer l'ignorance de votre part. C'est une question intéressante, mais je ne connais pas la bonne réponse.
Désolé si je sonnais offensé - je suis beaucoup ignorant sur cette plate-forme!
Cette réponse est pourquoi Étant donné l'exemple suivant:. P> "initialiseur élément n'est pas constante" code> theSelector = sel_registerName("constantSelector:test:");
merci pour les détails. J'avais supposé que le nom de Sel_Registername se produise à l'heure compilée / liaison, plutôt qu'à temps de chargement, pour un sélecteur constant ... Donc, je suppose que sel_registername est vraiment "plus lent" si vous l'appelez> 1 fois ...
Wow ... n'a pas compris la moitié, mais sonne comme si vous savez de quoi vous parlez) +1
"La fonction doit faire le travail réel de trouver le sélecteur si sa déjà enregistrée" : exactement. PAR EXEMPLE. Si un fichier source d'application utilisée @selector (ConstantesLector: test :) , une liberie dynamique (framework) a également utilisé ce sélecteur, et si un code d'exécution dynamique a fait un sel_registername ("ConstantsLector: test : ") , objectif-c assure tous les mêmes renvoient le même sel (aka struct objc_selector * ) Pointeur au moment de l'exécution. Cette fonctionnalité permet aux sélecteurs des chaînes internées efficacement afin de faire des comparaisons d'égalité sélecteur (et donc de recherches) vraiment rapides - une comparaison de pointeur est tout ce qui est nécessaire ..
On dirait que vous réinventez NSCell ici. Si vous souhaitez implémenter un menu, pourquoi ne pas utiliser de classes d'interface utilisateur existantes?
Je ne sais pas pourquoi
@selector n'est pas constant, mais si vous pouvez mettre l'initialisation dans une fonction, vous n'auriez pas à vous soucier de cela.Je ne voulais pas écrire de code comme des Somémenurects [0] .action = @Dosomething, car alors je pourrais aussi bien faire la même chose à l'exécution, c'est-à-dire si (CGRRRRECONTAINESPOINT (SOMÉMENURECTS [0], PT)) {[SOMMENURESTS [0] ]}
Un sélecteur n'est pas constant car la valeur n'est pas vraiment déterminée tant que très tôt au moment de l'exécution. Ainsi, vous pouvez coller une chaîne là-bas et effectuer une recherche au moment de l'exécution, si vous le souhaitez.
Donc, pour l'instant, j'utilise une table statique de (char *) s et appelez simplement le sélecteur via sel_registername lors de son choix, car il s'agit de l'interface utilisateur et que l'appel supplémentaire n'a pas d'importance.