Utilisation de fichiers cocoa multiples
Michael31
Membre
Bonjour,
Presque un an d'écoulé depuis mon inscription sur votre site : missions professionnelles obligent, j'étais loin de mon Mac !
Le GUI est donc de retour sur mon bureau: cela avance mais je bute sur un problème digne d'un étourdi ..
En fait, le programme complet étant assez volumineux, j'éclate les fonctions sur plusieurs fichiers qui sont attachés lors de la compilation: principe sans innovation, utilisé avec mes applications sous Delphi.
Problème : bien que je déclare les fichiers .h utilisés dans le source commun, ils ne sont pas vu lors du fonctionnement. J'ai essayé de grouper tous les fichiers dans le groupe CLASS ou dans OTHER SOURCE sans effet. Les fichiers sont sans erreurs lors du lancement de BUILD, je vois bien les routines depuis le cube bleu dans IB, mais pas de réponse aux actions en provenance des commandes associées dans le GUI.
A ce niveau, je suis un peu perdu . .. une aide pour éclairer mon ignorance serait des plus apprécier ...
pour info:
/********************/
#import "I2CFunctions.h"
#import "I2CbusCoder.h"
#import "HIDcontroller.h" // HID controller routines
@implementation I2CbusCoder
/********************/
les routines associées à 2CFunctions.h et / ou HIDcontroller.h ne sont pas vues par I2CbusCoder.h
merci pour votre aide,
Michael
Presque un an d'écoulé depuis mon inscription sur votre site : missions professionnelles obligent, j'étais loin de mon Mac !
Le GUI est donc de retour sur mon bureau: cela avance mais je bute sur un problème digne d'un étourdi ..
En fait, le programme complet étant assez volumineux, j'éclate les fonctions sur plusieurs fichiers qui sont attachés lors de la compilation: principe sans innovation, utilisé avec mes applications sous Delphi.
Problème : bien que je déclare les fichiers .h utilisés dans le source commun, ils ne sont pas vu lors du fonctionnement. J'ai essayé de grouper tous les fichiers dans le groupe CLASS ou dans OTHER SOURCE sans effet. Les fichiers sont sans erreurs lors du lancement de BUILD, je vois bien les routines depuis le cube bleu dans IB, mais pas de réponse aux actions en provenance des commandes associées dans le GUI.
A ce niveau, je suis un peu perdu . .. une aide pour éclairer mon ignorance serait des plus apprécier ...
pour info:
/********************/
#import "I2CFunctions.h"
#import "I2CbusCoder.h"
#import "HIDcontroller.h" // HID controller routines
@implementation I2CbusCoder
/********************/
les routines associées à 2CFunctions.h et / ou HIDcontroller.h ne sont pas vues par I2CbusCoder.h
merci pour votre aide,
Michael
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Montre un peu plus de code si tu souhaite que nous t'aidions
- les fichiers I2CbusCoder.h , I2CbusCoder.m, I2CFunctions.h et I2CFunctions.m sont sous la même classe.
Les routines de chacun de ces fichiers doivent répondre aux commandes saisie sur l'écran du système ( voir image 1 ).
Toutes les fonctions situées dans I2CbusCoder.m fonctionnent comme attendu en utilisant la délégation, associé aux tags pour identifier l'origine des commandes.
Afin d'éclaircir le programme, j'ai éclater les fonctions par famille : les routines présentes dans le fichier I2CFunctions.m sont bien compilées, sans erreur, mais ne sont jamais activées par les commandes provenant de l'écran de saisie. voir image 2
Une deuxième série de fichiers est en cours pour supporter le port HID. Pour essais, j'ai logé ces fichiers dans le groupe "Other Sources" : cela ne fonctionne pas car je ne sais ni envoyer / recevoir une chaà®ne de
caractères, ni activer une fonction depuis le fichier I2CbusCoder.m.
Une re- lecture du bouquin de Aaron Hillegass, version 3, s'impose pour moi car je suis plus que bloqué, sauf à mettre toutes les fonctions dans un seul fichier , ce qui n'est pas très élégant mais délicat pour la mise point et la maintenance...
Encore merci pour l'aide...
Michael
Qu'est ce que ça veut dire exactement ?
ça ne compile pas, ou bien leur code n'est pas exécuté ?
Par ailleurs, je ne peux accéder aux routines ou aux variables existantes dans le fichier HIDcontroller .
Michael
- La communication fait partie de la couche modèle.
- Il te faut créer un objet contrôleur qui va recevoir toutes les IBActions de ta fenêtre, et posséder toutes les Outlets.
C'est ensuite au contrôleur d'appeler les fonctions/méthodes de ta couche modèle.
Ceci amène à la deuxième question: qui va instancier l'objet qui gère la communication ?
Pour un projet comme celui-ci, le plus simple est que ce soit le contrôleur.
Le contrôleur est instancié, quant à lui, depuis le .nib, en plaçant un cube bleu. Dans sa méthode -init, tu pourras instancier un objet qui gère la communication.
Ces quelques indications devraient t'aiguiller.
merci pour les informations.
Manifestement, ce n'est pas simple d'utiliser cocoa en venant du monde Pascal.
Je vais continuer mon analyse. Pour information, le projet fonctionne (matériel et logiciel) sous Delphi, mais je souhaite une version logicielle sous Mac pour supporter des applications en dehors du monde Windows. Dommage qu'un ensemble de développement sous Pascal n'existe pas sous Apple !
bye
Michael
ça demande un changement d'état d'esprit: passer du "que faut-il faire" à "quel objet à quelles responsabilités". C'est une science en soi, qui demande des années d'apprentissage.
Cocoa utilise les notions "objet" avec souvent beaucoup d'élégance, mais ceci exige de la part du programmeur de penser totalement "objet".
Je te conseille un bon bouquin pour apprendre la logique de la POO (Programmation Orientée Objet), ils sont en général bien expliqués et ça t'aidera je pense
La difficulté, ou le problème, c'est de devoir digérer une nouvelle technique pour développer un système qui est sans commune mesure avec les besoins de l'informatique " gros calibre". Tout en gardant à l'esprit la limite du temps dédié à ce système qui ne peut être infini... J'ai une approche de la POO avec Delphi, approche restreinte en comparaison des connaissances nécessaires, il me semble, pour utiliser au mieux Cocoa. Donc, des efforts en perspective...
Cela étant, le système reste simple, en terme informatique : pas de jeu, pas de liaison complexe sur le web, pas de gestion de fichiers complexes, pas d'utilisateurs multiples, etc. reste la notion de commande temps réels et la liaison USB qui sont essentiels pour supporter une électronique complexe par ailleurs.
Néanmoins, cela avance et , hier soir, j'ai pu établir l'activation de la méthode B via la méthode A en utilisant la procédure performSelector sans toucher au reste du code existant. je vais étudier la méthode NSInvocation afin de pouvoir échanger plusieurs paramètres lors de l'appel des fonctions que je dois gérer dans ce contexte.
Merci pour vos conseils et encouragements !
Michael
Tu m'a l'air pris de cours dans un projet ou les zones d'ombre sont multiple. Tu essaie de faire avec Cocoa comme ce que tu faisait sur delphi ou Pascal. Ca peu marché maintenant mais la maintenance du produit risque d'être dur et tu risque de tout ré-écrire.
Bon courage et n'hésite pas à poser des questions.
Comment gère tu la connexion USB ? (utilise tu une class USB spécifique ou un mode de connexion simple ? )
Je suis d'accord : le logiciel en cours ne répond probablement pas aux canons de cocoa ... désolé ...
La communication avec le MCU extérieur ( MC9S08JM60 freescale) se fait selon la procédure HID , USB 2.0. Le format des données est défini selon les spécifications du MCU. Je penses utiliser les modèles fournis par Apple, en particulier la note technique TN2187.
A ce jour, le problème des échanges entre A et B est résolu : je peux donc écrire une chaà®ne de caractères, définie selon le type de donnée, pour préparer le rapport HID avant son envoie sur le bus.
L'étape suivante est donc la liaison USB/HID.
bye
Michael
Je reviens vers vous pour clarifier / solutionner un problème avec le kit HIB développé par Apple.
Les nouveaux API, de 2009, doivent simplifier la programmation du port USB pour un périphérique HID. Sur le papier,c'est bien. Sur la réalité, je tombe sur un problème en relation avec la méthode suivante :
IOHIDManagerRegisterDeviceMatchingCallback(managerRef, [ select callBackRoutine , inContext);
question: dés lors que la fonction attend un pointer sur la sous routine " callBackRoutine " ( que je crée par ailleurs ), comment établir cette demande de pointeur depuis cocoa ?
Par ailleurs, la totalité des fonctions API sont au format C : comment les utiliser depuis cocoa en gardant en tète que de nombreuses de ces fonctions attendent des pointeurs de routines dans leurs paramètres ?
merci pour votre aide,
bye
Michael
Tu peux donc appeler une fonction C depuis le code Cocoa comme d'habitude, et écrire des fonctions C dans une fichier .m.
Quand les API ont besoin d'un callback, c'est un pointeur sur une fonction C qui est attendu. Il te suffit de donner le nom de la fonction C (sans les parenthèses). Fais juste attention que la fonction ait le prototype attendu, qui doit t'être fourni dans la documentation. Tu ne peux donc pas passer un pointeur sur une méthode ObjC.