Making a crowdsourced project on Canvas - page 35
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
By the way, since people are dealing with a previously long-overdue:
this is a random screenshot taken from yandex, the GUI client-server interface, and over the network. No need to reinvent the wheel...
(a second of advertising) Pi is really cool. Honest tungsten lives there :-)
Yes, that's the main problem! The same market prohibits the use of dlls, so we have to reinvent the wheel. Ok, if someone thinks that GUI is not needed, but any complex long calculations in any case in one thread will not work, everything will hang! So it has to be done in a dll... which is forbidden in the marketplace...
And so on. For this reason I have to draw and solve everything with mql methods.
In fact, the separation of GUI and logic into threads is, of course, already possible. Here guys have already discussed the parallelism issue https://www.mql5.com/ru/forum/288985/page5#comment_14722396.
As the result, the form itself could be left in the main thread, as it is done in winnda, while any additional computations could be moved to "background" execution. This is the way it works for Windows, Linux and Android.
Yeah, I've seen that article, which is kind of another crutch with a bunch of code that I don't even want to look into.
When everything is much faster and easier to do in dll.
By the way and mql Socket andWebRequest I gave up, because when mql server is not available, due to break of connection,
The socket or webrequest functions are blocked, so keep it in mind, if you decide to build applications on mql sockets and webrequests.
By the way, as long as people are doing things that have been done before:
This is a random screenshot taken from yandex, GUI client-server interface, and over the network. No need to reinvent the wheel...
(a second of advertising) Pi is really cool. Honest tungsten lives there :-)
by the way and Scratch in the screenshot is roughly what Konov wants to do, put together an algorithm out of dice.
it's because microsoft is in charge :-)
Why do you think people lose their login details when they upgrade and activate products on pirate platforms?
What hasMicrosoft got to do with dll signing keys? That only identifies the developer.
Keys to sign the dll, can be issued by MQ, to those who have been fully identified in the marketplace.
With this key the developer signs his dll to identify who wrote the dll.
The dll signature key does not affect product activation.
///
Can you understand that there is no proper GUI on the MKL? The one you have is from '95. Shame on you... And you with the calls for a third party GUI, have you thought about how to use it in MT? How to connect it? Or don't give a honey, let me tell you a platitude?))
Can you understand that there is no proper GUI on the MKL? The one you have is from '95. Shame on you... And you with the calls for a third party GUI, have you thought about how to use it in MT? How to connect it? Or don't give you a honey, let me tell you a platitude?))
Peter, I'll probably open your eyes and speak for Maxim: Maxim knows the subject better than anyone else and about a year and a half ago he posted his version of GUI, sort of forming it on the markup basis. Moreover, the GUI was built in an external environment, but it had a full interaction with the programme (indicator, Expert Advisor).
Maxim, sorry for answering your question.
However, I would like to get back to the subject. I pulled a picture from an article on the operation of the standard library:
This screenshot shows the composition of the dialog in a simplified form.
In this version, the Border is the main element which creates the canvas object on the chart and all slave objects are drawn on it. Or rather, it is drawn depending on the slave object.
The Close button is drawn on the Caption and the Caption is drawn on the Border, which is then drawn on the canvas with all drawn elements.
Peter, I'll probably open your eyes and tell you for Maxim: Maxim is more familiar with this topic than anyone else and about a year and a half ago he posted his version of GUI, which was formed on the basis of markup. Moreover, the GUI was built in an external environment, but it had a full interaction with the programme (indicator, Expert Advisor).
Maxim, sorry for answering your question.
However, I would like to get back to the subject. I pulled a picture from an article on the operation of the standard library:
This screenshot shows the composition of the dialog in a simplified form.
In this version, the Border is the main element which creates the canvas object on the chart and all slave objects are drawn on it. Or rather, it is drawn depending on the slave object.
Close button is drawn on Caption and Caption is drawn on Border and this button with all drawn elements is drawn on canvas.
I don't know what he posted and what he did in the GUI matters, but in my threads he didn't make a single technical suggestion, solution or discussion on the subject. Only empty trolling, pointing out third party solutions and urging not to reinvent the wheel.
Back to the topic at hand.
As far as I'm familiar with the standard library (very little actually), there elements and windows are composed of MT objects. That is, in our context - they are not drawn on the canvas. Of course they are drawn, but not on our canvas, which prevents us from controlling pixel colours, creating surface gradients and more.
In theory, we could take the library structure, copy and make an analog on the kanvas. In theory...
The problem is that CCanvas itself is not suitable for making a GUI on it. Why? Because the kanvas system is used mainly for graphic primitives. So, in essence, this class does not provide anything but primitives. The GUI archetype has to be built by yourself. And in this case, the class isn't necessary. It's more convenient to make do with your own solutions. After all, you can draw a rectangular marker without the class. Just like you can create or load a canvas. It is very simple. Therefore, I preferred my own solution.
But someone cannot do without CCanvas. That's why I don't insist on it.
I don't know what he has posted and what he has done in GUI matters, but in my threads he has made no technical suggestions, no solutions and no discussions on the subject. Only empty trolling, pointing out third party solutions and urging not to reinvent the wheel.
Back to the topic at hand.
As far as I'm familiar with the standard library (very little actually), there elements and windows are composed of MT objects. That is, in our context - they are not drawn on the canvas. Of course they are drawn, but not on our canvas, which prevents us from controlling pixel colours, creating surface gradients and more.
In theory, we could take the library structure, copy and make an analog on the kanvas. In theory...
The problem is that CCanvas itself is not suitable for making a GUI on it. Why? Because the kanvas system is used mainly for graphic primitives. So, in essence, this class does not provide anything but primitives. The GUI archetype has to be built by yourself. And in this case, the class isn't necessary. It's more convenient to make do with your own solutions. After all, you can draw a rectangular marker without the class. Just like you can create or load a canvas. It is very simple. Therefore, I preferred my own solution.
But someone cannot do without CCanvas. So I do not insist on it.
Stop! Peter (right?), let's make some conventions to understand each other. Condition 1: We will not call a canvas a CCanvas class but just a canvas to draw a part of the screen or one resource specifically. The CCanvas class has nothing to do with any of this and we will not dwell on it at all. It simply provides functions to draw on that canvas and that's it! In fact, we can draw using a lot of different methods.
By "draw" we will understand the formation of an array of pixels, based on which a resource is created, which is then placed on the chart.
Stop! Peter (right?), let's accept some conventions for each other's understanding. Condition 1: We won't call CCanvas a class, but just a canvas to draw part of the screen, or specifically one resource. The CCanvas class has nothing to do with any of this and we will not dwell on it at all. It simply provides functions to draw on that canvas and that's it! In fact, we can draw using a lot of different methods.
By "draw" we will understand the formation of an array of pixels on the basis of which a resource is created and then placed on the chart.
That's right.
Peter, I'll probably open your eyes and tell you for Maxim: Maxim is more familiar with this topic than anyone else and about a year and a half ago he posted his version of GUI, which was formed on the basis of markup. Moreover, the GUI was built in an external environment, but it had a full interaction with the programme (indicator, Expert Advisor).
Maxim, sorry for answering your question.
However, I would like to get back to the subject. I pulled a picture from an article on the operation of the standard library:
This screenshot shows the composition of the dialog in a simplified form.
In this version, the Border is the main element which creates the canvas object on the chart and all slave objects are drawn on it. Or rather, it is drawn depending on the slave object.
The Close button is drawn on Caption and Caption is drawn on Border and all elements are drawn on the canvas.
Of course, this is not quite right :-)
I posted an interface to the Tcl DLL (which is Tool Common Language), which has a Tk graphics that are shared as a GUI in Python/Ruby/etc
the goal was not to get a GUI, but a nice byproduct :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
in my opinion, convenient, and most importantly short :-)
I am not agitating anyone - I know tcl/tk, I use it, I share my experiences (see sourceforge atcl).