My approach. The core is the engine. - page 170
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
Hilarious :)))
Well done, you******* take a pie off the shelf.
OK, I'll try to justify it:
If you go by your solution, the user will still have to copy the source code of the static class into the project, which will translate events, run the form in a separate thread well, etc. In addition, you must statically link the form to this class, i.e. explicitly enter the name of the form class and its components. I.e. explicitly modify your layer code when a form is changed or some element is added. In other words, a simple and straightforward solution, would work well for demonstrating interaction with a specific form, which is what you've shown. In a generalized case, it's better to separate the control logic from the display logic, which is what I've done. Also, this separation allows you to secure the controller from unqualified modification.
Here's a comment that answers exactly the question of why it was done this way and not the other way around:
you are probably right, it is easier for a user to sketch graphic elements in a form in VS2017, then check by running his creation in VS, having made sure that "everything is spinning", he can move on to creating a program interaction in .Net and MT5
...
Your way is probably more practical.
Exactly. There will be a huge database of Cyb-codes with pictures. Go in, select, get the code, insert into the constructor, get the core with connection files. And the connection is already thought out and much easier.
So, each form is in a separate file. Even if it were simpler, the possibilities are limited.
So there too, each form is in a separate file. Even if it were simpler, the possibilities are limited.
To be honest, I haven't fully grasped the technology yet, so I can't say anything about the limitations of Vasiliy's solution yet.
Basil, no offence, but a panel like this:
I have about this kind of code:
This code can simply be passed to each other, or put in a common base and there is no need to draw a form to each one specially.
I pasted it into the constructor and got another window with all the item parameters and connections.
Peter, to draw the same panel you have, I need to learn your markup language. The user doesn't need anything but a mouse and basic skills to draw this panel in Visual Studio. Do you feel the difference?
To be honest, I haven't fully grasped the technology yet, so I can't say anything about the limitations of Vasiliy's solution yet.
And I didn't write about the limitations of Vasiliy's solution.
Peter, to draw the same panel as yours, I need to learn your markup language. The user does not need anything to draw this panel in Visual Studio, just a mouse and basic skills. Can you feel the difference?
Vasily, one person studies my markup language and writes the panel. A thousand others see the picture of the panel and take the ready-made cyber-code. They paste it into my constructor and get that panel in their program.
Pre-read, but will keep rereading to get into the details.
1. Why does the article say 5 requests per second? I have a frequency of 30ms.
2. Can you show me what a connection to a table of a thousand cells looks like?
3 As far as I understand it, calling the elements in the form by their names sent to theGuiController::SendEvent function? Do you have to specify all the parameters? Name, event, value? Some more zeros... And in the timer to do a loop on events?
In other words, user creates the event queue himself and then passes it to the Controller in the timer?
I have to thank you, for the great promotion of my topic.
1) It makes no difference. You can set it to any frequency you want.
2) Tables are not supported now (great reason for your cheering by the way:)
3) Yes, addressing by name, you have to specify all parameters. But, and this is the most important thing, there is no single monolithic event model. You want your own model, you're welcome. It is elementary to make it. But you can't do without timer.
The event queue is a generalized algorithm for reliable handling of events. The user doesn't compose anything; events generated by him get to the queue by themselves. The queue itself consists of only one event 99.9% of the time.
OK, I'll try to justify it:
If we go by your solution, the user will still have to copy the source code of the static class into the project, which will translate events, run the form in a separate thread, etc. In addition, you must statically link the form to this class, i.e. explicitly enter the name of the form class and its components. I.e. explicitly modify your layer code when a form is changed or some element is added. In other words, a simple and straightforward solution, would work well for demonstrating interaction with a specific form, which is what you've shown. In a generalized case, it's better to separate the control logic from the display logic, which is what I've done. Also, this separation allows you to secure the controller from unqualified modification.
Here's a comment that answers exactly the question of why it was done this way and not the other way around:
The biggest issue is launching the form in a separate thread, but it is solved by two lines of code, so in the end it is not a problem. In addition, in my example I intentionally made the opening of the second form, to show how easy and simple it is to do, and how you can open any number of forms in separate threads.
And that highlighted in the quote - is hay and straw the same thing? Yes! To eat a banana, you have to peel the peel.
To be honest, I haven't fully understood the technology yet, so I can't say anything about the limitations of Vasiliy's solution yet.
There is no capacity limit there, everything is limited neither more nor less than the functionality of Windows graphical elements, read the article "Under the bonnet of GuiController", add the necessary controls in the form designer and add to MT5 in <element - list of event handlers> what events you think you need to receive
2) Tables are not supported now (great reason for your rejoicing by the way:)
I'll also congratulate Peter, I made a table work in a separate form in .dll on .Net, right-click events, sorting, and other charms dataGridView all work, did in part experiments table as the terminal, but rather capricious and slow dataGridView , I tried many things with it ( and filled a clone datatable and then copied to the datatable which is linked to a dataGridView and . and googling for a week and experimenting, while with dataGridView a complete fiasco - you can't write to it more than 3-5 seconds) the 10x11 table is already critical, although the form with the table and runs in a separate thread
SZY: I attached a StringGrid to MT4 5 years ago in Delphi, I was not worried at all about how it worked, but everything was flying, however with the Microsoft dataGridView is a problem, today I will try to experiment with SourceGrid, according to feedbacks it is faster than dataGridView