
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
Briefly, about engineering :
If there is an urge to improve some "A" by re-development, it is necessary to specify its critical weaknesses. Just list them and explain why they are intractable in the evolutionary development of "A".
On the other hand, no one forbids it. If you like writing code, write it. Rewrite "A" but in your own way, but it will be new
Max, hi!
Well I have already repeatedly described the "flaws" that from my point of view I see in the standard library and in Anatoly's library.
Both libraries have, in my opinion, one significant drawback: the interface is built on discrete chart objects, i.e. the more controls in the interface, the more detached objects in the chart itself. On the one hand this doesn't seem to be a problem, but on the other hand it is a problem with drag and drop dialogs, as not a single "form with elements" object is dragged and dropped, but many different elements. And this consumes additional resources.
Anatoly's library is very chic, but it is complicated in its composition and difficult to integrate into the main program. And the standard library is limited in the controls themselves, although the original architecture is very good in my opinion.
Actually, the best solution would be what Petr Konov tries to do: GUI GUI builder with GUI code generation, but with extended event model, so when integrating with main program, you would not need to get into huge GUI code (something like MVVM analogue), and of course with objects that users could expand on their own.
Max, hi!
Well, I have already described many times the "shortcomings" that, from my point of view, I see in the standard library and in Anatoly's library.
Both libraries have, in my opinion, one significant drawback: the interface is built on discrete chart objects, i.e. the more controls in the interface, the more isolated objects in the chart itself. On the one hand this doesn't seem to be a problem, but on the other hand it is a problem with drag and drop dialogs, as not a single "form with elements" object is dragged and dropped, but many different elements. And this consumes additional resources.
Anatoly's library is very chic, but it is complex in its composition and difficult to integrate into the main program. And the standard library is limited in the controls themselves, although the original architecture is very good in my opinion.
In fact, the best solution would be what Petr Konov is trying to do: a GUI GUI builder with GUI code generation, but with an extended event model, so that when integrating with the main program you don't have to go into huge GUI code, and of course with objects that users could extend on their own.
the quote should be read from bottom to top. The bottom (what is underlined) is more important. It's the defining one.
With all the modern development of all the Human Interfaces, it's rather surprising to see coordinate views and form elements in the foreground.
At the same time everyone uses browsers with Rest/Ajax, knows what MVC is, but doesn't think about the interface between the Expert Advisor and its GUI.
If the model is described and there is a protocol for working with it, the GUI can be anything and does not depend on the Expert Advisor. This is some kind of evil when you put windows into the Expert Advisor. The main purpose of Expert Advisors is to trade, everything else should be taken out of the main code and be optional.
the quote should be read correctly from bottom to top. The bottom (what is underlined) is more important. It is the defining one.
With all the modern development of the Human Interface, it is quite surprising to see coordinate representations and form elements in the foreground.
At the same time everyone uses browsers with Rest/Ajax, knows what MVC is, but doesn't think about the interface between the Expert Advisor and its GUI.
If the model is described and there is a protocol for working with it, the GUI can be anything and does not depend on the Expert Advisor. This is some kind of evil when you put a box in the Expert Advisor. The main purpose of Expert Advisors is to trade, everything else should be taken out of the main code and be optional.
I think we should assume that from the beginning the developers didn't think about the fact that interfaces functionality might be needed. If you remember, in the early days there wasn't even any OOP in mql, its main purpose was only to write indicators and everything was designed for it.
And now we see that mql has already worked with sockets and databases, even at the core level... But the mechanisms of interaction between the user and the program are left aside.
The developers themselves have declared almost ten years ago that the development of interfaces is a very important mechanism of interaction between the user and the application and have developed a standard library for this case, but only its applicability to the tasks have not shown and in fact even today many programmers are not aware of its existence.
We will try to eliminate the gaps. Even if other participants will not need it, a certain experience will be gained anyway.
I started with your library, thank you for that, then I tweaked it a bit, then some more, then some more)))) changed everything including rewritten line functions, also wide line function from Kanvas source, removed fake functions, put stub on event. not yet completely gone from W structure although there is not much left too. I've added calculation of bar on the left and right by binary search among other elements and also added binary search itself with ability to choose greater or lesser value. Also added ability to build from arrays of any kind (timeseries/common ) And came to conclusion that I should change construct))))))
Cool.
Yes, the libraries should be either universal for novice programmers, or narrowly focused for more advanced.
I myself have several versions of my own iCanvas for different purposes.
This is why I started to formulate a list of intentions and goals or at least indicate the direction. And put this list in the first post while it is available for editing.
Anyway, either I'm doing something wrong or the class declaration (empty) templates don't want to work. Which makes the code not particularly handy.
I'm thinking of changing
Guys, since you taught me, let me teach you.
Wait to judge - it's not even more than the basics. And the fact that I will finish the GUI is unlikely - that's what I said back in the beginning. As for large projects - I say so in your code lines are not enough to compete with large projects.....
now the question is why the trick doesn't work
...
now the question is why this trick doesn't work