My approach. The core is the engine. - page 26
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
GUI constructors are made for a specific graphic library. If there was a GUI builder for MQL, it would be here.
I have seen an article somewhere, somewhere in hubre, it seems, like "create a GUI constructor for Python", so I thought that maybe someone has seen a multiplatform GUI where I could add my own code
But if I want to write a constructor from scratch, I would rather use MQL.
1. I have never developed it in Sharp, I had no interest, but about 5 years ago I used Delphi to connect .dll with buttons and forms and it worked without problems, even the entire Delphi project was ready during one day, I even spent half a day trying to find the reason why standard forms didn't work, and when I connected it through calling system windows everything was working properly, but MT4 was very slow then, it lags now it flies
i have no problems to connect .dll, synchronize with standard mutexes - start a thread to connect to the terminal and that's all, then everything goes by itself - separately a form in .dll, separately MT no one is waiting for anyone
SZS: please note, that Delphi is rather impractical to create a .dll, but what was at hand (what I was sitting on at that time) I used))
2. But as for the point, I don't understand why they can't use standard classes from MT toolkit, it would be cool to unify the process of graphics creation, maybe it would be a universal include where you could comment unnecessary buttons/dialogs, etc.
1. this is a very, very amateurish way of looking at the problem (no offense). A project that is done in a day is not a Project. It is a small task.
Imagine that you create an application consisting of 10 windows, among which there are big data tables, settings windows and dialog boxes. You draw them in Delphi. Then you create a DLL. Then you connect it to your MT project.
Your MT application needs to connect to the Delphi GUI via shared memory. Connect functions to controls, and data to table cells. You need to organize the complex interaction of the two parts of the application and think it through properly.
You need the synchronous operation and exchange of parameter values between the two parts - GUI and MT Application.
Once again: if your application is big and serious (tables, settings windows, dialog boxes, ancient lists, etc...) creating a single, coherent and efficient work of two parts via DLL is a VERY serious task. I've done it and I know what I'm talking about.
And you are talking about some small task that can be done in a day. It's not serious.
You can use the standard library a long time ago. But the question is about the effort required and the result you will get. What are they? I know that Anatoly used the standard library as a springboard for creating his own library. But why did he do it, if the standard library works too? The answer is simple - he implemented everything of higher quality and went beyond the Standard Library. But, mass distribution can only be achieved by reducing the difficulty of use. The easier to use, - the more users will be (with an increase in quality of course).
1. this is a very, very amateurish way of looking at the problem (no offence). A project that is done in a day is not a Project. It is a small task.
Imagine that you create an application consisting of 10 windows, among which there are big data tables, settings windows and dialog boxes. You draw them in Delphi. Then you create a DLL. Then you connect it to your MT project.
Your MT application needs to be connected to the Delphi GUI via shared memory. Connect functions to controls, and data to table cells. You need to organize the complex interaction of the two parts of the application and think it through properly.
You need the synchronous operation and exchange of parameter values between the two parts - GUI and MT Application.
Once again: if your application is big and serious (tables, settings windows, dialog boxes, ancient lists, etc...) creating a single, coherent and efficient work of two parts via DLL is a VERY serious task. I've done it and I know what I'm talking about.
And you are talking about some small task that can be done in a day. This is not serious.
What are your grievances? You just don't understand that data exchange between MT and .dll is as old as the world
I was making a .dll because previously there were no decent graphics in MT, I wanted buttons and a panel
tables? - well draw tables, controls? - draw.... You just can't separate the task, in the same Delphi there are many ready-made components, both for creating d atabases of databases and for working with them
I.e. from MT you need only the data itself, and the rest will do a third-party program, you can take your word for it, but in the same Delphi to write work with the database, with the output in tables, charts, etc. work for a day ;)
What is data in MT? = it's just a tick and bar, and there's no point in "racing" through a .dll - just dump everything into a file once and work with the file in a third-party program
SZS: someone wrote recently on the forum that modern IT companies value employees who do not thoroughly understand the code in which they work, but those who as soon as possible can perform a large volume of tasks, ie, need to be able to integrate other people's work into their task, and not build every time all from scratch! I do not know your main occupation, I have never worked as a programmer, but I am constantly working in related fields, for a long time engaged in maintenance of industrial controllers, ACS and ACS, and had to do add program solutions and interact with the developers, so I had to get into all ready-made software solutions - here you can not write everything from scratch )))), and the manufacturers of industrial "iron" use specialized programming systems, where C, where SCADA, and assembler, and every once must be able to read someone else's code ;))
You propose to create, based on your "engine", conditionally workable design, which can not be further modified by programmers?
What are the hard feelings? You just don't understand that data exchange between MT and .dll is as old as the world
I did the .dll because previously there were no decent graphics in MT, I wanted buttons and panel
tables? - well draw tables, controls? - draw.... You just can't separate the task, in the same Delphi there are many ready-made components, both for creating databases of databases and for working with them
I.e. from MT you need only the data, and the rest will do a third-party program, you can take your word for it, but in the same Delphi to write work with the database, with the output in tables, charts, etc. work for a day ;)
ZS: what is data in MT? = it's just a tick and bar, and there's no point in "racing" the history through a .dll - just dump everything into a file once and work with the file in a third-party program
If you take only the data coming into it from MT, and pass it through a DLL to an application written in Delphi or C++ or C#, then it is definitely possible. Then the trading application will be completely written in a different programming language.
That is, timeseries, tester, optimization, synthetics and many other things must be created in another language.
Why do you need MQL at all? It is enough to supply the data directly to a third-party application, and use the platform as a sender of events and orders. And that's all. But the advantages of MQL as a trading system language will be lost.
Why do you need MQL?
Because MQL is an application language developed for writing trading applications. This is its main advantage. It's light and simple. It has a lot of ready-made solutions for programmers. They take them and use.
Programmers have a choice:
Obviously, the most preferable option is to use MQL and MT, because they give advantages - Testing, Optimization, Research (synthetics), Indicators, handy functions, timeseries... + Technical language support on the forum.
But this ideal has one serious flaw: Limited ability to create complex applications, because of the difficulty of creating a quality GUI.
This last problem I mostly solved.
Therefore when it comes to practice and you start writing a serious application, you will surely choose MT. So will many, many others.
...
Are you suggesting to create, on the basis of your "engine", a conditionally workable design, which cannot be further modified by programmers?
The engine is the "carrier" of that GUI which is created in my constructor. It doesn't need to be modified. Only connect it to the application and the GUI created will work.
Once again: if the application is large and serious (tables, settings windows, dialogs, ancient lists, etc...) creating a single, coherent and efficient operation of the two parts via the DLL is a VERY serious task. I've done it, and I know what I'm talking about.
Whoever can create a large and complex application will definitely use the gui library. What should the developer do, if he develops his application and decides to add animation, for example? Should he seek you out and ask, or should he break everything and build from scratch?
Where did you get the idea that there is a problem with GUI creation. Look at the market, there are many applications with GUI.
1. Whoever can create a large and complex application will definitely use the gui library.
2. What should the developer do if, while developing his application, he decides, for example, to add animation? Search for you and ask, or break everything and build from scratch?
3) And where did you get the idea that there is a problem with GUI creation. Look at the marketplace, there are plenty of apps with GUIs.
1. The GUI library is a library designed for serious programmers. It cannot be mass produced due to difficulty of use. What is the point in that? Just some of us will pore over the library and create complex applications while others won't be able to?
2. Let the developer create animation in his application. What does this have to do with me? He can call this animation independently of the GUI and the engine, or link the call of his animation to some button.
3) There are only a few people whose GUI is worthy of attention. You, Anatoly and maybe someone else... The rest don't reach the slightest serious level.
3. there are only a few people whose GUI is noteworthy.
I wouldn't be so categorical. And I wasn't talking about gui library development, I was talking about gui applications. There are a lot of them in the market, some using their own developments, some using the standard one and some using the library from Anatoly.
1. That's the point. The GUI library is designed for serious programmers. It cannot be massively spread because of the difficulty of use. What is the point in that? Some of those who will pore over the library and create complex applications and some won't be able to?
2. Let the developer create animation in his application. What does this have to do with me? He can call this animation independently of the GUI and the Engine, or link the call of his animation to some button.
3) There are only a few people whose GUI is worthy of attention. You, Anatoly and maybe someone else... The rest of them don't reach even the slightest serious level.
Peter, I think the main problem you have is in the positioning of the project.
It may only be of interest to those participants who have a rather good experience in programming, but at the same time - prefer to trade hands.
Do you think there are many of them?
Look - all of the critics of your design are people who do not engage in "manual" trading on a regular basis. At most - from time to time. And, since they do not look at your project as "manual" traders - they look at it as programmers. And, understandably, they find a lot of very dubious solutions.
In my opinion, your question now should be about finding this niche (in my opinion, a very narrow one): programmers who prefer to trade hands.
I think I saw an article somewhere, like on hubra, called "create a GUI builder for Python", so I thought maybe someone has seen a multiplatform GUI where I can add my own code
If I want to write a constructor from scratch, I would rather use MQL.
Modern GUI constructors (the ones that "spread buttons onto forms") are quite a technological thing and attaching MQL elements to them doesn't look fantastic.
In the intermediate form ( project file, etc) almost all of them have XML describing the layout and relations between the elements.
Target platform code generation is in fact XSLT transformation, which can be done by anyone who thinks they are web-developers :-)
Take for example EasyAndFast (https://www.mql5.com/ru/code/19703) because it is object-based and has all necessary components. (and open and documented by the way, unlike in this thread),
and simply write a translator.
There are no gui-mql builders, not because it is mega-complex, but simply because it is not in demand.