Creating a GUI for MQLs in graphical mode. - page 13
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
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 you have an implicit call to the dll to return the state of the flag.
Checking the flag is a very fast operation. I mean the fastest one at all :-)
And there are no implicit calls in this example:
InitDLL received int *flags as input, stored it somewhere in there, spawned a trace that counts something and upon completion does atomic_inc(flags).
The advisor only has to check flags[0].
checking the flag is a very fast operation. That is, it is the fastest at all :-)
And there are no implicit calls in this example:
InitDLL receives int *flags at input, stores it somewhere, spawns a trace that counts something and makes atomic_inc(flags) upon completion.
The advisor has only to check flags[0].
But you can't do nothing with just checking the flag - inter-thread synchronization is required, barriers, atomic or mutex which one to take, of course, for not every CPU.
Exactly to check. That is the key point. And I suggest alerting the tool that the "task" has been completed. That is, you don't have to spend constant resources on checking. The notification came - you got the data.
checking the flag is a very fast operation. That is, it is the fastest at all :-)
And there are no implicit calls in this example:
InitDLL receives int *flags as input, stores it somewhere there, spawns a trace that counts something and upon completion does atomic_inc(flags).
The EA only has to check flags[0].
Max, well, the situation with the callback is clear for now. We'll use what we have and wait for developers to add the callback feature.
I want to get back to the question of GUI. It doesn't matter what it is drawn on. For example I make it in Sharp, you make it in Tcl.
As long as the form exists by itself, it is not a problem at all. But I'd really like forms not to fly by themselves, but to be bound to the appropriate charts.
When you set parent of created form it's placed in required chart. But there is a problem of "merging" the window with the chart and the chart just draws the "glued" form.
I suggest trying to solve this issue for now, as it still lies outside the scope of action of the MT developers.
Have you tried to attach your GUI to the charts?
But you can't do just with flag check, you need inter-thread synchronization, barriers, atomic or mutex, which is not relevant for every CPU, of course.
And how are all sorts of mutexes implemented? All through checking and setting flags, as far as I know. You have to check some flag somewhere in the µl thread anyway.
Quite true. But let it happen at the very low, application level, as, for example, it works with OnChartEvent. I.e., now we explicitly program it (checks), but it all could be transferred to the application level, as Renat said (he suggested some variants).
I'm down :-) donate - can you send it 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.
Thanks, passed, got a quid!
Thanks, passed, got a quid!
so it's more profitable than scalper ! ready to retail them for a cent, you sell them in bulk for 1$/tens. the only limit is the transmission speed :-) some kilobytes of GUIDs per second
Tempting as hell. That's how we'll conquer the used GUID market! And become a monopoly, create an artificial frenzy like with bitcoin and get rich!
Max, well, the situation with callback is clear for now. we'll use what we have and wait for the developers to add callback capability.
I want to get back to the question of GUI. It doesn't matter what it is drawn on. For example I make it in Sharp, you make it in Tcl.
As long as the form exists by itself, it is not a problem at all. ButI'dreally like forms not to fly by themselves, but to be bound to the appropriate charts.
When you set parent of created form it's placed in required chart. But there is a problem of "merging" the window with the chart and the chart just draws the "glued" form.
I suggest trying to solve this issue for now, as it still lies outside the scope of action of the MT developers.
Have you tried to attach your GUI to the charts?
I don't have any need to chain forms to charts.
There are operational graphics that are directly connected to the chart (all kinds of lines, captions, inscriptions, etc.), this is naturally done by MT tools.
But there are management GUIs - settings, reports, statistics. They are quite big and it's a crime against the user :-)
Just place the form on top of the chart. You will need to remove the form from the window manager and track the changes in chart geometry and focus.
The update/ about placing a form - put RectLabel on the chart and in the chart-events to track the change of codinates. When it changes - put its form strictly on top :-) You need a little bit of tambourine when you change tabs, minimize window, to hide your form in timeSuch a "sunset by hand" :-) At least you won't get into the guts of MetaTrader and won't impose new chills and hooks on its windows - i.e. you will behave decently
Any GUI called from DLL has the most unpleasant feature - Expert Advisors/indicators that call it will periodically restart because of the slightest sneezing. Which leads to reopening of forms and waterfalls of foul language...
Perhaps the long-announced "services" (or whatever they will be called) will be devoid of this drawback.
You haven't explained anything at all. How do you get the data from MT* to the sharpe panel?
I've been doing feedback via Memory Mapping with timed polling. The panel only transmitted different settings and slow calculation results