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
Vasiliy!
Didn't wait for a reply from you. (don't know if MQ had time to implement changes in build 1100)
Decoder:
Callouts:
Vasiliy!
Didn't wait for a reply from you. (don't know if MQ had time to implement changes in build 1100)
Decoder:
Callouts:
Mikalas, is it possible to make the decoding and encoding code as a library with a check for unpacking completion?
Sure. That's what I'll be doing in the near future. There will be packing/unpacking. Adding and removing files from archive. The main thing is that CryptDecode doesn't fail.
Vasiliy!
Is ZIP packaging necessary?
I don't think it's worth it.
1. If you want to build a database based on ZIP, it won't be relevant.
Soon MQ will add standard functions to work with the database (Renat did a survey).
2. You can't solve the problem with file sizes larger than uint.
There should be ZIP64 compression for ulong sizes.
3. You don't know exactly how MT5 data is compressed
It is possible that large files ( even uint size ) will
large files ( even uint size ) will be compressed for HOURS!
4. To "cram" files into an archive, you will have to keep quite a lot of information in
a lot of information in memory - there will be HARDWARE!
I strongly advise against it....
I am probably thinking the old-fashioned way, but for me archiving is interesting to speed up data transfer on the Internet. Locally with large hard drives the file size loses its relevance, and the database will be for a limited range of people, and it is costly to implement, as it will require additional knowledge from the programmer and the user.
It is true that zip is considerably inferior to rar in the compression, especially of text - which is a little sad.
Vasiliy!
Is ZIP packaging necessary?
I don't think it's worth it.
I think otherwise.
1. If you want to build a database based on ZIP, it won't be relevant.
Soon MQ will add standard functions to work with database (Renat did a survey)
No, zip is not interesting as an alternative to DB. That's not why it's worth bothering with zip.
2. You cannot solve the problem with file sizes larger than uint.
There must be ZIP64 compression for ulong size.
I have no goal to create an analogue of WinZip or WinRar. Only the most basic archives. No one will even think of compressing files larger than 4 GB.
3. You don't know how exactly MT5 data is compressed.
It's possible that large files ( even uint size) will be
even uint size) will be compressed for HOUR!
4. To "cram" files into an archive, you will have to keep quite a lot of information in
a lot of information in memory - there will be HARDWARE!
I strongly advise against....
1. MQ doesn't do slow functions, and if it does, it optimizes them in a timely manner, based on requests from servicedesk. I'm somehow confident that CryptEncode will fly.
2. There won't be any slowdowns. You do not know what a modern MQL5 is capable of in terms of performance. Today's computers have too much memory. To download and pack a file of a couple of hundreds of megabytes is a piece of cake, and you don't need more. For these are other tasks.
Vasiliy!
Is ZIP packaging necessary?
I don't think it's worth it.
I think otherwise.
No, zip is not interesting as an alternative to DB. That's not why it's worth bothering with zip.
I have no goal to create an analogue of WinZip or WinRar. Only the most basic archives. No one would even think of compressing files larger than 4 GB.
1. MQ doesn't do slow features, and if it does, it will optimize their work in a timely manner, based on requests from the service desk. I'm somehow confident that CryptEncode will fly.
2. There won't be any slowdowns. You do not know what a modern MQL5 is capable of in terms of performance. Today's computers have too much memory. To download and pack a file of a couple of hundreds of megabytes is a piece of cake, and you don't need more. For these are other tasks.
I am probably thinking the old-fashioned way, but for me archiving is interesting to speed up data transfer on the Internet. Locally with large hard drives the file size loses its relevance, and the database will be for a limited range of people, and it is costly to implement, as it will require additional knowledge from the programmer and the user.
True zip is significantly inferior in compression, especially text, rar - which is a little sad.
Quite true. Communicating with a third-party server via WebRequest will be much faster using the packaging of sent information. This is another idea why reloading the packaging is a good solution.
However, zip is significantly inferior to rar in compression, especially of text - which is a bit unfortunate.
Appreciate what we have been given. Believe me, the ability to work with the most popular compression format covers 90% of all tasks. 80% of redundancy is successfully eliminated with zip. What comes next is chasing parrots which nobody needs.
Good riddance!