Intercambio de datos entre dos EAs que se ejecutan en diferentes terminales - página 4

Nuevo comentario
 

Una alternativa al registro es el simple intercambio de archivos. (Me refiero al sistema de archivos NTFS)

Hay 2 terminales c:\mt1, c:\mt2 en cada uno de ellos por supuesto \experts\files

Crear comando linkd desde Windows Server 2003 Resource Kit Tools (para win 2000,2003,xp) en vista MKLINK

linkd.exe c:\mt1\files\cambioc :\mt2\files\cambio

este es ahora un directorio compartido con los terminales. (Copie cualquier archivo en c: \mt1\experts\files\exchange y busque en c:\mt2\experts\files\exchange )

lo mismo se puede hacer usando Far - Alt F6.

 
JavaDev >> :

Una alternativa al registro es el simple intercambio de archivos. (Me refiero al sistema de archivos NTFS)

Hay 2 terminales c:\mt1, c:\mt2 en cada uno de ellos por supuesto \experts\files

Crear comando linkd desde Windows Server 2003 Resource Kit Tools (para win 2000,2003,xp) en vista MKLINK

linkd.exe c:\mt1\files\cambioc :\mt2\files\cambio

este es ahora un directorio compartido con los terminales. (Copie cualquier archivo en c: \mt1\experts\files\exchange y busque en c:\mt2\experts\files\exchange )

puedes hacer lo mismo con Far - Alt F6.

Aun así, la comunicación a través de archivos no es la herramienta adecuada. No es la correcta.

Los archivos se inventaron para almacenar información a largo plazo. ¿Por qué molestarse con un disco? Hay RAM para la comunicación.

 
Andres >> :

Tras lo cual se recibe:

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(): Se ha creado una partición inexistente.
2009.05.19 01:22:16 temp comenzó para las pruebas

Es decir, el contenido del búfer no cambia, aunque no se produzcan errores al llamarlo. Y el registro contiene exactamente la cadena "Test"

De los mensajes del foro entendí que ocurre por el paso inusual de cadenas desde el entorno MQL a las funciones DLL. En el entorno MQL los desarrolladores operan con cadenas utilizando su propio gestor (pool de cadenas), y aparentemente en este borde se llena el buffer equivocado y por lo tanto no podemos ver el resultado devuelto por la función API. Pero si usamos cadenas inicializadas a toda la longitud máxima, entonces, por lo que veo, no hay problema. Por eso está la cadena de 255 caracteres "#". El carácter "#" se ha elegido simplemente para que la cadena sea visible a simple vista. No tiene nada que ver con la propia API de Win, porque no importa con qué se llena el búfer antes de la llamada. Esta es la limitación de la longitud de la cadena que mencioné antes. Puede pasar cadenas de más de 255 caracteres a SetStringValue() pero fallará al leerlas.

Por supuesto que es bueno no tener limitaciones, pero no veo que sea un gran inconveniente. Esto nos lleva a preguntarnos: ¿por qué hay que leer una cadena de un tamaño determinado? Si se trata de restricciones, puede evitarlas escribiendo una función que divida la cadena de entrada en N parámetros de 255 de longitud + el parámetro "resto". Y al leerlo lo recoge de nuevo. No hay otra manera. Si tiene dificultades, póngase en contacto conmigo, lo haré. Simplemente, todo el mundo tiene diferentes necesidades, no podemos proporcionar todo, es suficiente para mí sólo esto, y alguien utiliza las variables globales, e incluso en varios niveles.

Estoy confundido... ¿Dónde está el límite de 255 caracteres? Sé de hecho que no hay tal restricción en MQL4.

El código de ejemplo era una sutil insinuación al respecto :-))

 
Zhunko >> :

Aun así, la comunicación a través de archivos no es la herramienta adecuada. No es la herramienta adecuada.

Los archivos se inventaron para almacenar información durante mucho tiempo. ¿Por qué atormentar el disco? Hay RAM para la comunicación.

Estoy parcialmente de acuerdo con usted.

A través de la RAM se puede, pero es difícil (después de todo, el foro no es 100% de programadores de sistemas y ni siquiera el 50%).

Y si miras un poco más allá - en unix - todos los archivos y RAM y discos y procesos.

Sólo he sugerido una de las muchas maneras.

 
Zhunko >> :

No lo entiendo... ¿Dónde está el límite de 255 caracteres? Sé de hecho que no hay tal limitación en MQL4.

La muestra de código era una sutil insinuación de la esencia de la pregunta :-))

Pues bien, cuando durante la ejecución del programa se incrementa una cadena, no hay ninguna restricción, pero luego resulta que ya no es una constante de cadena. La documentación es muy clara sobre la longitud de las constantes de las cadenas :

La longitud de la constante de la cadena es de 0 a 255 caracteres. Si la constante de la cadena supera la longitud máxima, los caracteres innecesarios se truncarán a la derecha y el compilador generará la advertencia correspondiente.

 
Andres >> :

Bueno, no hay limitación cuando se aumenta la cadena durante la ejecución del programa, pero entonces ya no es una constante de cadena. Está claramente escrito aquí en la documentación sobre la longitud de las constantes de cadena:

En nuestro caso, no importa si es una constante o no.

¿Así que se puede hacer más con una variable?

 
Zhunko >> :

En nuestro caso, no importa si es una constante o no.

¿Así que puedes hacer más, con una variable?

¿Por qué no importa? La cuestión es que es importante (!), porque con un buffer como cadena constante la llamada a la API funciona como debería, y con un buffer de cadena creado "dinámicamente" la llamada a la API funciona sin errores, pero no observamos los datos del registro en esta cadena, por las razones descritas anteriormente.


Andrés escribió >>
Cuando durante la ejecución del programa hay que aumentar la cadena, ésta no tiene límite, pero entonces resulta que no es constante la cadena. La documentación dice que es clara en cuanto a la longitud de las constantes de cadena:

Aquí me refería a la limitación de la longitud de la cadena, no a la limitación de la biblioteca.

Intenta obtener datos del registro con una cadena constante y con una cadena incrementada dinámicamente y verás la diferencia. En el primer caso, los datos llegan, en el segundo, no.

 
Andres >> :

Aquí me refería a la limitación de la longitud de la cadena, no a la limitación de la biblioteca.

Intente recuperar los datos del registro utilizando una cadena constante y una cadena incrementada dinámicamente, y verá la diferencia. En el primer caso se reciben datos, en el segundo no.

>>...¡raro!... Así que resulta que importa en qué parte de la función se asigna la memoria?

 

La mejor manera de intercambiar datos entre programas, en mi opinión, es a través de archivos virtuales:

// Открываем объект-отображение 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;

}

//---

y así sucesivamente.....

Todo funciona de forma fiable y sin fallos.... Probado electrónicamente :)

 
klot >> :

La mejor manera de intercambiar datos entre programas, en mi opinión, es a través de archivos virtuales:

y así sucesivamente.....

Todo funciona de forma fiable y sin fallos.... Probado electrónicamente :)

Absolutamente correcto. FileMapping es una gran herramienta, aunque no la más fácil. También puedes probar con las tuberías o las ranuras de correo.

12345678
Nuevo comentario
Razón de la queja: