TazNormand a écrit :Pourquoi tu veux absolument passer par la mémoire pour échanger entre VB et PB ???
Il me semble que Dobro t'avais conseillé de passer par un/des fichier(s), ce qui me paraît aussi beaucoup plus simple.
Peux-tu me dire :
1° Quelles type de données doivent être échangées entre les 2 "basics" ?
2° En gros ce que fait le prog VB et que fait le prog PB ?
3° Pourquoi tu as exclu d'emblée le fichier "d'échange" ?
J'ai cru comprendre le côté "sensible" de tes développements, mais parfois, rien ne sert de réinventer la roue, ou de se prendre le chou inutilement
Oui oui, et je lui avait deja expliqué tout ça.
Donc je vais le refaire rien que pour toi que j'aime bien
ATTENTION !! comme je l'ai deja expliqué X fois....je vais faire court
3° Pourquoi tu as exclu d'emblée le fichier "d'échange" ?
1/ Pour les fichiers a mon boulot on a l'UAC a fond, et je ne suis jamais sur de pouvoir creer un fichier meme ou est le programme principal, car il faut que je demande l'autorisation pour l'instal
2/ En plus j'aime pas les fichiers pour ce genre d'utilisation
En fait passer une variable, c'est assez simple, alors j'ai du mal a comprendre que ce soit si "impossible" pour un tableau qui est X variable, ni plus ni moins
3/ Et troisieme raison, ce ne sont pas des fichiers que je passe mais des variables donc je trouve pas ça vraiment approprié, plus un peu du domaine de la bidouille, que de la vraie prog
DJES m'a donné un lien sur les filemapping, mais encore la c'est plutot pour les fichiers
Quand aux PIPES..apparement c'est plus pour les données pas trop longues.
Y'a encore la mémoire partagée, je crois
Et je crois aussi que les MUTEX, dont je connais que le nom, ont un raport avec ça aussi
1° Quelles type de données doivent être échangées entre les 2 "basics" ?
Comme je te l'ai dit.. "juste" un tableau de string "tout bete".
Mais comme le dit le soldat...la gestion de ces "choses" n'est pas de tout repos
Remarque c'est un bon exercice pour la gestion des memoires et tout le toutim
2° En gros ce que fait le prog VB et que fait le prog PB ?
C'est aussi "tout simple"...ça fait un mois que je le dit
1/ j'ai un tableau dans VB, je veux pouvoir, le modifier, l'agrandir, le retrecir dans la DLL et le retourner a VB.
Et ceci autant de fois que je le desire, come si il etait dans VB tout le temps quoi
2/ Ou bien mais si j'arrive a faire la une, la 2/ pourra se faire aussi.
J'ai rien dans VB, je demande "la liste des slips a KCC" (Pour reprendre un exemple que j'ai bien compris
) et la DLL cherche dans les armoires des disques dur (par exemple) et elle me renvoie un tableau de string comme elle renverrait une variable string
Voila, j'ai au moins 10 codes differents, passage par bloc memoire, par pointeurs, par prototype, retour aussi par X methodes, les callbacks avec IDLE, et meme l'ASM avec XOMBIE
Je les remercie tous au passage
MAis y'a toujours un "MIASME" qui fait que j'echange mes larmes de bonheur du debut par celles de la tristesse quand je me rend compte que je suis dans un cul de sac
Encore hier, je suis arrivé a faire ce que je voulais ...mais avec cette satané RTLMOVEMEMORY, car il n'y a qu'elle avec VB pour lire dans la memoire,
1/ j'envoie bien le tableau par pointeur, grace au code de SROD je lis le tableau VB avec la structure *strptr.INTEGER (Ca ça marche
)
2/ Je copie le tableau dans la DLL comme ça, j'abandonne le tableau VB
3/ Je modifie le tableau DLL, comme si de rien etait, redim, dim et ce qui s'en suit ...
4/ Et c'est le retour le probleme...si je renvoie l'adresse du tableau de la DLL
Quand je fais un rtlmovememory, ce cake il enleve les pointeurs du tableau de la DLL pour les mettre dans le nouveau tableau de retour dans VB.
ET quand je veux reenvoyer un second tableau...la DLL est perdue car les pointeur de son tableau de transfert ont été déplacé la fois d'avant
Et la ...j'ai soit des hieroglyphes...soit un plantage et fermeture du RAD de VB
plantage assuré