Working with files. - page 4
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
TheXpert:
OMG! Where the output is, it is nonsense. That's how we get the claims like "OOP is faster" or "indicators are slow, we should put the entire code into Expert Advisor".
I understand that everything does not work as planned. At least, the normal use of FileFlush() should be faster than FileClose().
But I still think that such things should not be put into loops; they will not be of much help anyway.
And if I understood correctly the example for MQL4, the call of FileFlush() is placed between two loops (it suggested to me that it would be a brake in a loop).
Thus, if I understand correctly the logic of developers, the file should be opened in OnInit / Constructor of main class (maybe not only in constructor) and closed in OnDeint / Destructive of main class.
Inall other cases instead of FileClose use FileFlush (after FileWrite and after loops).
TheXpert:
I swapped the lines according to the documentation:
Where is this written in the documentation?
There is such a phrase in MQL5 Reference:
FileFlush
Note
The FileFlush() function should be called between operations of reading from a file and writing to a file.
If "writing to file" == FileWrite() function , then read: "The FileFlush() function must becalled before the FileWrite() function". Or do you have a different opinion?
TheXpert:
But I still do not understand the sense of calling FileFlush() before FileWrite().
How can you make sense of something that doesn't have one? Return the order of the lines back to the home page and double-check it. Apparently the documentation didn't put it quite right.
It's good when you know in advance what makes sense and what doesn't when studying new material. Since nature has not endowed us with such talents, we have to "take each new height", test, interpret documentation and results. I'm not even sure if the tests themselves are written correctly. At first I intuitively put FileFlush() after FileWrite(), but after re-reading the Handbook I deleted that example.
TheXpert:
Interesting:
OMG! It's absurd where the output is. This is how we get the claims like "OOP is faster" or "indicators are slow, we should put the whole code into Expert Advisor".
It would be nice if every evaluation of "your output is stupid" were followed by the explanation of what is stupid about it :) Otherwise, it is unclear in what direction to move inquisitive with such a strictness of the judiciary :)
There is no point in flushing out the changes before they appear, as they are not there yet :)
... Well, the course is clear - we are waiting what the developers will say if some problem is really detected.
There is such a phrase in MQL5 Reference:
If "write to file" == FileWrite() function , it reads: "The FileFlush() function must be called before the FileWrite() function".Or do you have a different opinion?
Let's analyze "rather unfortunate" description and example of this function for MQL4.
Resets to disk all data remaining in the file I/O buffer.
Note: The FileFlush() function must be called between file read and write operations.When the file is closed, the data is automatically flushed to disk, so there is no need to call FileFlush() before calling FileClose().
The line marked here is the argument of the necessity to place FileFlush call in the loop before writing into the file.
But if we understand this comment word for word we will get the following:
the FileFlush() function must be called between the operations of reading from the file (while reading is FileReadXXX) and writing to the file (writing is connected with FileWrite and FileWriteXXX).
When closing the file (read - when FileClose is executed), the data is dumped to disk automatically (read - when FileFlush is executed automatically).
I think the developers didn't care much about the correctness of reading the help even in the MQL4 version; it's even ridiculous to speak about putting the truncated part into MQL5.
At least the second sentence in the comment above should look as follows in my opinion:
It's a little messy too, but from some point of view it explains why FileFlush should not be used before closing the file using FileClose.
The example is not so simple, the text says about one thing (use between read and write operations), while the example describes use between two loop write operations (work inside loops by the way is not considered in help at all).
Thus, at a minimum, the following should be added:
1. a description of what this input/output buffer is and what actually happens in it between opening a file, reading a data block, writing a data block and closing the file.
This most likely refers to the entire section on file operations.
2. Give a normally understood example (can be class-based) of how to correctly use FileFlush call for single file access (e.g. writing timer value).
3 Provide a normal example of a call when working with arrays. As far as I understand, the example described in the MQL4 Reference refers to working with large arrays, but illustrates it incorrectly (in a word - why write twice a fairly large amount of identical data to the file, if it can be done several times?)
The line highlighted here is your argument for the need to call FileFlush in the loop before writing to the file.
But if we understand this comment word for word we get the following:
the FileFlush() function must be called between the operations of reading from the file (while reading is FileReadXXX) and writing to the file (writing is connected with FileWrite and FileWriteXXX).
When closing the file (read - when executing FileClose) the data will be automatically flushed to the disk (read - when executing FileFlush).
I see what you mean. I'm sorry, that unknowingly I equated the "read from file" operation to FileOpen() function (my Expert Advisor will read only from OnInit(), while during processing of ticks and custom events - only write; for this reason I haven't considered functions like FileReadXXX() in the loop). Nevertheless, FileFlush() before FileWriteXXX() - the principle is the same in both references. And it wasn't argumentation in its classical meaning (as a reasoning of my position), but simply an answer to the question why I made that phrase.
Anyway, if the developers don't reply here, I'll post a request tonight, with a link to the discussion and intermediate results. Even two applications are needed: 1) "bug - not a bug" and 2) changes in documentation. Would you like to make the second application yourself, since you have dug so deep into the topic?
I see what I am thinking. I confess, that unknowingly I equated operation "read from file" to function FileOpen() (my Expert Advisor will read only from OnInit(), while during processing of ticks and user events - only write; for this reason I haven't considered functions like FileReadXXX() in the loop). Nevertheless, FileFlush() before FileWriteXXX() - the principle is the same in both references. And it wasn't argumentation in its classical meaning (as a reasoning of my position), but simply an answer to the question why I made that phrase.
Anyway, if the developers don't reply here, I'll write a request tonight, with a link to the discussion and intermediate results. Even two applications are needed: 1) "bug - not a bug" and 2) changes in documentation. Would you like to make the second request yourself, since you dug so deeply into the subject?
1. Is it so deep? I would probably be glad to do it, if I understood what developers want to say and where.
Sometimes there is a mention of an I/O buffer but no proper description of it. Or does everyone here know what the FILE I/O buffer is?
Is it difficult to add a normal description of this issue in the chapter on file operations? Or google all over the world looking for an answer to what the developers had in mind?
I understand that the size of the help is limited, but why should we make fun of those who are just starting to learn MQL?
2. Why any mention of this buffer I found only in Help for this function, why it's not mentioned elsewhere in the section on file operations?
3. Let's assume I have some idea of this very buffer of input/output approximately in this form
The notion of input-output buffer is connected with the file system. Input and output data are carried out through this buffer.
Bufferis an area in memory which is allocated for each file.
At record in a file all information at first is directed to the buffer and there accumulates until all volume of the buffer will not be filled. Only after that or after special command of dump (e.g. FileClose or FileFlush). the data is transferred from the buffer to the file.
When reading from a file, the data is first read into the buffer, and not as much data is read as is requested, but as much as will fit in the buffer.
And do developers really think that this is all information that can be interesting for a newcomer studying MQL (if only this definition can be considered valid for this language)?
For example, I was wondering what is the size of this buffer and how it is defined.
In my opinion, all this information, and not only this, should be in the language documentation (there, and not in various articles and discussions on the forum).
Why doesn't the script return the actual"Last Read Date" of the file?
Why doesn't the script return the actual"Last Read Date" of the file?
Last access, not read access.
OK, as you may have noticed, in my question I quoted the phrase verbatim from the documentation:
ENUM_FILE_PROPERTY_INTEGER
Identifier
Identifier description
FILE_EXISTS
Existence check
FILE_CREATE_DATE
Date of creation
FILE_MODIFY_DATE
Last modification date
FILE_ACCESS_DATE
Date of last read
Question 1: Do you think there is a typo in the documentation, and that instead of "Last Read Date" it should be something like "Last Open Date"? At least from your answer, you can see that "read file" and "access file" operations mean different things to you.
Further. If you restart the attached script several times, you will see approximately the same behavior:
That is, when running the script for the first time, the third call toFileReadInteger() takes place at21:34:06, but the date of the last read/access is different -21:33:57.However, the second script run (37 seconds later) shows that the first call of theFileReadInteger() function resulted in 21 : 34: 06, i.e. the time of the last call of theFileReadInteger() function during the previous script run.
Furthermore, the second launch of the script at 21:34:43 occurs, which means that the "reopening of a handle", as you call it, occurred at the same time. But after such a "handle reopening" returns21:34:06, i.e. a completely different time to what you are talking about.
Question 2: how should this be interpreted?
Reopen the handle and you'll be happy.
In the current situation, good news is expected when file properties are retrieved without "reopening" the handle.