Scambio di dati tra due EA in esecuzione su terminali diversi - pagina 4

 

Un'alternativa al registro è la semplice condivisione di file. (intendo il file system NTFS)

Ci sono 2 terminali c:\mt1, c:\mt2 in ognuno di essi naturalmente \esperti\fili

Creare c:\mt1\experts\files\exchange c:\mt2\experts\files\exchange

Creare il comando linkd da Windows Server 2003 Resource Kit Tools (per win 2000,2003,xp) in Vista MKLINK

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

questa è ora una directory condivisa con i terminali. (Copiare qualsiasi file in c:\mt1\experts\files\exchangee navigare in c:\mt2\experts\files\exchange )

lo stesso può essere fatto usando Far - Alt F6.

 
JavaDev >> :

Un'alternativa al registro è la semplice condivisione di file. (intendo il file system NTFS)

Ci sono 2 terminali c:\mt1, c:\mt2 in ognuno di essi naturalmente \esperti\fili

Creare c:\mt1\experts\files\exchange c:\mt2\experts\files\exchange

Creare il comando linkd da Windows Server 2003 Resource Kit Tools (per win 2000,2003,xp) in Vista MKLINK

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

questa è ora una directory condivisa con i terminali. (Copiare qualsiasi file in c:\mt1\experts\files\exchangee navigare in c:\mt2\experts\files\exchange )

si può fare lo stesso con Far - Alt F6.

Eppure, comunicare attraverso i file non è lo strumento giusto. Non quello giusto.

I file sono inventati per l'archiviazione a lungo termine delle informazioni. Perché preoccuparsi di un disco? C'è la RAM per la comunicazione.

 
Andres >> :

Dopo di che viene ricevuto:

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(): È stata creata una partizione inesistente.
2009.05.19 01:22:16 temp avviato per i test

Cioè, il contenuto del buffer non cambia, anche se non si verificano errori durante la chiamata. E il registro contiene esattamente la stringa "Test"

Dai post del forum ho capito che succede a causa di un insolito passaggio di stringhe dall'ambiente MQL alle funzioni DLL. Nell'ambiente MQL gli sviluppatori operano con le stringhe usando il proprio gestore (string pool), e apparentemente su questo confine il buffer sbagliato viene riempito e quindi non possiamo vedere il risultato restituito dalla funzione API. Ma se usiamo stringhe inizializzate all'intera lunghezza massima, allora, per quanto posso vedere, non ci sono problemi. Ecco perché la stringa "#" di 255 caratteri è lì. Il carattere "#" è stato scelto semplicemente per rendere la stringa visibile all'occhio. Non ha niente a che fare con l'API Win stessa, perché non importa con cosa sia riempito il buffer prima della chiamata. Questa è la limitazione della lunghezza delle stringhe che ho menzionato prima. Potete passare stringhe più lunghe di 255 caratteri in SetStringValue() ma non riuscirà a leggerle.

Naturalmente è bene non avere limitazioni, ma non vedo come sia un grande inconveniente. Viene da chiedersi: perché avete bisogno di leggere una stringa di una data dimensione? Se si tratta di vincoli, puoi aggirarli scrivendo una funzione che divide la stringa di input in N parametri con lunghezza 255 + parametro "resto". E quando si legge lo raccoglie di nuovo. Non c'è altro modo. Se avete difficoltà, contattatemi, lo farò. Semplicemente, ognuno ha esigenze diverse, non possiamo fornire tutto, è sufficiente per me solo questo, e qualcuno usa variabili globali, e anche a più livelli.

Sono confuso... Dov'è il limite di 255 caratteri? So per certo che non c'è una tale restrizione in MQL4.

Il codice di esempio era un sottile accenno al punto :-))

 
Zhunko >> :

Tuttavia, comunicare attraverso i file non è lo strumento giusto. Non è lo strumento giusto.

I file sono inventati per conservare le informazioni per molto tempo. Perché tormentare il disco? C'è la RAM per la comunicazione.

Sono parzialmente d'accordo con te.

Attraverso la RAM è possibile, ma è difficile (dopo tutto, il forum non è 100% programmatori di sistema e nemmeno 50%).

E se si guarda un po' più in là - in unix - tutti i file e la RAM e i dischi e i processi.

Ho solo suggerito 1 dei tanti modi.

 
Zhunko >> :

Non capisco... Dov'è il limite di 255 caratteri? So per certo che non c'è questa limitazione in MQL4.

L'esempio di codice era un sottile accenno all'essenza della domanda :-))

Bene, quando durante l'esecuzione del programma si incrementa una stringa, non c'è restrizione, ma poi si scopre che non è più una costante di stringa. La documentazione è molto chiara sulla lunghezza delle costanti di stringa :

La lunghezza della costante di stringa va da 0 a 255 caratteri. Se la costante di stringa supera la lunghezza massima, i caratteri non necessari saranno troncati a destra e il compilatore genererà l'avvertimento corrispondente.

 
Andres >> :

Beh, non c'è limitazione quando si aumenta la stringa durante l'esecuzione del programma, ma allora non è più una costante di stringa. È chiaramente scritto qui nella documentazione sulla lunghezza delle costanti di stringa:

Nel nostro caso, non importa che sia una costante o meno.

Quindi si può fare di più con una variabile?

 
Zhunko >> :

Nel nostro caso, non importa se è una costante o no.

Quindi si può fare di più, con una variabile?

Perché non ha importanza? Il punto è che è importante (!), perché con un buffer come stringa costante la chiamata API funziona come dovrebbe, e con un buffer di stringa creato "dinamicamente" la chiamata API funziona senza errori, ma non osserviamo i dati di registro in questa stringa, per i motivi descritti prima.


Andres ha scritto >>.
Quando durante l'esecuzione del programma si deve aumentare la stringa, essa non ha limiti, ma poi si scopre che non è costante di stringa. La documentazione dice che è chiaro sulla lunghezza delle costanti di stringa:

Qui stavo parlando della limitazione della lunghezza delle stringhe, non della limitazione della libreria.

Provate a ottenere dati dal registro con una stringa costante e con una stringa incrementata dinamicamente e vedrete la differenza. Nel primo caso i dati arrivano, nel secondo no.

 
Andres >> :

Qui stavo parlando della limitazione della lunghezza delle stringhe, non della limitazione della libreria.

Provate a recuperare i dati dal registro usando una stringa costante e una stringa incrementata dinamicamente, e vedrete la differenza. Nel primo caso i dati vengono ricevuti, nel secondo no.

>>...strano!... Quindi si scopre che è importante dove nella funzione viene allocata la memoria?

 

Il modo migliore per scambiare dati tra programmi, IMHO, è attraverso file virtuali:

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

}

//---

e così via.....

Tutto funziona in modo affidabile e senza glitch.... Testato elettronicamente :)

 
klot >> :

Il modo migliore per scambiare dati tra programmi, IMHO, è attraverso file virtuali:

e così via.....

Tutto funziona in modo affidabile e senza glitch.... Testato elettronicamente :)

Assolutamente giusto. FileMapping è un grande strumento, anche se non il più semplice. Potresti anche provare con i tubi o con i mailslot.