Questions from a "dummy" - page 204
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
I tried to look through the hcc history files for interest.
It turns out that the line of data records inside the hcc binary starts with FileSeek(handle,15333,SEEK_SET) , and looks like
4 byte int Separator
4 byte int datetime
8 byte double Open
8 byte double High
8 byte double Low
8 byte double Close
1 or 2 byte int TickVolume
1 or 2 byte int Spread
and up to 4 byte Volume
And the length of last two or three int's is determined by the first Separator, as far as I understood. I just don't understand how? Could you please tell me how to determine 1 or more byte will be last 2-3 int's?
A hint please...
I think I guessed it - Separator contains data reading structure in 16 byte code. Like Separator=18385028, in 16th from the lowest bit 4888811, that is 4 byte, 8 byte .... 1 byte.
Does this seem to be the case?
P.S. This is exactly how the files are read, only you have to skip 189 bytes between days.
Now I understand why developers do not make these files public. It is not only about synchronization with server, but it seems that they are afraid to be reproached for structure and organization of files, like real "Woe from Wit". They are too cheap to add Aski, but for all sorts of reinsurance against nonsynchrony, well, they made a whole atom ship "Lenin". I personally do not understand all these perversions and are sad.
I now understand why the developers do not make these files public. It is not only about synchronization with the server, but it seems that they are afraid to be reproached by the structure and organization of the files, like a real "Woe from Wit". They are too cheap to add Aski, but for all sorts of reinsurance against nonsynchrony, well, they made a whole atom ship "Lenin". I personally don't understand and feel sad about all these distortions.
*.HCC files are compressed blocks of data, which means they are not directly readable.
These files serve as input data to create compressed working timeframes, which are placed in the /cache subdirectory.
*.HCC files are compressed data blocks, which means that they are not readable directly.
These files serve as source data for the creation of uncompressed working timeframes, which are placed in the /cache subdirectory.
Renate. Why did they make it so complicated? Is it justified? I'm not a programmer and maybe I'm missing something, but looking at the order of entries is just creepy. Is it convenient for your own work?
Actually, of course, I was looking at it to see if I could overwrite hcc files. But after looking at their complexity, I don't want to parsing them further. Right now I'm looking at FXCM quotes on demo. But for some reason, the history is only from October. I have an account with them, but without markup with commission. I've been using their API to download TS2 minutiae for years and I've been using Asks as well. I wanted to implement them in MT5 to make my tests more realistic. But now I don't feel like it. If developers don't provide us with the full structure of hcc files we will have to make tests in MT4 using scripts reading real data with Askas from available history files. By the way, FXOpen gives the history with Askas directly in MT4. That's great. It's a pity they cannot be used in the tester. But at least one can test it with scripts.
I tried to look at the hcc history files for the sake of interest.
It turns out, that data record line inside hcc binary starts with FileSeek(handle,15333,SEEK_SET)
and what is in these first 15333 bytes, could you figure it out?
I think I've guessed it - separator contains structure of reading data in 16-bit code. Like Separator=18385028, in 16th from the lowest bit 4888811, that is 4 byte, 8 byte .... 1 byte.
Does this seem to be the case?
hmm, looks like it. it turns out the file is read block by block, varying the size of the block depending on the separator specified.
P.S. That's exactly how files are read, only between days you have to skip 189 bytes.
I noticed that the days really start with the "header". In which the name of the character, etc. goes. Probably this hat gives some quantitative information about the data contained in this day block.
PS
Don't give up on the subject, because it is very interesting to create your own minutes. Unless, of course, the terminal will overwrite them during another synchronisation with the server.We have a very efficient compression format; without it, there would be many times more network traffic.
I am working on non-Russian Windows, set MetaEditor's language to Russian, but when I call help (F1), it pops up in English. Can you tell me if there is anything else that should be changed to Russian, so that the help would pop up in Russian. I use Russian Windows at home and everything is all right.
And look in the directories, do you have a Russian-language Handbook file there?
I work on non-Russian Windows, set MetaEditor's language to Russian, but when I call help (F1), it pops up in English. Do you know, is there anything else, which should be changed to Russian, to make help appear in Russian? At home I use Russian Windows and everything is normal.
After changing language in MetaEditor, did you restart it?
We will check it.