Creating a GUI for MQLs in graphical mode. - page 12

[Alexey Volchanskiy]

Yuriy Asaulenko:
Actually, I don't. There is no difference between an external program and a program in MT. The capabilities are the same, the interaction is the same.

Of course there are not enough colbucks, but neither are there any in the MT.

But in general it is possible. Second EA and mutexes or short timer. This works, but there is no need.

You haven't explained anything at all. How do you get data from MT* in sharpe panel?

I've been doing feedback via Memory Mapping with timed polling. The panel only sent me different settings and slow calculation results.

[Alexey Volchanskiy]

Renat Fatkhullin:
Ignorance gives confidence. But knowledge multiplies sorrows.

Would you mind when:

- an alien and huge virtual machine gets into your process

- hijacks your excerpts and thinks it's the master

- eats up a lot of memory and thinks it's the master

- run a bunch of threads that have a life of their own.

- rubbish collector grows to the max and limits your process.

- all calls through the wrapper.

For gui's sake, it's definitely overkill.

Ok, then I'll make the panel separate, communication via Memory Mapping. I used to do it via pipes in late 2000s, but didn't like it.

Connected directly though, didn't notice any horrors.

[Koldun Zloy]

Maxim Kuznetsov:

The terminal's COM interface would be cool, though rapidly becoming obsolete.

It just doesn't seem to fit in with the real time :-(.

COM interface will probably not be available.

But may I ask why it is obsolete?

It is also fast becoming obsolete.

[Alexey Volchanskiy]

Koldun Zloy:

COM interface will probably not be available.

But may I ask why it is obsolete?

It is also rapidly becoming obsolete.

it has been replaced by .net with its communication interfaces

[Alexey Volchanskiy]

Alexey Volchanskiy:

it has been replaced by .net with its communication interfaces

and in COM GUIDs alone are worth a lot

MS still buys back unused GUIDs for a dollar a 10. If you have some left over from the old days, you can make a nice profit!

[Maxim Kuznetsov]

Alexey Volchanskiy:

And in COM GUIDs alone are worth a lot

MS still buys back unused GUIDs for a dollar a tenner. If you have some left over from the old days, you can make a nice profit!

I've got some lying around :-) I'll let you send them to MS

066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb

if there's anything else, I might be able to find it.

[Алексей Барбашин]

Colleagues. I think that the argument about which development environment is better and which code is faster has no sense whatsoever. It is all a matter of taste and depends on the tasks to be solved. Regardless of the development environment, we still have problems of interaction between an external application and a MetaTrader tool. Let's consider a simple example. You have implemented in a native dll an algorithm of complex mathematical calculations. You passed the required parameters from the MT tool to this library and started the calculation, the tool continued its work until the calculation was completed. And again this issue is independent of the development environment!

I see several options:

1. The possibility of calling from the outside of the program method OnChartEvent, using for example the PostMessage

2. Adding to МТ tools new method, as Renat offered: OnExternal, specifying the event type or generally transferred data, i.e. in this method you can return the data

3. Implementation in MT tools of winsocket. This is similar to the second point, but allows the MT tool to connect to a specific port to listen for data.

If the first and second items will allow interaction on a single machine level, the third item will provide MT tools networking.

Here is an example:https://www.mql5.com/ru/articles/2599

But here again you have the problem of having to check if the data on the socket is available all the time.

So the callback problem remains in all cases and it is not solved.

Timer monitoring is not a solution but a crutch. Yes, in the absence of other options this is how we're solving it now.

If the developers would implement a solution for these issues on the platform level, then there wouldn't be any need to access the API terminal. After all, it's not asked for because of the good life, but because there is no full-fledged interaction between MT and the applications being created. And I repeat: this problem exists regardless of the chosen external application development environment.

[Алексей Барбашин]

Information on the possibility of using net libraries )))https://www.mql5.com/ru/forum/13388

The topic is very old in principle. The developers themselves once announced the possibility to work with net libraries without any difficulties... Since then a lot of water has flowed, but the question remains unresolved...

Or here, a message from Renat himself:https://www.mql5.com/ru/forum/3153/page2#comment_298866

https://www.mql5.com/ru/forum/3153/page2#comment_298892

[Maxim Kuznetsov]

Алексей Барбашин:

Colleagues. I think that the argument about which development environment is better and which code is faster has no sense whatsoever. It is all a matter of taste and depends on tasks to be solved. Regardless of the development environment, we still have problems of interaction between an external application and a MetaTrader tool. Let's consider a simple example. You have implemented in a native dll an algorithm of complex mathematical calculations. You passed the required parameters from the MT tool to this library and started the calculation, the tool continued its work until the calculation was completed. And again, this issue does not depend on the development environment!

I see several options:

1. The possibility of calling from the outside of the program method OnChartEvent, using for example the PostMessage

2. Adding to МТ tools new method, as Renat offered: OnExternal, specifying the event type or generally transferred data, i.e. in this method you can return the data

3. Implementation in MT tools of winsocket. This is similar to the second point, but allows the MT tool to connect to a specific port to listen for data.

If the first and second items will allow interaction on a single machine level, the third item will provide MT tools with network communication.

Here is an example:https://www.mql5.com/ru/articles/2599

But here again you have the problem of having to check if the data on the socket is available all the time.

So the callback problem remains in all cases and it is not solved.

Timer monitoring is not a solution but a crutch. Yes, in the absence of other options this is how we're solving it now.

If the developers would implement a solution for these issues on the platform level, then there wouldn't be any need to access the API of the terminal. After all, it's not asked for because of the good life, but because there is no full-fledged interaction between MT and the applications being created. And I repeat: this problem exists regardless of the chosen external application development environment.

I'll add about monitoring and polling, just not everyone knows it - to avoid jerking DLL at every poll, you can have int[] for "sharing" flags. Inside DLL all access to them as __atomic__ .
In principle this works and is quite economical on resources, but you have to rely on the fact that on MQL side increment/decrement are also atomic and optimizer doesn't make assumptions about values.

int flags[1]={0};     // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] )   // проверить один int это очень быстро
{
   flags[0]--;
   ReadDataFromDLL(handle);
}

To make things really good, atomic (volatile?) attribute and a set of appropriate primitives would be enough. In my opinion, it is easier than to build a new mechanism into the system and does not change existing DLL protocol

[Алексей Барбашин]

Maxim Kuznetsov:

I'll add about monitoring and polling, not everyone knows about it - not to bother DLL with every poll, you can create int[] for "sharing" flags. Inside DLL all access to them as __atomic__ .
In principle this works and is quite economical on resources, but you have to rely on the fact that on MQL side increment/decrement are also atomic and optimizer doesn't make assumptions about values.

int flags[1]={0};     // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] )   // проверить один int это очень быстро
{
   flags[0]--;
   ReadDataFromDLL(handle);
}

To make things really good, atomic (volatile?) attribute and a set of appropriate primitives would be enough. In my opinion, it is easier than to build a new mechanism into the system and does not change existing DLL protocol

Maxim, how is this solution better? After all, in order to check the status of a flag, it also needs to be periodically checked in MQL. So, it turns out that everywhere you look, you need to constantly monitor changes of the state of something to understand that it's time to pick up the data. And this fragment may be stored in dll itself and checked there - that's what I do. In your example we have an implicit call to the dll to return the state of the flag.