Errors, bugs, questions - page 2239

New comment
 
Stanislav Korotky:

I read MSDN too. Explain, is it Microsoft doesn't know English or they don't read their documentation themselves, or the last option - the flags in MQL are named similar to WinApi but work differently?

Taken from here - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ -Enables subsequent open operations on a file or device to request read access.Otherwise, other processes cannot open the file or device if they request read access.

FILE_SHARE_WRITE -Enables subsequent open operations on a file or device to request write access.Otherwise, other processes cannot open the file or device if they request write access.

Therefore, the first program only needs to set FILE_SHARE_READ for the second to read. FILE_SHARE_WRITE only if you know that the second program will also write to the file.

Can you give an example of the difference in behavior?


From the link provided, the description of the flags does not give an idea of how to use them correctly when trying to open the same file more than once.

Based on the data in your description, try to answer the question, would the fourth (hread_1) and fifth (hread_2) in the example below be valid?

   HANDLE hwrite     =::CreateFile(L"test.txt", GENERIC_WRITE,FILE_SHARE_READ,                   nullptr,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,nullptr);

   HANDLE hread_fail =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_READ,                   nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);
   HANDLE hread_ok   =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_WRITE,                  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);

   HANDLE hread_1    =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_WRITE,                  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);
   HANDLE hread_2    =::CreateFile(L"test.txt", GENERIC_READ, FILE_SHARE_WRITE|FILE_SHARE_READ,  nullptr,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,nullptr);

I'll tell you the answer right away: these calls will be invalid

 
Stanislav Korotky:

I read MSDN too. Explain, is it Microsoft doesn't know English or they don't read their documentation themselves, or the last option - the flags in MQL are named similar to WinApi but work differently?

Taken from here - https://docs.microsoft.com/en-us/windows/desktop/api/FileAPI/nf-fileapi-createfilea

FILE_SHARE_READ -Enables subsequent open operations on a file or device to request read access.Otherwise, other processes cannot open the file or device if they request read access.

FILE_SHARE_WRITE -Enables subsequent open operations on a file or device to request write access.Otherwise, other processes cannot open the file or device if they request write access.

Therefore, the first program only needs to set FILE_SHARE_READ for the second to read. FILE_SHARE_WRITE only if you know that the second program will also write to the file.

To avoid confusion with these flags, just make sure that when we open a file, these flags allow other processes to read and/or write, not ourselves.

 
Alexey Viktorov:

To avoid confusion about these flags, it is enough to firmly understand that when we open a file, these flags allow other processes to read and/or write, not ourselves.

That's exactly what I'm saying, that's exactly how I understand MS documentation (in particular, the one who opens a file for writing can allow others to share reading). The recommended flagging technique does the opposite - the second process uses the write-share flag to authorize reading the file being written (i.e. it sort of bypasses the first process to authorize reading, even though the first process has not implemented write-share permission). This even sounds unnatural. Anyway, I'm off to read the interpretations.

 
Stanislav Korotky:

That's exactly what I'm saying, that's how I understand MS documentation (in particular, whoever opens a file for writing can allow others to read it together).

Not only reading can be allowed, but also writing. And if there will be any shared writing, each process should have shared write permission.

Stanislav Korotky:

The use of flags which is recommended to solve this problem assumes the opposite - that the second process uses the write-flag to authorize itself to read the file being written (i.e. it sort of bypasses the first process by raising its authorization, even though the first process has not specified write-share permission). This even sounds unnatural. Anyway, I'm off to read the interpretations.

And this is wrong. Self never allows anything or raises any rights to itself. The FILE_SHARE_READ and FILE_SHARE_WRITE flags refer to attributes of an open file. If the attributes do not include permission from the process that already has the file in use, the file cannot be used until it is released.

That's how it works in those examples: The first opened file for writing, allow other processes to read, and the second when you open it tries to prohibit (not allow) to write to the one who is already using the file. Here is where it gets a bummer... It is like, who got up first, who walks away...

 
Alexey Kozitsyn:

