Buggish interaction between winfile_v600.mqh and PrintFormat
I have now posted this question on the Russian forum, both in English and in Russian.
Let's see if they answer.
Best regards to all!
It was the reply from one user in Russian forum (this user reproduced your issue, and he is asking admins to fix it):
Forum on trading, automated trading systems and testing trading strategies
New Version of MetaTrader 5 Build 2650: Background Chart Loading and Improvements in MQL5 Profiler
fxsaber , 2020.10.22 07:31
This strange crash is reproducible on the b2560. Interestingly, after the crash, the created file cannot be deleted - it is used by another process. It would be nice to fix that too.
for information.
Forum on trading, automated trading systems and testing trading strategies
New Version of MetaTrader 5 Build 2650: Background Chart Loading and Improvements in MQL5 Profiler
Slava , 2020.10.22 12:44
The very first thing is that the FileHandle type must be long, 64-bit, since you are working on a 64-bit system.
#import "kernel32.dll" long CreateFileW( string Filename, uint AccessMode, int ShareMode, int PassAsZero, int CreationMode, int FlagsAndAttributes, int AlsoPassAsZero); int WriteFile( long FileHandle, uchar & Buffer[], int BufferLength, int & BytesWritten[], int PassAsZero); int CloseHandle( long FileHandle); #import
Thank you so much, but this does not resolve the problem, unfortunately.
Thank you so much, but this does not resolve the problem, unfortunately.
If not so you can repeat your post with this issue.
Thank you so much, but this does not resolve the problem, unfortunately.
More reply:
Forum on trading, automated trading systems and testing trading strategies
New Version of MetaTrader 5 Build 2650: Background Chart Loading and Improvements in MQL5 Profiler
Slava , 2020.10.23 08:47
#import "kernel32.dll" long CreateFileW( string Filename, uint AccessMode, int ShareMode, long PassAsZero, int CreationMode, int FlagsAndAttributes, long AlsoPassAsZero); int WriteFile( long FileHandle, uchar & Buffer[], int BufferLength, int & BytesWritten[], long PassAsZero); int CloseHandle( long FileHandle); #import
Ah ah ah ah! THIS now resolves the problem!
So, finally, the problem resolves by understanding the correct datatypes to be transferred to the win32 API.
Perhaps then, for the people that could need it in the future, these are the discoveries of this exercise. And I add also the BOOL story, that is present in other posts, trying to collect information in one place:
DATATYPE CORRESPONDENCE:
| Win32 API | Mql5 run on 32-bit system | Mql5 run on 64-bit system |
|---|---|---|
| HANDLE | int (4 bytes) | long (8 bytes) |
| LPSECURITY_ATTRIBUTES | int (4 bytes) | long (8 bytes) |
| LPOVERLAPPED | int (4 bytes) | long (8 bytes) |
| BOOL (4 bytes) | NOT bool (1 byte) BUT int 0 = false; int >0 = true | NOT bool (1 byte) BUT int 0 = false; int >0 = true |
If some expert wants to go on in filling this table it would be great. Alternatively, if anybody knows where to find such kind of information in a more professional and complete way, I think it could be useful for the whole community posting such a link in a very visible way on the forum!
Thank you a lot for your very nice support!
Ah ah ah ah! THIS now resolves the problem!
So, finally, the problem resolves by understanding the correct datatypes to be transferred to the win32 API.
Perhaps then, for the people that could need it in the future, these are the discoveries of this exercise. And I add also the BOOL story, that is present in other posts, trying to collect information in one place:
DATATYPE CORRESPONDENCE:
| Win32 API | Mql5 run on 32-bit system | Mql5 run on 64-bit system |
|---|---|---|
| HANDLE | int (4 bytes) | long (8 bytes) |
| LPSECURITY_ATTRIBUTES | int (4 bytes) | long (8 bytes) |
| LPOVERLAPPED | int (4 bytes) | long (8 bytes) |
| BOOL (4 bytes) | NOT bool (1 byte) BUT int 0 = false; int >0 = true | NOT bool (1 byte) BUT int 0 = false; int >0 = true |
If some expert wants to go on in filling this table it would be great. Alternatively, if anybody knows where to find such kind of information in a more professional and complete way, I think it could be useful for the whole community posting such a link in a very visible way on the forum!
Thank you a lot for your very nice support!
Hello
I have applied this suggestion and it works for me, to read, (possibly), because when I print what I read, I receive some characters in Chinese
If I use the OpenFile version that comes by default in MQL5, something similar happens to me, but in OPENFILE, I can add the FILE_ANSI flag and it solves it
So I ask, how can I add FILE_ANSI or something similar in the FILE_CREATE_W or READ_FILE of Kernel32.dll??
I will be very attentive
Thank you
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Hallo people,
I was testing in mql5 the mql5-slightly-modified winfile_v600.mqh library provided to the community by the Mighty JC (https://www.mql5.com/en/forum/150831).
Now look at this strange behavior: if I write something like
the script works wonderfully. The TestWinfile600.txt file is created in its directory and the test string inserted in it...
Now let's make just a VERY LITTLE MODIFICATION:
Well: this is what you get in your Terminal Expert log:
Is there any Guru explaining what is going on here? If I remove the PrintFormat statement everything turns back to normal. Is this a bug in PrintFormat? Is this a strange interaction with the Win32 API? How to avoid it?
The thing seems to be quite nasty, because I wanted to include these WIN32 API functions into my library. And it looks like that ANY PrintFormat statement around the library will cause the winfile functions getting scrambled and crashing memory! (Of course I don't want to re-write the whole library without them, and... yes it would be a huge problem for encapsulation...).
[Without telling about how long it took tracing the problem down to this... bug?]
I am using MT5 5 Build 2650 on a Windows10 mounted on 64-bit (x64) Intel.
Thank you so much.