Creating a GUI for MQLs in graphical mode. - page 10
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
One-way polling from μl, pips, files or web-requests.
I'm sure that would be just fine! We're not talking about sending anything to MT. The transfer itself can be done in any other way. The important thing is to notify MT that some action needs to be performed. It's exactly the same as in the GUI library that you've developed: all the colbecs are done through events.
By the way, about this library: do you plan to expand it and translate it completely to canvas? That is, the final "product" is not a set of chart objects, but one whole picture.
And in the context of dll review, of course I would like to be able to include dll as a resource in MT, so I don't have to "drag" them along with Expert Advisor or indicator.
Why stop at dotnet for gui?
The question is not so much about GUI. The interfaces can be easily created using MT tools. Of course, it's a bit complicated and requires creation of own processing classes, but everything can be solved. I started working with net because of impossibility to implement some algorithms of working with Internet. It's rather complicated and unstable in C++, even in native language, not to mention MT. Once I've mastered net, I can start using GUI as well, because everything is ready for it, unlike in MT. Among open questions of applications development in any language, namely in any, as these questions are not connected with the net: 1. Feedback, 2. Linking GUI to chart (https://www.mql5.com/ru/forum/103764)-one of the topics.
One-way polling from µl, pips, files or web queries.
it is your choice ;-)
from the applications point of view - there should be a standard way after calling DLL to say back to MT "this is what you want, this is what you get".
Typical scenario for long calculations, network IO - MT calls DLL, DLL creates a thread and something gets done in it. There needs to be a way to say "that's it, it's been calculated". Without it, we're constantly polling the EAs for something.
it's your choice ;-)
From an applications point of view - there should be a standard way to tell MT "this is what you want, this is what you get".
Typical scenario for long calculations, network IO - MT calls DLL, DLL spawns a thread and something gets done in it. There needs to be a way to say "that's it, it's been calculated". Without it, we are constantly polling the EA for something.
Seconded by me!
Well
We can all argue to the end about the merits of one development environment or another. But what for? We all know that no development system is self-sufficient, because it solves specific problems. Any other plug-in component developed in any other language or environment can be used to extend its capabilities. We just need to make it easy to communicate. Let's not go far: the same Windows libraries that we use through importing... ...we use them to implement the functionality we're missing. And you can't say that it's implemented purely by means of mql. ))) So what difference does it make which external application we use to expand the capabilities and achieve the desired objectives? How is a self-written dll worse than a Windows one?
Here is an article for example: https://www.mql5.com/ru/articles/364
But it's not about getting rid of dll completely, it simply will never happen, because MT has strictly its own tasks. The system libraries are present in this article, no matter how you look at it. Yes, unlike homemade libraries these libraries don't need to be carried around with Expert Advisor or indicator...
Well, what prevents you from adding the possibility to compile dlls into the tool's resources?
Yes, you can not put it on the market, because the market does not allow to use dll, but it would be much more convenient for your own development.
We can all argue to the end about the merits of one development environment or another. But what for? We all know that no development system is self-sufficient, because it solves specific problems. Any other plug-in component developed in any other language or environment can be used to extend its capabilities. We just need to make it easy to communicate. Let's not go far: the same Windows libraries that we use through importing... ...we use them to implement the functionality we're missing. And you can't say that it's implemented purely by means of mql. ))) So what difference does it make which external application we use to expand the capabilities and achieve the desired objectives? How is a self-written dll worse than a Windows one?
Here is an article for example: https://www.mql5.com/ru/articles/364
But it's not about getting rid of dll completely, it simply will never happen, because MT has strictly its own tasks. In this article, system libraries are present no matter how you look at it. Yes, unlike homemade libraries these libraries don't need to be carried around with Expert Advisor or indicator...
Well, what prevents you from adding the possibility to compile dlls into the tool's resources?
Yes, you can't put it on the market, because the market doesn't allow using dll, but for your own development it would be much more convenient.
These thoughts and posts are 10 years old.
If we are talking about the ecosystem, then we should simply shut down the use of any imports in MT. But they don't do that. After all, they didn't just decide to use library imports for a reason. For a while MT couldn't work with web requests, there were limitations when working with files... all this was EXPANDED by importing libraries. It's all obvious and all systems work that way. Even now MQL can work with files only from a sandbox. It's not like anyone is challenging this approach, it's the developer's policy and everyone understands and supports it. If you need to get out of a sandbox or use registry to store data, or a database or mapping ... then please use libraries for this purpose. Right? It all makes perfect sense. The tool doesn't need databases or anything else... it's all just for developers, which is why the MQL language is available, so you can implement tools of any functionality. And since there's a development environment, MT is no longer a thing in itself. )) You just need to ... ))))
These kinds of thoughts and posts are 10 years old, but we're still here...
How is that still the case?
All the possibilities for interoperability have been around for a long time. DLL support was even introduced in 2004.
Our languages are constantly evolving and becoming more powerful and functional. And the ecosystem is more powerful than anyone else's.