Échange de données entre deux EAs fonctionnant dans des terminaux différents - page 4

Nouveau commentaire
 

Une alternative au registre est le simple partage de fichiers. (Je veux dire le système de fichiers NTFS)

Il y a 2 terminaux c:\mt1, c:\mt2 dans chacun d'eux bien sûr \experts\files

Créer c:\mt1\experts\files\exchange c:\mt2\experts\files\exchange

Créer la commande linkd à partir des outils du kit de ressources Windows Server 2003 (pour win 2000,2003,xp) dans vista MKLINK

linkd.exe c:\mt1\experts\files\exchangec :\mt2\experts\files\exchange

il s'agit maintenant d'un répertoire partagé avec les terminaux. (Copier n'importe quel fichier dans c:\mt1\experts\files\exchangeet naviguer dans c:\mt2\experts\files\exchange )

la même chose peut être faite en utilisant Far - Alt F6.

 
JavaDev >> :

Une alternative au registre est le simple partage de fichiers. (Je veux dire le système de fichiers NTFS)

Il y a 2 terminaux c:\mt1, c:\mt2 dans chacun d'eux bien sûr \experts\files

Créer c:\mt1\experts\files\exchange c:\mt2\experts\files\exchange

Créer la commande linkd à partir des outils du kit de ressources Windows Server 2003 (pour win 2000,2003,xp) dans vista MKLINK

linkd.exe c:\mt1\experts\files\exchangec :\mt2\experts\files\exchange

il s'agit maintenant d'un répertoire partagé avec les terminaux. (Copier n'importe quel fichier dans c:\mt1\experts\files\exchangeet naviguer dans c:\mt2\experts\files\exchange )

vous pouvez faire de même avec Far - Alt F6.

Pourtant, la communication par dossiers n'est pas le bon outil. Pas le bon.

Les fichiers sont inventés pour le stockage à long terme d'informations. Pourquoi s'embêter avec un disque ? Il y a de la RAM pour la communication.

 
Andres >> :

Après quoi il est reçu :

2009.05.19 01:22:16 2008.12.31 01:49 temp EURUSD,M1 : ####
2009.05.19 01:22:16 2008.12.31 01:49 temp EURUSD,M1 : RegCreateKeyExA() : Une partition inexistante a été créée.
2009.05.19 01:22:16 temp démarré pour les tests

C'est-à-dire que le contenu du tampon ne change pas, bien qu'aucune erreur ne se produise lors de l'appel. Et le registre contient exactement la chaîne "Test".

D'après les messages du forum, j'ai compris que cela se produit à cause d'un passage inhabituel de chaînes de l'environnement MQL vers les fonctions DLL. Dans l'environnement MQL, les développeurs opèrent avec des chaînes en utilisant leur propre gestionnaire (string pool), et apparemment sur cette frontière, le mauvais tampon est rempli et donc nous ne pouvons pas voir le résultat renvoyé par la fonction API. Mais si nous utilisons des chaînes de caractères initialisées à la longueur maximale totale, alors, pour autant que je sache, il n'y a aucun problème. C'est pourquoi la chaîne de 255 caractères "#" est là. Le caractère "#" a été choisi simplement pour rendre la chaîne visible à l'œil. Cela n'a rien à voir avec l'API Win elle-même, car le contenu du tampon avant l'appel n'a aucune importance. Il s'agit de la limitation de la longueur de la chaîne que j'ai mentionnée précédemment. Vous pouvez passer des chaînes de plus de 255 caractères à la fonction SetStringValue() mais elle ne parviendra pas à les lire.

Bien sûr, il est bon de ne pas avoir de limites, mais je ne vois pas en quoi cela constitue un grand inconvénient. Cela pose la question suivante : pourquoi avoir besoin de lire une chaîne de caractères d'une taille donnée ? S'il s'agit de contraintes, vous pouvez les contourner en écrivant une fonction qui divise la chaîne d'entrée en N paramètres de longueur 255 + le paramètre "reste". Et en le lisant, il le récupère. Il n'y a pas d'autre moyen. Si vous avez des difficultés, contactez-moi, je le ferai. Simplement, tout le monde a des besoins différents, nous ne pouvons pas tout fournir, il me suffit de ceci, et quelqu'un utilise des variables globales, et même à plusieurs niveaux.

Je suis confus... Où se trouve la limite de 255 caractères ? Je sais avec certitude qu'il n'existe pas de restriction de ce type dans MQL4.

L'exemple de code était une indication subtile du but à atteindre :-))

 
Zhunko >> :

Pourtant, la communication par dossiers n'est pas le bon outil. Ce n'est pas le bon outil.

Les fichiers sont inventés pour stocker des informations pendant une longue période. Pourquoi tourmenter le disque ? Il y a de la RAM pour la communication.

Je suis en partie d'accord avec vous.

Par la RAM, c'est possible, mais c'est difficile (après tout, le forum n'est pas composé à 100% de programmeurs système et même pas à 50%).

Et si vous regardez un peu plus loin - dans unix - tous les fichiers et la RAM et les disques et les processus.

J'ai juste suggéré une des nombreuses façons.

 
Zhunko >> :

Je ne comprends pas... Où se trouve la limite de 255 caractères ? Je sais avec certitude qu'il n'y a pas de telle limitation dans MQL4.

L'exemple de code était une allusion subtile à l'essence de la question :-))

Eh bien, lorsque pendant l'exécution du programme vous incrémentez une chaîne de caractères, il n'y a pas de restriction, mais ensuite il s'avère que ce n'est plus une constante de chaîne de caractères. La documentation est très claire sur la longueur des constantes de chaîne :

La longueur de la constante de chaîne est comprise entre 0 et 255 caractères. Si la constante de la chaîne dépasse la longueur maximale, les caractères inutiles seront tronqués à droite et le compilateur générera l'avertissement correspondant.

 
Andres >> :

Il n'y a pas de limitation lorsque vous augmentez la chaîne pendant l'exécution du programme, mais il ne s'agit plus alors d'une constante de chaîne. C'est clairement écrit dans la documentation sur la longueur des constantes de chaîne :

Dans notre cas, il importe peu que ce soit une constante ou non.

On peut donc faire plus avec une variable ?

 
Zhunko >> :

Dans notre cas, il importe peu que ce soit une constante ou non.

Vous pouvez donc faire plus, avec une variable ?

Pourquoi ça n'a pas d'importance ? Le fait est que c'est important ( !), parce qu'avec un tampon sous forme de chaîne constante, l'appel API fonctionne comme il le devrait, et avec un tampon de chaîne créée "dynamiquement", l'appel API fonctionne sans erreurs, mais nous n'observons pas les données du registre dans cette chaîne, pour les raisons décrites précédemment.


Andres a écrit >>
Lorsque, au cours de l'exécution du programme, vous devez augmenter la chaîne, elle n'a pas de limite, mais il s'avère alors que ce n'est pas une chaîne constante. La documentation dit qu'elle est claire sur la longueur des constantes de la chaîne :

Je parlais ici de la limitation de la longueur des chaînes, et non de la limitation de la bibliothèque.

Essayez d'obtenir des données du registre avec une chaîne constante et avec une chaîne incrémentée dynamiquement et vous verrez la différence. Dans le premier cas, les données arrivent, dans le second, elles n'arrivent pas.

 
Andres >> :

Je parlais ici de la limitation de la longueur des chaînes, et non de la limitation de la bibliothèque.

Essayez de récupérer des données du registre en utilisant une constante de type chaîne et une chaîne incrémentée dynamiquement, et vous verrez la différence. Dans le premier cas, les données sont reçues, dans le second cas, elles ne le sont pas.

>>...bizarre !... Il s'avère donc que l'endroit où la mémoire est allouée dans la fonction a de l'importance ?

 

La meilleure façon d'échanger des données entre programmes, à mon avis, est de recourir à des fichiers virtuels :

// Открываем объект-отображение FILE_MAP_READ

hMMF = OpenFileMapping( FILE_MAP_WRITE, FALSE, lpFileShareName);

// Если открыть не удалось, выводим код ошибки

if( hMMF == NULL) {

MessageBox(NULL,"OpenFileMapping: Error","RealTimeData", MB_OK );

return 0;

}

// Выполняем отображение файла на память FILE_MAP_READ 

// В переменную lpMMF будет записан указатель на отображаемую область памяти

lpMMF = MapViewOfFile( hMMF, FILE_MAP_WRITE,0,0,sizeof( NSDTfeedTick));

// Если выполнить отображение не удалось, выводим код ошибки

if( lpMMF == 0) {

MessageBox(NULL,"MapViewOfFile: Error","RealTimeData", MB_OK );

return 0;

}

//---

et ainsi de suite.....

Tout fonctionne de manière fiable et sans problème. .... Testé électroniquement :)

 
klot >> :

La meilleure façon d'échanger des données entre programmes, à mon avis, est de recourir à des fichiers virtuels :

et ainsi de suite.....

Tout fonctionne de manière fiable et sans problème. .... Testé électroniquement :)

Tout à fait exact. FileMapping est un outil formidable, mais pas le plus facile. Vous pouvez également essayer les pipes ou les mailslots.

12345678
Nouveau commentaire
Raison: