My approach. The core is the engine. - page 87
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
s.s. Specifically on the subject of storing strings in MT objects, there's one weird glitch. If you start compressing the data and use unprinted characters in the object name, in some cases you won't be able to access that object. The glitch is probably still there because it's very specific and not many people know about it, but you might stumble upon it nonetheless.
I see. Only practice will help to figure it out definitively.
Dear opponents.
Here is the script code which:
Result:
Peter, you're testing the wrong thing in the wrong place. What you're testing should have about the same speed in terms of string logic.
You completely misunderstood my message.
My message was that you should stop using strings to pass double,long,time,int etc. And if you need to pass text, then translate a text string to uchar array. And all mixed data of different types via union data structures or arrays of these structures, converted to uint arrays via union, should be passed through resources, and on the receiving side these uint arrays should be converted back via union to the original structures. Believe me, Peter, thongs are very slow, you should always avoid them where possible. String is needed only for text and print output.
And in your example you've got the notion of performance measurement completely wrong.
Especially via the OBJPROP_TEXT property you can pass a string with a maximum size of 63 bytes. This is nothing.
Although your example makes no sense at all, but I modified it to something more correct purely for demonstration purpose and this is what I've got when copying 1000 different strings with size 63 bytes:
The script code is attached. It works on both MT4 and MT5
MT4:
MT5:
It seems that MT5 is asynchronous, so your method is 100 times slower and not suitable for MT5 at all. You should more and more focus on MT5
And what is it?
You should at least read the Help
Dear opponents.
Here is the script code which:
Result:
Read carefully and conclude: https://docs.mql4.com/ru/basis/types/stringconst
don't agree. We need uchar array for string as an intermediate. And there is no conversion, just copying bytes.
I don't agree. We need a uchar array for the string as an intermediate. And there is no conversion, just copying of bytes.
Try to use Cyrillic characters. And compare character codes in uchar array and in string, string is like ushort array.
I know what unicode is. But in our case we need uchar array only to get uint array through union to pass it further through the resource and when getting back chain of string recovery. There will be no losses. And in this case we do not need to extract characters from uchar array.
Encoding can be changed and is non-unicode by default.
Peter, you're testing the wrong thing in the wrong place. What you're testing should have about the same speed in terms of string logic.
Nikolai, with all due respect, that's empty words for nothing. I have measured and attached a script. "The right way, the wrong way...", "should have approximately the same speed in terms of string logic"... Just words.
Nikolai Semko:
...
You completely misunderstood my message.
My message was that you should stop using strings to pass double, long,time, int etc. And if you need to pass text, then convert a text string to uchar array. And all mixed data of different types via union data structures or arrays of these structures, converted to uint arrays via union, should be passed through resources, and on the receiving side these uint arrays should be converted back via union to the original structures. Believe me, Peter, thongs are very slow, you should always avoid them where possible. String is needed only for text and print output.
That's exactly your message I understood perfectly. AND IT'S WRONG.
Why? - Because you would have to complicate the system of working with control parameters a LOT. The architecture of storing, passing and managing parameters will become TUCH more complicated and confusing, which will lead to a lot of problems and an overall slowdown.
You don't understand the internal architecture. You don't know how programs interact, manage parameter values according to their type and properties. What you propose would make things a lot more complicated and confusing. And it won't solve the communication problem. It will still remain crutchy.
...
All the more you can pass a string with a maximum size of 63 bytes through the OBJPROP_TEXT property. That's nothing.
Although your example makes no sense at all, I reworked it to something more correct purely for demonstration purposes, and here's what I got when copying 1000 different strings with size 63 bytes:
...
You can pass a string of 64 characters through the description of one MT-object. That's enough. I need - 20-30 lines to transfer data of big tables. Without large tables, I need 2-3 lines at most.
I am interested in MT4 at the moment.
MT5 is developing all the time. Developers can just add common memory of MT-programs (so they don't have to fuss with resources) and the question will be removed.
Nikolai Semko:
...
My message was that we should stop using strings to pass double,long,time,int etc.
...
How do you transfer double,long,time,int etc... ???
All the same we need to convert it to string and then to char to write it into the resource.
Or do you suggest using lparam,dparam ?
That is, overload the event queue...
Also, in your measurements, you forgot to add the time to save and read the resource...
So, even if you write 1000 lines (which is really better to pass through the resource), you don't gain in speed, due to the cost of saving and retrieving from the resource.