My approach. The core is the engine. - page 25

 
Yuriy Asaulenko:

You don't have a callback in MT either. Everything is done by predefined events in MT, which once and for all.

You will still send terminal events to the DLL, and it doesn't matter where you process them, in MT or in the DLL.

Here's an example of my connection interface:

This is where everything is already thought out.

Files:
 
Реter Konow:

Even if one imagines that constant checking of messages from Sharp on the part of the ICL application is not a nuisance, developing an interaction format is a very voluminous task.

This task includes the following:

1. Coming up with a shared memory organisation.

2. Implementing the interaction of the three parties.

3. Synchronous testing of the three sides (Sharp, DLL, MT application).

Very time consuming.


In my case, the user gets the file and fills it out. And the connection works.

Don't make this up. I've been doing this for 8 years with different terminals and languages, from VBA Excel to C++, and know nothing about these problems).

I've already written that your system is probably applicable by Market vendors or people other than MT-MQL who know nothing about the existence of other languages and programming environments.

 
Yuriy Asaulenko:

Don't make this up. I've been doing this for 8 years with different terminals and languages, from VBA Excel to C++, and I don't know anything about these problems).

Have a look at my connection file.

The user simply connects this file via an inline to his EA. And fills it in. And everything works...
 
Yuriy Asaulenko:

...

I already wrote that your system is probably applicable by Market vendors or people other than MT-MQL who know nothing about the existence of other programming languages and environments.

By the way, I'm currently developing GUI connections with an EA in a tester. The GUI will be on one chart and the EA will be running in the tester. And they will communicate with each other. The Expert Advisor in the Strategy Tester will be responding to the user's actions on a different chart that will interact with the GUI.

I have worked out how to implement this.

But to set communication between the Expert Advisor in the Strategy Tester and the Sharp through the DLL... It doesn't seem to be possible.

 
Реter Konow:

And to set up a link between the EA in the tester and Sharpe via the DLL... I don't think you can.

It seems to be possible. The tester, as far as I know, does not impose any restrictions on communication with DLL. However, I haven't tried it myself.

 
Yuriy Asaulenko:

It seems to be possible. The tester, as far as I know, does not impose any restrictions on communication with the DLL. However, I haven't tried it myself.

Yes it is possible of course. Just make sure the DLLs are allowed and that's it.
 
Well, maybe you can... However, the "masochistic" choice towards Sharp is very obvious.) There are so many nuances... But when you don't have a choice, of course.
 
Реter Konow:
Well, maybe you can... However, the "masochistic" choice towards Sharp is too obvious))) There are so many nuances there... But when there's no choice, of course.

I have never written in Sharpe, I had no interest, but about 5 years ago I used Delphi to connect .dll with buttons and forms, everything worked without problems, and I even wrote the whole project in Delphi during one day, moreover I 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 problem 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: note, that Delphi is not practical enough to create .dll, but what was at hand (what I was sitting on then) I used )))


But as for the gist, I don't understand why they can't use standard classes from MT toolkit. At the most it would be interesting to unify the process of graphics creation, maybe it would be a universal include where you could comment out buttons/dialogs, etc.

 
Peter, Don't think that your approach is something new.
What tricks programmers went to when there was no OOP.
You can see it yourself, in C programs with open source.
All your claims that OOP can and cannot have nothing to do with reality.
You're not talking about OOP, you're talking about your ideas about OOP. It's surprising that you talk about it so much,
but you haven't bothered to find out what it is.

For some reason you neglect other people's experience, and it exists.
It's stupid to study for four months what you can find on google and still learn so much more.
When inventing your own markup language, for some reason you didn't want to study other people's experience as well.
For example, there is a free QT Designer. It uses a markup language based on XML.
Delphi, C++ Builder also use XML nowadays.
There is also the resource editor in MS Visusl Studio. It allows you to edit dialog boxes and put them into resources.
It also has its own markup language.

From my experience with GUI:
A good GUI library makes working with the GUI much easier.
A visual editor adds very little convenience. In fact, it's just a lure for newcomers.
Markup languages are usually used to store forms in the visual editor. Without it, a markup language is unnecessary.
With a library, it's easier for a programmer to create a graphical interface in code rather than using a markup language.
I think you are imposing your markup language because you want to hide code.

 
Igor Makanu:

Can you suggest a free GUI builder that would allow to write the MQL code for graphics?

I want to make something similar to Delphi Drag-and-Drop, but I haven't found a free GUI constructor, that would allow to enter the MQL code.

GUI constructors are made for a specific graphic library. If there was a GUI builder for MQL, it would be here.