My approach. The core is the engine. - page 24
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
Right.
The engine carrying the application GUI simply performs the mechanics of the controls (buttons, input fields, etc...).
Button presses, checkboxes, text input and other user actions, direct from are passed to the developer's application.
The application can transfer its data to fields and tables.
Everything is done through a simple connection file.
Oh well, that's another matter then.
NET-dlls are now coming to MT. It is no longer difficult to make a GUI in C-sharp for MT, and with more functionality. And since in any case all events are on MT-ticks, then the buttons, too. Well, analysis screw, imho, easier to DLL than to Peter.
In general, the engine Peter, if anyone useful, it is only Market Sellers, where DLL nizizzi.
First of all, you're lying when you say "no difficulty at all". You can easily create a GUI in C#, but to connect it to an MQL-application?
Show me an example of such a connection. This is at least a creepy crutch. You have to do everything through a DLL. Send events, receive events...
How much effort and time will it take to develop a SharpGUI connection with an MT application via DLL?
Who will do it, in the face of the simplicity of my solution? I already have a connectivity interface. The connection issue is half an hour (if several windows). Everything is very simple. No DLL.
So this, is a "dying" idea.
First of all, you're lying when you say that "it's no big deal". To make a GUI in C# is easy, but to connect it to MQL-application?
Show me an example of such a connection. This is at least a creepy crutch. You have to do everything through a DLL. Send events, receive events...
How much effort and time would it take to develop a Sharp GUIinterface with an MT application WITHOUT the DLL?
Who will do it, in the face of the simplicity of my solution? I already have a connection interface. The connection issue is half an hour (if multiple windows). Everything is very simple. No DLL.
So this, is a "dying" idea.
Everything is the same. No complications at all. There is no difference what function you call, application or DLL. Do you see complexity in calling functions?
Everything is the same. There is no complication. It doesn't make any difference which function you call - the application or the DLL. Do you see difficulty in calling functions?
No. It's about the memory where the parameter values have to be synchronized. The memory has to be either in a file or in a shared application memory in the DLL (or somewhere else).
But this is not the main point.
THE GENERAL:
Every developer will have to come up with his own interface for connection to GUI on Sharp.
And why would that be necessary when I already have everything working?
No. It's about the memory where the parameter values should be synchronised. The memory must be either in a file or in the shared application memory in the DLL (or somewhere else).
But this is not the main point.
THE GENERAL:
Every developer will have to design his own interface for connection to GUI on Sharp.
And why would that be necessary if I already have everything working?
You're being dramatic).
You're being dramatic).
Not a bit. I know the situation. I've done interfacing between an MT application and a Sharpe application, via a DLL written in C++. Terrible pain in the ass. You have to work with visual studio and MT at the same time. Then to run applications in parallel.
But the main thing is that nobody developed a format of interaction of application parts. Hence, everybody will be agonizing on his/her own.
Not a drop. I know the situation. I've done interfacing between an MT application and a Sharpe application, via a DLL written in C++. It's an awful pain in the ass. You have to work with visual studio and MT at the same time. Then to run applications in parallel.
But the main thing is that nobody developed a format of interaction of application parts. Hence, everyone will be struggling on his own.
The DLL is a standard Windows tool. The interoperability of the DLLs has been developed and used since DOS times. There is no problem there at all.
The DLL is a standard Windows tool. Interoperability with the DLL has been developed and widely used for a long time, since the DOS days. There is no problem there at all.
Sharp's interaction with the DLL has been developed. And the interaction of an ICL application with Sharp via DLL is a personal hassle for the programmer.
He needs to organize the shared memory and make his function calls based on reading flags.
Consequently, he needs to endlessly access the shared memory which is in the DLL or in the file.After all, there is no callback from Sharp via DLL to MT.
The interaction with the DLL on the Sharp side is worked out. And the interaction of MKL application with Sharpe via DLL, is a personal hassle for the programmer.
He needs to organize the shared memory and make his function calls based on reading flags.
Consequently, he needs to endlessly access the shared memory which is in the DLL or in the file.After all, there is no callback from Sharp via DLL to MT.
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 DLL.
Even if one imagines that constant verification of messages from Sharp by 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.