2017-10-16 6 views
0

J'ai créé un ensemble qui sert de plug-in pour une application Cocoa avec laquelle je peux uniquement m'interfacer via un SDK C/C++. Conformément au SDK, mon plug-in exécute une fonction qui définit un objet de données de résultat par référence et renvoie un code d'erreur de résultat. Comme les développeurs de mon équipe sont beaucoup plus expérimentés en Java, nous avons construit un pont entre C/C++ et Java en utilisant des tuyaux. Ainsi, lorsque j'appelle la fonction SDK, il envoie un message à Java à travers le canal en lui demandant d'exécuter une méthode Java. La méthode Java envoie un ou plusieurs messages de rappel au SDK C/C++ qui définira finalement l'objet de données de résultat et retournera le code d'erreur de résultat pour la fonction SDK d'origine.Interagir avec l'interface graphique en Objective-C lors de l'exécution de la tâche d'arrière-plan

Ce mécanisme fonctionne assez bien à moins que mon code n'ait besoin de générer une interface graphique Java (par exemple un sélecteur de couleurs dont les valeurs RVB seront stockées via le SDK C/C++). Je veux que mon interface graphique Java présente un comportement similaire à celui d'une fenêtre enfant modale dans une application Cocoa pure. En d'autres termes, je ne veux pas que l'interface graphique de la fenêtre principale bloque (balancer la balle de plage) quand j'interagis avec elle, tout en gardant l'interface graphique Java sur l'interface graphique de Cocoa.

Ce que j'ai tenté jusqu'ici est de créer un thread d'arrière-plan qui envoie mon message d'invocation de méthode à Java. Avant que cette méthode Java génère une interface graphique, j'envoie un message spécial à C/C++ à travers le canal. Lorsque C/C++ reçoit ce message, j'inscris un observateur de fenêtre et ensuite démarre une boucle d'exécution en utilisant une source de port de message (toujours sur le thread d'arrière-plan) en utilisant Objective-C++. Mon processus de pensée était que puisque mes lectures de pipe bloquent et je n'aurai pas besoin de lire autre chose jusqu'à ce que Java GUI soit éliminé, je devrais commencer une boucle d'exécution dans mon thread d'arrière-plan qui m'aurait permis d'interagir avec L'interface graphique de Cocoa, provoquant ainsi une notification que mon observateur reconnaîtrait et ramènerait l'interface graphique Java devant l'interface graphique de Cocoa. Lorsque je disposerai de l'interface graphique Java, j'utiliserai JNI pour envoyer une requête de port de message distant à C/C++ et arrêter la boucle d'exécution. À la place, ce qui se passe, ce sont les blocs de l'interface graphique principale jusqu'à ce que je dispose de l'interface graphique Java, puis le code que j'ai décrit ci-dessus s'exécute. Je suppose que c'est parce que j'ai besoin du thread principal pour attendre un résultat afin qu'il puisse renvoyer ce résultat à la fonction C/C++. Le mécanisme que j'utilise pour cela est un std :: async qui retourne un std :: future, sur lequel j'appelle get(). Je comprends que mon appel à get() est là où je me trompe, mais je ne suis pas sûr de savoir comment attendre que mon fil de fond se termine. Je suis heureux de fournir des extraits de code si cela peut vous aider, mais je me demande si quelqu'un peut donner un sens à ce que je décris et donner des conseils généraux qui pourraient m'aider à me mettre sur la bonne voie.

Répondre

0

J'ai été capable de résoudre le problème de blocage en créant une fenêtre transparente en haut de la fenêtre principale du processus Cocoa et en effectuant mon opération qui indique au processus Java de générer une interface graphique dans un thread d'arrière-plan.

[[NSApplication sharedApplication] runModalForWindow:transparentWindow]