My approach. The core is the engine. - page 86

New comment
 
Peter, I understand from the ellipse gif that the form is one solid canvas? And how do dropdown lists work? I'm interested in the case where the drop down list is bigger than the size of the form.
 
Vasiliy Sokolov:

Let me put it this way - I don't like some of the sloppiness of my solution myself. You have to create MT objects. But, in reality, it's just a bias. What difference does it make? You don't need more than 20 -30 of them for a complete transfer.

30*64 characters = 1920 characters. This is enough to transfer large table data.

 
Dmitry Fedoseev:
Peter, I see from the ellipse gif that the form is one continuous canvas? And how do the dropdown lists work? I'm interested in the case where the drop down list exceeds the size of the form.

Yes, the form is a single kanvas. The constructor writes the names of the canvas itself and makes wrapper functions to work with it.

The dropdown lists work in the area outside the window as well. This is implemented.

The drop-down list is another kanvas. It appears and disappears when the button is clicked.

 
Vasiliy Sokolov:

Direct mapping of structures via union to byte array, shared for global access. I don't know if this is technically feasible, but if so, the speed would be cosmic, as you wouldn't have to copy anything at all.

I would gladly accept this solution if you provide an example.

 

Be careful with data exchange via graphical objects :-)

otherwise you can easily make your Expert Advisor look like "cannot be optimized"...

 
Реter Konow:

My solution is the best option under the initial conditions.

What is a string:

  1. No fixed size. As a consequence, it is impossible to organise an array of strings, and to access an arbitrary string in that array;
  2. Complete absence of data typing in strings. You have to define a subtype dynamically inside the string parsing. You waste precious time on parsing needed tokens; and if lexemes contain errors, the string doesn't control it in any way. You get a string and pray that it is correct;
  3. Low efficiency of storing information per byte. Service string like "opt=1;cancel=3" at best use 35-40 characters (bytes) out of 256 possible (17%). In order to send 100 bytes of information you should form a 588-byte string, overloading the communication channel. If you compress the characters, it makes the code very complicated. If you abbreviate variable names, it helps only a little.

And despite all these obvious things, you're like Robin Hood , still proclaiming how fast and accurate you are, and how well you guessed the string. No, I didn't, and it's all very unhealthy.

Don't try to ride your gut where fundamental knowledge is needed.

 
Vasiliy Sokolov:

What is a string:

  1. There is no fixed size. As a consequence, it is impossible to organise an array of strings, and to access an arbitrary string in that array;
  2. Complete lack of data typing in the string. You have to define a subtype dynamically inside the string parsing. You waste precious time on parsing needed tokens; and if lexemes contain errors, the string doesn't control it in any way. You get a string and pray that it is correct;
  3. Low efficiency of storing information per byte. Service string like "opt=1;cancel=3" at best use 35-40 characters (bytes) out of 256 possible (17%). In order to send 100 bytes of information you should form a 588-byte string, overloading the communication channel. If you compress the characters, it makes the code very complicated. If you abbreviate variable names, it helps only a little.

And despite all these obvious things, you're like Robin Hood , still proclaiming how fast and accurate you are, and how well you guessed the string. No, I didn't, and it's all very unhealthy.

Don't try to ride your gut where you need to know the fundamentals.

Vasily, don't you think the MT developers took the string issues into account when preserving the description of MT objects?

It is much cooler to ride on someone else's fundamental knowledge and using your intuition to achieve even more.

 
Реter Konow:

Vasiliy, don't you think that MT developers took into account problems of strings, when storing MT object description?

Peter, every data storage algorithm has its weaknesses and strengths. The developers certainly took a lot of things into account, and they're certainly good, but fundamentally strings will always remain strings.

 
Vasiliy Sokolov:

Peter, every data storage algorithm has its weaknesses and strengths. The developers, of course, took a lot of things into account, and they are certainly good, but fundamentally, strings will always remain strings.

Vasily, if practice shows my solution to be flawed, I will abandon it. And I will take Nikolai's solution. If it's bad too, I'll return to OnChartEvent() and say that nothing can be done.

However, there's no reason to believe that the implementation of my solution will be lame yet.

We'll soon find out.

 
z.s. Specifically on the subject of storing strings in MT objects, there's one weird glitch. If you start compressing data and use unprintable characters in the object name, in some cases you won't be able to access this 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.
1...798081828384858687888990919293...184
New comment