Bonsoir à tous
J'ai deux applications, une en Visual Basic 6.0 et une autre en visual C 6.0 qui tournent au même moment et qui comminiquent actuellement par fichiers sur disque interposés. Ce n'est pas très élégant. Avant je compilais une DLL en C que j'appelais sous VB mais ça n'allait que dans un sens.
Je pense qu'il doit y avoir une manière pratique pour échanger des informations, est-ce que quelqu'un peut me mettre sur la voix?
Je vous remercie. Lionel.
Bonjour,
Si la communication n'a lieu que dans un sens, un pipe :
appli VB | appli C
la sortie standard de l'appli VB arrive sur l'entrée standard de l'appli C (ou inversement en inversant les commandes)
Si la communication a lieu dans les deux sens, déclarer soi-même un pipe (voir ici), à condition de réussir à s'y connecter en C (je ne sais pas si les pipes VB sont compatibles avec les pipes C).
Merci pour cette réponse.
Je ne connaissais pas ce mécanisme des pipes.
Mais je doute pouvoir l'incorporer sous visual studio 6.
Je vais chercher, mais je ne vois pas au juste ce que c'est que "la sortie standard de l'appli VB", pouvez-vous préciser?
Merci.
Bonjour
Il n'existe pas de "pipe VB"; il y a des pipe sous Windows, et c'est une des méthodes d'IPC (il y en d'autres, mais pour déterminer celles utilisable avec une techno aussi ancienne que VB6 ....), donc accessible aussi bien via VB que VCEnvoyé par Chanur
Mais a tout hasard :
- pipe nommés ou non-nommés.
- RPC (implémentation assez complexe).
- etc .... (Mailslot, MSMQ, ....)
d'autres possibilités (via DDE, pare exemple) mais comme le posteur initial ne donne aucun détail, il est difficile de l'orienter.
Pour commencer, les infos minimum requises :
- Sous quel OS tournent les applis ?
- Est une IPC locale ou distante qui est souhaité ?
- l'appli VC est en 16 ou en 32 bits ? (la VB6 étant de toute façon en 32 bits).
- Quel type d'appli pour VB et VC: windows, console ou service (ce dernier cas n'étant possible que pour VC).
Bref, sans plus d'info, on ne peut rien dire.
Merci pour vos réponses pertinentes.
Je n'ai pas donné de détails parce que la réalité est complexe.
Aussi parce que j'ai un peu honte d'être encore avec windows XP, mais cela fonctionne tellement bien!
Mon application m'est très utile. Elle construit toute seule les images que vous pouvez voir Ici.
Le code en C produit un fichier exécutable sans fenêtre windows ni console je ne sais pas si c'est ce que vous appelez le mode "service".
Je ne déclare que cela:
#include <dos.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <time.h>
#include <windows.h>
#include "ximadef.h"
#include "ximage.h"
#include "ximath.h"
#include "gradient.h"
#include "lineflt.h"
#include "lineint.h"
et le point d'entrée comme cela:
int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) {
C'est un générateur d'images très rapide.
il contient ni MFC ni aucun événement. Il scrute des fichiers et quand il est prêt, il exécute des tâches graphiques stochastiques à l'aide de la librairie CxImage de Davide Pizzolato et des tas de services graphiques que j'ai mis des années à mettre au point.
Les fichiers contiennent des milliers de paramètres, par familles de formes de couleurs etc... que je sélectionne à la main.
VB6 fait la même chose mais en plus il reçoit par RS232 les informations de la part d'un pic16f628 qui lit les coordonnées d'un pinceau sur une toile que je peins et temps réel. J'ai utilisé VB car c'est ce que je savais faire de plus simple et rapide.
VB6 interpète les réponses du générateur qui est réaiguillé de plus belle.
Jusque là tout va bien.
Il y a peu, j'ai voulu remplacer mon pic par une webcam.
Dans ce cas là je me suis dit que OpenCV en C ou en python pourrait voir la position du pinceau et la transmettre à VB comme le pic le fait, afin de pas chambouler toute mon organisation.
Je croyais que la DDE avait été abandonnée dès le Visual studio 2003.
Maintenant, je ne sais pas encore avec quel sytème le plus simple je pourrai lire un flux vidéo.
Au départ j'avais pensé insérer un arduino équipé d'un CCD.
En fait, je suis complètement perdu car je crois être en présence d'idées incompatibles.
J'ai peur d'être obligé de tout adapter dans une version récente de visual studio car je ne me sens pas à la hauteur.
VB reçoit 10 coordonnées par secondes, c'est suffisant.
Il est certain que la meilleur solution serait de tout mettre en C++, mais le travail est colossal.
Je crois que je vais utiliser un second ordinateur qui lira le flux vidéo, cherchera la position du pinceau et transmettra les coordonnées en RS232, car les mécanismes inter-process me paraissent bien plus compliqués que ceux que je faisais il y a longtemps sous VMS.
Je vous remercie encore beaucoup.
Bonjour à tous.
Mon problème est résolu. Merci d'avoir été là quand j'étais dans la nuit.
Je croyais que les MFC avaient aboli les services anciens de la GDI.
J'ai fait des essais et j'obtiens des résultats avec la DDE et aussi avec le clipboard.
Merci encore. Lionel.
Bonjour,
juste une petite remarque : Trés jolies images, bravo !
(Ca ressemble beaucoup à des fractals.)
Oui merci.
Oui, il n'y a pas de fractales, ce sont les nombreuses itérations sur l'opérateur barycentrique qui créent ces effets là de proche en proche. Il y a beaucoup d'étapes et elles sont toutes visuelles, c'est passionnant. Quand je vais pouvoir insérer dynamiquement des impératifs finaux, "je vais en voir de toutes les couleurs".
