It's amazing how this trick worked at all for someone. With such glitches inside... Below is a fragment from CMemMapApi::Write() ArrayResize(src, size); memcpyX(src, view, size); // took the bytebuffer for(int i=0; i
Unfortunately, FileMapping has one significant disadvantage. If the child application (reading data) has not finished its work correctly for some reason ( kernel32 ::UnmapViewOfFile and kernel32::CloseHandle calls) , the "file" remains hanging in memory until all processes from where it was opened are closed ( kernel32::OpenFileMappingW and kernel32::MapViewOfFile calls). In particular, you cannot change its size - reopen it (close and reopen).
Ihave not found a solution to the problem. It is hard to run into such a situation with this library, because every action in it starts with opening and ends with closing. This is why it is so slow. But you may still encounter this error. And then the MQL-program will crash with this message.
поэтому он должен оценить x и ввести значение в ST2 для структуризации. с технической точки зрения При использовании одноуровневой индирекции ST2 x строчит имя введенного макроса но при использовании двойного слоя он строчит значение введенного макроса
I'm trying to check the work of this example https://www.mql5.com/en/code/818
I am using MT5 Version: 5.00 build 5370 17 Oct 2025.
For some reason I get errors when trying to compile the memmap.mq5 file:
memmap.mq5
MemMapLib.mqh
wrong parameters count, 4 passed, but 3 requires MemMapLib.mqh 2799
long CMemMapFile::Open(string,int,int) MemMapLib.mqh 25119
call resolves to 'long CMemMapFile::Open(string,int,int)' instead of 'long CMemMapApi::Open(string,int,int,int&)' due to new rules of method hiding MemMapLib.mqh 2799
see declaration of function 'CMemMapFile::Open' MemMapLib.mqh 25119
see declaration of function 'CMemMapApi::Open' MemMapLib.mqh 12219
wrong parameters count, 3 passed, but 1 requires MemMapLib.mqh 2929int CMemMapFile::Fill(uchar) MemMapLib.mqh 25314
call resolves to 'int CMemMapFile::Fill(uchar)' instead of 'int CMemMapApi::Fill(long,uchar,int&)' due to new rules of method hiding MemMapLib.mqh 2929
see declaration of function 'CMemMapFile::Fill' MemMapLib.mqh 25314
see declaration of function 'CMemMapApi::Fill' MemMapLib.mqh 12414
wrong parameters count, 4 passed, but 1 requires MemMapLib.mqh 29916int CMemMapFile::Grows(int) MemMapLib.mqh 25514
call resolves to 'int CMemMapFile::Grows(int)' instead of 'long CMemMapApi::Grows(long,string,int,int&)' due to new rules of method hiding MemMapLib.mqh 29916
see declaration of function 'CMemMapFile::Grows' MemMapLib.mqh 25514
see declaration of function 'CMemMapApi::Grows' MemMapLib.mqh 125193 errors, 3 warnings 33
Can anyone tell me what I am doing wrong? And how to fix it?
fxsaber #: The library sources do not meet the current requirements of the MQL5 language.
Is there any way to correct it? Or is it necessary to rework all the sources and it is impossible to do it without the author? I think the compiler generated only 3 errors here. It would be great if it could be corrected.
Is there any way to fix it? Or is it necessary to rework all the sources and it is impossible to do it without the author? I think the compiler gave only 3 errors here. It would be great if it could be corrected.
And here I have already corrected the code myself. Those who need it can use it. The Expert Advisor compiles successfully with it.
I added this starting from line 251:
using CMemMapApi::Open;
using CMemMapApi::Close;
using CMemMapApi::Fill;
using CMemMapApi::Grows;
using CMemMapApi::Write;
using CMemMapApi::Read;
It was necessary to transfer huge amounts (gigabytes) of data. Implementation through this library, unfortunately, showed super-low performance.
I had to completely redo it using the original DLL set. It worked quickly.
Unfortunately, FileMapping has one significant disadvantage. If the child application (reading data) has not finished its work correctly for some reason ( kernel32 ::UnmapViewOfFile and kernel32::CloseHandle calls) , the "file" remains hanging in memory until all processes from where it was opened are closed ( kernel32::OpenFileMappingW and kernel32::MapViewOfFile calls). In particular, you cannot change its size - reopen it (close and reopen).
Ihave not found a solution to the problem. It is hard to run into such a situation with this library, because every action in it starts with opening and ends with closing. This is why it is so slow. But you may still encounter this error. And then the MQL-program will crash with this message.
For some reason I get errors when trying to compile the memmap.mq5 file:
Can anyone tell me what I am doing wrong? And how to fix it?
The library sources do not meet the current requirements of the MQL5 language.
Is there any way to correct it? Or is it necessary to rework all the sources and it is impossible to do it without the author? I think the compiler generated only 3 errors here. It would be great if it could be corrected.
Is there any way to fix it? Or is it necessary to rework all the sources and it is impossible to do it without the author? I think the compiler gave only 3 errors here. It would be great if it could be corrected.
And here I have already corrected the code myself. Those who need it can use it. The Expert Advisor compiles successfully with it.
I added this starting from line 251: