Exchanging data between two EAs running in different terminals - page 4

New comment
 

An alternative to the registry is simple file sharing. (I mean NTFS file system)

There are 2 terminals c:\mt1, c:\mt2 in each of them of course \experts\files

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

Create linkd command from Windows Server 2003 Resource Kit Tools (for win 2000,2003,xp) in vista MKLINK

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

this is now a shared directory with the terminals. (Copy any file to c:\mt1\experts\files\exchangeand browse to c:\mt2\experts\files\exchange )

the same can be done using Far - Alt F6.

 
JavaDev >> :

An alternative to the registry is simple file sharing. (I mean NTFS file system)

There are 2 terminals c:\mt1, c:\mt2 in each of them of course \experts\files

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

Create linkd command from Windows Server 2003 Resource Kit Tools (for win 2000,2003,xp) in vista MKLINK

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

this is now a shared directory with the terminals. (Copy any file to c:\mt1\experts\files\exchangeand browse to c:\mt2\experts\files\exchange )

you can do the same with Far - Alt F6.

Still, communicating through files is not the right tool. Not the right one.

Files were invented to store information for a long time. Why bother with a disk? There is RAM for communication.

 
Andres >> :

After which it is received:

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(): A non-existing partition was created.
2009.05.19 01:22:16 temp started for testing

That is, the contents of the buffer do not change, although no errors occur when calling. And the registry contains exactly the "Test" string

From forum posts I understood that it happens because of unusual string passing from MQL environment to DLL functions. In MQL environment the developers operate with strings using their own manager (string pool), and apparently on this border the wrong buffer is filled and therefore we can't see the result returned by API-function. But if we use strings initialized to the whole maximum length, then, as far as I can see, there's no problem. That's why the 255 character "#" string is there. The "#" character was chosen simply to make the string visible to the eye. It has nothing to do with the Win API itself, because it doesn't matter what the buffer is filled with before the call. This is the string length limitation I mentioned earlier. You can pass strings longer than 255 characters into SetStringValue() but it will fail to read them.

Of course it is good to have no limitations, but I don't see how it is a great inconvenience. It begs the question: why do you need to read a string of a given size? If it's about constraints, you can get around them by writing a function which splits input string into N parameters which are 255 long + "remainder" parameter. And when reading it gathers it back. There is no other way. If you have difficulty, please contact me, I will do it. Simply, everyone has different needs, we can not provide everything, it is enough for me only this, and someone uses global variables, and even at several levels.

I'm confused... Where is the 255-character limit? I know for a fact that there is no such a restriction in MQL4.

The example code was a subtle hint at the point :-))

 
Zhunko >> :

Still, communicating through files is not the right tool. Not the right tool.

Files are invented to store information for a long time. Why torment the disk? There is RAM for communication.

I partly agree with you.

Through RAM you can, but it is difficult (after all, the forum is not 100% system programmers and not even 50%).

And if you look a little wider - in unix - all the files and RAM and disks and processes.

I just suggested 1 of many ways.

 
Zhunko >> :

I don't get it... Where is the 255 character limit? I know for a fact that there is no such limitation in MQL4.

The code sample was a subtle hint at the essence of the question :-))

Well, when during execution of the program you increment a string, there is no restriction, but then it turns out to be not a string constant anymore. The documentation is very clear about the length of string constants :

The string constant length is from 0 to 255 characters. If the string constant exceeds the maximum length, the unnecessary characters will be truncated to the right and the compiler will generate the corresponding warning.

 
Andres >> :

Well, there is no limitation when you increase the string during program execution, but then it is no longer a string constant. It's clearly written here in the documentation about the length of string constants:

In our case, it does not matter whether it is a constant or not.

So you can do more with a variable?

 
Zhunko >> :

In our case, it doesn't matter if it is a constant or not.

So you can do more, with a variable?

Why doesn't it matter? The point is that it is important (!), because with a buffer as a constant string API call works as it should, and with a buffer of "dynamically" created string API call works without errors, but we do not observe data from registry in this string, for the reasons described earlier.


Andres wrote >>
When during execution of program you must increase string, it has no limit, but then it turns out not to be string constant. The documentation says it's clear about the length of the string constants:

Here I was talking about string length limitation, not library limitation.

Try to get data from registry with string constant and with dynamically incremented string and you will see the difference. In the first case, the data comes in, in the second, it does not.

 
Andres >> :

Here I was talking about string length limitation, not library limitation.

Try to retrieve data from the registry using string constant and dynamically incremented string, and you will see the difference. In the first case data are received, in the second case they are not.

>>...weird!... So it turns out that it matters where in the function the memory is allocated?

 

The best way to exchange data between programmes, IMHO, is through virtual files:

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

}

//---

and so on.....

Everything works reliably and without glitches.... Tested electronically :)

 
klot >> :

The best way to exchange data between programmes, IMHO, is through virtual files:

and so on.....

Everything works reliably and without glitches.... Tested electronically :)

Absolutely right. FileMapping is a great tool, although not the easiest. You could also try pipes or mailslots.

12345678
New comment