Discussion of article "Developing graphical interfaces for Expert Advisors and indicators based on .Net Framework and C#" - page 2
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
Unfortunately, it's all a dark forest for nerds like me. Your article shows a cool application of github. Probably it is only 1% of its capabilities, but it was useful.
I haven't understood how it can help in MQL5 from the given links. Probably, it is a must-have for programmers, but there are those who are far from programming, as I am myself.
If there was an article on this topic for MQL5, it would be useful.
Version control systems (any, not just github) are very non-trivial things. You can't explain what it is and why you need it in five minutes. But the "copy the link and get the latest version of the project" feature is one of the features of such systems, and very cool indeed.
4) You can customise it in different ways. It is made so that you need to specify the name of the form and the assembly in which it is located. I.e. now you can run one, two or five forms. There are no restrictions.
For example, we launch two identical Expert Advisors, but with different forms. Won't they conflict?
If I understand correctly, you suggest that for each Expert Advisor you should write a different GuiMT.exe. Is that right?
good article, but for some reason I don't think it's at a beginner's level.
I don't think I can explain it any easier. Honestly, I tried my best. I even described the studio installation in detail, as requested by the workers.
A novice user needs to do three things:
- Draw the form he needs (exactly draw it in Visual Studio)
- Create an event handling code in his Expert Advisor (it is assumed that the user is familiar with MQL at least on a basic level)/
- Link the form with the Expert Advisor via GuiController (specify the correct paths, specify imports, etc.).
If it is difficult - then you have done everything you can, as they say.For example, let's run two identical EAs but with different forms. Won't they conflict?
If I understand correctly, you suggest that for each EA you should write a different GuiMT.exe. Is that right?
Mm-hmm. I need to think about it....
HI: a form with buttons and without third-party dll ( GuiController.dll ) user can create a form with buttons using VS2017 tools literally in 2 clicks: create project - Net class library and then project - add Windows form
If he is not familiar with C# unfortunately he can't. The code you provided is kind of "simple", just a few lines: create a thread, assign a delegate to it, then run it. And in some other part of the programme you have subscribed to the necessary events.... - Everything is "simple"...
My key idea was that the user could draw a new project without having to add a handler code to it, which would be unavoidable.
For example, let's run two identical EAs but with different forms. Won't they conflict?
If I understand correctly, you suggest that for each EA you should write a different GuiMT.exe. Is that right?
In short, yes, such a configuration will conflict. To avoid this, you can overload the ShowForm method:
The idea is that magic will contain a unique synchronisation number reflecting the <form-expert> type relationship. In short, everything is solvable and extensible.
Unfortunately, if you are not familiar with C#, you will not be able to. The code you cited is "simple", just a few lines: create a thread, assign a delegate to it, then run it. In some other part of the programme, you have subscribed to the necessary events.... - Everything is "simple"...
My key idea was that the user could draw a new project without having to add a handler code to it, which would be unavoidable.
You are probably right, it is easier for the user to sketch graphical elements into a form in VS2017, then check by running in VS his creation, making sure that "everything is spinning", he can move on to creating the interaction of the programme on .Net and MT5.
I had slightly different goals - to run .Net under MT4, but MT4 is hard to achieve correct marshalling at once, so it turned out that I made a .dll first under MT5, and then I integrate it into MT4.
Your way is probably more practical, a little later I will familiarise myself with the project on github, definitely a HUGE THANK YOU !
You are probably right, it is easier for the user to sketch graphical elements into a form in VS2017, then test by running in VS his creation, making sure that "everything is spinning", he can move on to creating interaction of the programme on .Net and MT5.
You got it right! That's why the system is three-component. And the principle of "divide and conquer" in action.
I had slightly different goals - to run .Net under MT4, but it is hard for MT4 to achieve correct marshalling at once, so it turned out that I made .dll first under MT5 and integrated it into MT4.
You still have a professional level. Of course, MT4 is a little different story.
Your way is probably more practical, I will familiarise myself with the project on github later, definitely a HUGE THANK YOU !
Thank you for the feedback:))))
Yeah, it's a good article, but I'm not sure if the editors read it ;-). "Besides" is spelt together, but everywhere else in the text it is separated. It caught my eye because I read it more or less carefully, compared to other articles.
In fact, it seems to be good on the one hand. But on the other hand - it's kind of cumbersome to pull all the Studio-related stuff just for the visual form editor. If Studio is already installed - no problem.
I would do everything in MQL, together with the designer (I have ideas, but I can't get my hands on it). And I think there is an intermediate option - with Studio, but without DLL - design WPF forms, read XAML in MQL.