A visual studio on the MT4 platform. - page 4
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
You can see what the technical information and instructions on creating the GUI for the graphical engine will look like by following this link:
https://www.youtube.com/watch?v=ciVqJwgIIyg&feature=youtu.be#t=66.940294
As far as I know, there is currently no way to transfer an interface created in MS Visual Studio to an MT platform chart.
...
This means that the user will be completely isolated from the code and compiler in all matters relating to the creation of the graphical interface of their program, and will only have to deal with the visual control tools offered by the studio. The interface design will use "drag and drop" technology and the various options windows, through which you can define properties of the ready-made window templates and controls.
...
... This engine will ...to merge with the developer application and carry out all graphical work.
But how would it integrate with the developer's app, if not via code? Suppose a program needs to output a table similar to Market Watch. Then we should send to it the instruction that "EURUSD" should be displayed in the cell "A1", the price "1.238273" should be displayed in A2, etc. However, a set of tools will be different from terminal to terminal and statically the fields and table names simply cannot be filled.
Microsoft Visual Studio is all clear - it's a handy add-on to pureSoftware environment application creation. That is, Visual Studio is not really a visual development environment, and in the case of your program, it is not clear how it will work.
But how will it integrate with the developer's application if not through code? Suppose the program needs to output a table similar to Market Watch. Then it should receive an instruction that "EURUSD" should be placed in the cell "A1", the price "1.238273" in A2, etc. However, a set of tools will be different from terminal to terminal and statically the fields and table names simply cannot be filled.
In Microsoft Visual Studio it's clear - it's a handy add-on to puresoftware environment creating applications. That is, Visual Studio is not really a visual development environment, and in the case of your program, it's not clear how it would work.
At the moment, a solution for combining the graphical engine and the functionality of the user application is in development.
I can only introduce you to the general concept.
When writing his own application, the developer will have to save values of variables returned by his custom functions (for example, value of the current Bid price on "EURUSD") not inside his application but outside.
This means that instead of their own names of variables, they will have to write the index of a shared memory array cell (located outside their program) and store the value returned by the function there.
This global array I call "parameter kernel". Then, the user will assign the address of this cell to the control in the studio. In turn, the graphics engine does a periodic loop through the objects and looks at the addresses of the parameters bound to them in the parameter kernel. If a value at that address has been changed by a user function, the engine will update it in the window. Or vice versa - if the value has been changed by a control, the user function will accept its processing.
In essence, this solution is a symbiosis of two programs communicating over a shared memory, called "parameter kernel". Both programs, the GUI GUI engine and the user program, will be placed on different graphics inside the terminal.
The only problem is the creation of the shared memory. Trying to solve it with MQL, I don't want to resort to a DLL, but if there's no way out, you can create shared memory there. I've already done that.
The only problem is creating the shared memory. Trying to solve it with MQL, I don't want to resort to a DLL, but if there is no way out, you can create shared memory there. I have already done this.
Why do you think so? There is, and even a few. But it is not clear why they, the interfaces, should be transferred to charts - if so, they probably do not exist. But it is quite realistic to overlay them on top of MT.
Once you resort to the DLL, there is nothing left of your concept. Just nothing - Pschich. With a DLL, and indeed even without a DLL, your problem can be solved without developing anything at all.
Be specific please.
What to be specific about? Creating windows in VS on top of MT? This is one birdie - on top of all windows.
Exchanging data with VS? 4 ways at least.
Please explain your opinion.
The only problem is creating the shared memory. Trying to solve it with MQL, I don't want to resort to a DLL, but if there is no way out, you can create shared memory there. I've already done that.
Of course you can organize communication via DLL, but no one will need it, because the Market bans any DLLs. The only way to organize the global exchange of data between the two programs, in terms of standard MQL - is the exchange through global variables. By the way, here is a very cool library for exchanging data via global variables:https://www.mql5.com/ru/code/12786.
In general, it is not very clear who you are creating your studio for. If for developers your solution has no API. No one wants to drag a separate application, with which the program will exchange data, especially for programs placed in the Market.
The solution with user license, too, imho, is a very unfortunate option. Here is a programmer has developed a program based on your studio, paid for the first month of work, and then in the second month, his program will not work, because the graphical core of your studio has required another fee. Bullshit. No developer would base their project on a package that would constantly ask for additional fees. But even if we imagine that the license will be purchased as a lump sum, and the studio itself will be a part of the application, then again it is not clear how it will work in the Market (licensed program with another license inside it).
Still, answer the main question: for which target audience is your project being created? Why would the average user need your studio? Do you want to create Microsoft Word in MetaTrader 5? Of course, it's cool, but WHY? People pay for ready solutions. For programs and algorithms that do a specific job. They do not need to create forms. They need programmes. And the programmers who write these very programs cannot use your studio, because the work is organized in a very strange way.
Understand that right now the emphasis has to be placed on the Market. If you want to create an infrastructure project, you must first of all answer the question: "Why programmers, who are doing business in the Market, or working in Freelance, will start to use my studio. What will it give them?"