Question for the developers.

There is a synchronisation function:

I sometimes get this error with it:

I.e. the indicator runs on USDJPY, and I get an error with EURGBP symbol. At the same time there is an open EURGBP chart in the terminal.

Error 4014 says that:

System function is not allowed to be called

How can it be?

It's that it was generated by some other call.

Use ResetLastError() before calling SymbolIsSynchronised

 
Slava:

And so it was generated by some other call.

Use ResetLastError() before calling SymbolIsSynchronized

Yes, I already did... It turns out that if it is not clearly written in the function documentation that GetLastError() must be called in case of an error, it means that the function does not reset the error code. Right?

 
Slava:

Also, I would like to know what functions could potentially cause this error to appear in the indicator?

 
A100:
In my case ServiceDesk now writes that it cannot play... accordingly the help of the room is required ... a little later I will describe in detail what and how

So on request #1530548 ServiceDesk cannot reproduce error https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 even though I have steady playback even now (in build 1881). With a bit of thought I figured out why! The answer is: because I have a slow computer (tablet)

I had the same situation in case #1952509 with this problem https://www.mql5.com/ru/forum/1111/page2124#comment_6518537

ServiceDesk also reported at first that it couldn't reproduce the error. It took me a lot of effort to convince myself that there was an error after all... in the end:

Support Team 2018.02.10 22:35
Seems to have reproduced your problem back on Friday on a weak machine with 39 charts.
We'll keep an eye on it. Will request additional data if required. Thank you.

This raises the question: Is it necessary to bother with such errors at all? Or just let them live their lives in peace ... maybe they won't pop up again - it's enough to have a fast computer, right?

These questions arise in the context that a dozen other charts with several EAs/indicators may turn a fast computer into a slow one (and an average trader uses exactly a lot of EAs - for example https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 EAs are running)... Or even a slow computer may become slow for a short time due to other circumstances (antivirus... other programs... or the system itself has temporarily taken over almost all resources).

And then exactly that unexplained 1 in 100 failure will happen (and by the laws of nature it naturally occurs at the most inopportune time).

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2016.08.03
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 
A100:

So on request #1530548 ServiceDesk cannot reproduce error https://www.mql5.com/ru/forum/1111/page1628#comment_2702870 even though I have steady playback even now (in build 1881). With a bit of thought I figured out why! The answer is: because I have a slow computer (tablet)

The same situation was in application #1952509 for this problem https://www.mql5.com/ru/forum/1111/page2124#comment_6518537

ServiceDesk also reported at first that it couldn't reproduce the error. It took me a lot of effort to convince myself that there was an error after all... in the end:

Support Team 2018.02.10 22:35
Seems to have reproduced your problem back on Friday on a weak machine with 39 charts.
Will keep an eye on it. Will request additional data if required. Thank you.

This raises the question: Is it necessary to bother with such errors at all? Or just let them live their lives in peace ... maybe they won't pop up again - it's enough to have a fast computer, right?

These questions arise in the context that a dozen other charts with several EAs/indicators may turn a fast computer into a slow one (and an average trader uses exactly a lot of EAs - for example https://www.mql5.com/ru/forum/267154/page5#comment_8164924 - 82 EAs are running)... Or even a slow computer may become slow for a short time due to other circumstances (antivirus... other programs... or the system itself has temporarily taken over almost all resources).

And then exactly that unexplained 1 in 100 failure will happen (and by the laws of nature it naturally occurs at the most inopportune time).


I don't have a weak computer. But this file opening error also occurs from time to time.

 
Vladislav Andruschenko:
I don't have a weak computer. But this error with opening a file also occurs from time to time.
All the more so because you are not an ordinary user, and your work is used by many, many people
1...223222332234223522362237223822392240224122422243224422452246...3190
New comment