Canvas is cool! - page 55
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
If you remember Borland, the GUI was assembled in a visual editor, the layout of controls was placed in a toolbar, and then you write the handlers.
If ME had such a graphical feature to build layouts in visual mode, it would make building graphical applications much easier.
As the majority of modern programmers, who studied GUI building, got used (so they were taught) to the visual GUI editor,
And to build a layout of a graphical application on pure C-style code is of little interest to them. Since it is already hardcore C-style.
We need a visual editor to build a graphical application, and then people will be eager to learn it, and those who worked in VS or RadStudio, they even quickly master the visual editor.
Here, there was already a prototype of such a visual editor in MQL. However, people were vehemently against it. They said it was not necessary in trading.
In general, they were demoralizing as best they could. Therefore, I don't know what the community really needs.
I fully support the need to have the ability to collect...
But whether it is necessary or not is another question.
I wonder if the developers themselves see the terminal as a trading tool or a programming tool?
I may be wrong at this point, but I always thought that ME was designed to implement exactly the functionality that the user needs for trading. Exactly trading!
But nowadays the depth of programming in ME has gone into areas where you really need to be able to "build" dice and have a very serious understanding of programming....
And what does this lead to in the end? It leads to the fact that advanced trading tools become available only to experienced programmers!
That is, if you're not a programmer, you have nothing to do in trading... But this is absurd.
ME is only an assistant to fill in the missing functionality, which would have been more correctly built into the terminal itself (different wizards).
And in fact ME is now evolving as a new development environment, requiring more and more knowledge from users.
Based on this conclusion, the visualization tools are necessary, but their use should be available to users who do not have deep knowledge in programming.
Only in this case they will be in demand.
This is only my opinion and I am not imposing it on anyone.
If you consider CCanvas class, there are about 20 functions of drawing graphical primitives. Suppose a user knows them all and knows the rules and syntax of OOP. However, it is too little up to the simplest visualization of his data. Not to mention the creation of the simplest control - a button. That is, it is relatively easy to draw primitives on the canvas, but using these primitives in creating visualization or GUI is much more difficult. And you cannot do here without knowledge - you cannot do here without developer's talent. But how many people have it? That's the key problem.
In order to use the potential of the Kanvas class you need to be able to combine graphical primitives into more complex objects (controls), to bind their operation with the event-driven model, to write the relations with functions... Or, convert digital data into different graphical curves... This is a job for talented and very hard working users. In fact, not users, but developers.
Here, there was already a prototype of such a visual editor in MQL. However, people were vehemently against it. They said it was not necessary in trading.
In general, they were demoralizing as best they could. Therefore, I don't know what the community actually needs.
Wow, so there is a prototype.
So maybe the developers should reconsider the community's shallow views? And revive the plan to develop a visual mode.
Kinda weird of course to demoralise an essentially highly sought after feature.
There are very few places now where they teach how to build a graphical interface in C-style, if at all they teach it yet.
Now everyone is taught to work in IDE with visual mode, and since MT5 has long gone beyond only trading platform,
the visual mode of building graphical applications would be in great demand.
Honestly I'm shocked that the developers listened to the short-sighted people who were against it.
If we consider CCanvas class, there are about 20 functions for drawing graphical primitives. Suppose the user knows them all and knows OOP rules and syntax. However, up to the simplest visualization of its data - it is too little. Not to mention the creation of the simplest control - a button. That is, it is relatively easy to draw primitives on the canvas, but using these primitives in creating visualization or GUI is much more difficult. And you cannot do here without knowledge - you cannot do here without developer's talent. But how many people have it? That's the key problem.
In order to use the potential of the Kanvas class you need to be able to combine graphical primitives into more complex objects (controls), to bind their operation with the event-driven model, to write the relations with functions... Or, convert digital data into different graphical curves... This is a job for talented and very hard working users. In fact, not users, but developers.
Peter, you say the right words!
So I advocate creating such libraries that would be intuitively understandable to programmers who are not familiar with OOP as well.
And this applies not only to GUI.
In the standard library and in Anatoly's library it would take a lot of effort to build a simple form! For real! One step to the right or to the left of the examples and that's it, nothing works, you have to understand all the details.
In all languages, of course, the GUI is also built on libraries, but there is one important BUT! There is an initial set of controls, which at the core level of the library are completely "tied" together, all the basic event handlers are "wired", all that remains is to subscribe to them if you want to change the behavior or presentation.
In essence, the architecture of the standard library is very well thought out and could be used as the basis for a more advanced library.
Wah, so there is a prototype available.
So maybe the developers should reconsider the community's shallow views? And revive the plan to develop a visual mode.
It's odd, of course, that they've demoralised an essentially highly sought-after feature.
After all, few places now teach how to build a graphical interface in C-style, if at all it is still taught.
Now they teach to work in IDE with the visual mode, and since MT5 is no longer only a trading platform,
then the visual mode of building graphical applications would be very much in demand.
To be honest I'm shocked that the developers listened to the short-sighted people who were against it.
There are a few other surprising factors: indicators are 100% visual, EAs are 80% visual and scripts are 20% visual. There is visuality in everything and the understanding of this lies on the surface. However, there is a development on integration with other development environments, and what is on the surface....
Apparently every other terminal user is asking for python and sql.
Roman, Peter, Nikolai... the terminal developers have their own vision, they are the authors and owners of the software product. I guess the development of ME functionality and the terminal as a whole is based on market research.
But no one is stopping us from talking :)
There are a few other surprising factors: indicators are 100% visual, EAs are 80% visual and scripts are 20% visual. Whatever you want to call it, everything is visual and the understanding of this lies on the surface. However, there is a development on integration with other development environments, and what is on the surface....
Apparently every other terminal user asks about python and sql.
Roman, Peter, Nikolay... The developers of the terminal have their own vision, they are the authors and owners of the software product. I think that the development of ME functionality and the terminal in general is based on market research.
But no one is stopping us from talking :)
That's right.
My opinion is: visual interface of EAs will allow to accumulate strategies in one application, which will negatively affect market sales. If everyone can easily create Expert Advisors with dynamic set of strategies (GUI allows this), their current rotation in the Market will go down, which will affect the sales. Expert Advisors that integrate and modify strategies internally will come to the forefront and eliminate clones that differ only in settings or a few conditions. Will this be good for Market? I don't know. But the level of Expert Advisors will rise and it will become much more interesting to examine them in the storefront.
Perhaps most users want CCanvas, CGrafic and CCanvas3D to be applications that produce the required visualizations, rather than classes that require knowledge of OOP principles and syntax. And not just to know, but essentially to build their own visualisation system, as Nicholas does.
What is the principle of oop that you need to know? Put a dot and choose a method from the list?
A follow-up question: how many and which of the "most powerful" and "simplest" MQL functions
is enough to write a fully functional and potentially the most profitable Expert Advisor for any
of the world's major currency pairs?
And what R or Python function, which everyone here has lost their heads about, is enough to write...? And look, the stool you're sitting on - is it suitable for that...?
Well, if you remember Borland, the GUI was assembled in a visual editor, you put the control layout on the panel, and then you write the handlers.
If ME had such a graphical ability to build layouts visually, it would greatly simplify the construction of graphical applications.
As the majority of modern programmers, who studied GUI building, got used (so they were taught) to the visual GUI editor,
And to build a layout of a graphical application on pure C-style code is of little interest to them. Since it is already hardcore C-style.
We need a visual editor to build a graphical application, and then people will be eager to learn it, and those who worked in VS or RadStudio, they even quickly master the visual editor.
Why are they needed here?
That's right.
My opinion is: visual interface of EAs will allow to accumulate strategies in one application, which will have a negative impact on Market sales. If everyone can easily create Expert Advisors with dynamic set of strategies (GUI allows this), their current rotation in the Market will go down, which will affect the sales. Expert Advisors that integrate and modify strategies internally will come to the forefront and eliminate clones that differ only in settings or a few conditions. Will this be good for Market? I don't know. But, the level of EAs will grow and it will become much more interesting to look at them on the showcase.
Absolutely a far-fetched problem.
Visual interface for strategy gathering is unnecessary, if you need dice, go to tslab.
And I have seen programs for generating mql code that collect strategies with cubes in visual mode.
We do not need the visual mode for development of trading strategies and indicators, it is really unnecessary.
But for modular graphical applications, visual mode, as you showed in the gif, would be useful.