Getting data from the Journal, Experts, Alerts tabs of the Toolbox -- indicator to replace Toolbox window

New comment
 

Due to the horrendous state of the MT5 Toolbox I'm looking to make an indicator that can act as an alternative. The Trade, History, and Calendar tabs should be easy enough. That data can all be accessed readily as far as I can tell. The problem lies with a couple of the other tabs I'm interested in...

Is there any way to access the data in the Journal, Experts and Alerts tabs from within MT5 with MQL5?

There is, of course, one final alternative in the event that MT5 has no internal MQL5 programming mechanisms to access that data, that is, aside from me learning to program outside of MQL5 to intervene from the outside... having all print/alert events from my programs routed to something, such as a file, or terminal global variables, and then pulling off that from an indicator. It's a great way to make custom monitoring windows for the EA's/indicators, but, it's still no replacement for the Journal tab.

 
Max0r847:

Due to the horrendous state of the MT5 Toolbox I'm looking to make an indicator that can act as an alternative. The Trade, History, and Calendar tabs should be easy enough. That data can all be accessed readily as far as I can tell. The problem lies with a couple of the other tabs I'm interested in...

Is there any way to access the data in the Journal, Experts and Alerts tabs from within MT5 with MQL5?

There is, of course, one final alternative in the event that MT5 has no internal MQL5 programming mechanisms to access that data, that is, aside from me learning to program outside of MQL5 to intervene from the outside... having all print/alert events from my programs routed to something, such as a file, or terminal global variables, and then pulling off that from an indicator. It's a great way to make custom monitoring windows for the EA's/indicators, but, it's still no replacement for the Journal tab.

No, you cannot with MQL functions.

I would suggest to go forward as about following, just to exclude some other issues, you will come across with your current, lean approach.

Build a Service. One to gather all data for you, use DLLs and what not is required. Collect all data and write it to a database.

Build another service. Make it inject a button on every open chart to "open the panel/toolbox"

Use a stub indicator. Load it from the service onto the chart, giving you a sub window. Use the indicator as EventProxy towards your service.

Make the service read the database and draw into the window of the stub indicator.

This will avoid a lot of issues, and leave the chart indicator thread without the burden of handling the toolbox.

You can consolidate all resources inside the service. You can make it adapt to the available data in the database. In case the data collector service is run without DLLs, you provide less data in the database, you can adjust to that.

You can also add additional tabs, like calendars and what else you like to gather. Multi terminal support, or different accounts...

It's following MCV construction this way.

EDIT:

One crucial drawback to only use an indicator is it's asynchronously. Each chart will have a different state of the toolbox.

Another is the amount of resources you will need to use.

And you cannot sync them either, or it will be very difficult.
 

Wow, that escalated quickly in terms of how advanced it could get compared to where I'm at. That being said, there is still some commentary/thoughts I have from my level of knowledge. I've only been doing this, as my first serious attempt at programming, for a few months, and learning very slow.

One thing to keep in mind is that this is not an end-user product but just a personal product, which I would be willing to share, including the source, but not develop to suit the requirements of other people. This allows me the luxury of simplifying everything to be very limited in scope of purpose/configuration.

I did consider the idea of potentially making a service as a place to perform intermediary operations on the back end, from which indicators can pull from as needed. I literally know nothing about using DLLs or any outside programming implementation. It may not be something I'm ready for. I'm still new to MQL5 itself as well. From what I understand, outside of reading memory itself directly, the only way to access the Journal will be through the log file, which is only updated perhaps once per minute or so. This, of course, would probably require outside programming because I believe file operations with MQL5 don't allow access to the log file. So I may just end up using the inbuilt toolbox as the journal tab and having a dedicated part in the screen for it, or just disappear it until I need it. Of course, the alternative would be simply to have a text editor showing it, preferably with some kind of color coding config like they do with programming languages, on a dedicated portion of the screen. It would have to be refreshed from time to time but only when I need to.

For everything else, however, I figure a service could be used to manage an SQLite database, something I will need to learn to do.

Aside from that, I plan to make dedicated detached chart windows that are purely used to display these readouts in dedicated places on my multi-monitor layout. So there will be one panel on a monitor that only shows active positions, one that only shows the history, one that only shows Expert log, one that only shows calendar stuff, etc. These dedicated indicator windows can be set to symbols I don't monitor/trade, or just no symbol at all, in order to occupy dedicated threads. Of course, the other option is to make them EA's instead of indicators. I'm used to thinking in terms of "indicators for displaying stuff, EA's for trading stuff" but really that's just a convention.

Additionally, I can make a separate indicator, or EA, for each specific dedicated toolbox-esque tab. Thus, there's no need to create any type of multi-functionality. At worst (or best, should I say) some of the functions of these indicators will end up being shared, perhaps with input parameters for their different requirements. Ideally each detached chart window used for viewing these toolbox-esque readouts will have nothing but the text label table of what I'm looking at, visually configured to my specifications (with some configurability/flexibility) without any type of buttons or complex interface, aside from indicating where in the log it's showing (current, beginning, where in the middle) and responsiveness to keyboard/mouse inputs for navigating. I've already demonstrated that it's easy to scroll a bunch of text label objects in sync with each other through keyboard/mouse actions in an indicator, and control their positioning. It works marvelously, in fact. I love chart events!

My job will be to make that display read from data, and display the correct data based on positioning of scrolling. I think this shouldn't be too difficult. I haven't decided on whether I want to just use arrays, structures, or arrays of structures, or structures of structures, or structures of arrays :D I'm new to this.

What I can say almost for sure is that it's probably wise to parse this data through an actual database rather than attempting to do it with my own code, except maybe for active positions which is limited in number of items. The arrays/structures would be used for holding the contents/etc. of the label chart objects. Perhaps it would even be useful to have intermediary arrays/structures for caching stuff from the SQLite database and then pull from those to populate the label contents.

 
Max0r847 #:

Wow, that escalated quickly in terms of how advanced it could get compared to where I'm at. That being said, there is still some commentary/thoughts I have from my level of knowledge. I've only been doing this, as my first serious attempt at programming, for a few months, and learning very slow.

One thing to keep in mind is that this is not an end-user product but just a personal product, which I would be willing to share, including the source, but not develop to suit the requirements of other people. This allows me the luxury of simplifying everything to be very limited in scope of purpose/configuration.

I did consider the idea of potentially making a service as a place to perform intermediary operations on the back end, from which indicators can pull from as needed. I literally know nothing about using DLLs or any outside programming implementation. It may not be something I'm ready for. I'm still new to MQL5 itself as well. From what I understand, outside of reading memory itself directly, the only way to access the Journal will be through the log file, which is only updated perhaps once per minute or so. This, of course, would probably require outside programming because I believe file operations with MQL5 don't allow access to the log file. So I may just end up using the inbuilt toolbox as the journal tab and having a dedicated part in the screen for it, or just disappear it until I need it. Of course, the alternative would be simply to have a text editor showing it, preferably with some kind of color coding config like they do with programming languages, on a dedicated portion of the screen. It would have to be refreshed from time to time but only when I need to.

For everything else, however, I figure a service could be used to manage an SQLite database, something I will need to learn to do.

Aside from that, I plan to make dedicated detached chart windows that are purely used to display these readouts in dedicated places on my multi-monitor layout. So there will be one panel on a monitor that only shows active positions, one that only shows the history, one that only shows Expert log, one that only shows calendar stuff, etc. These dedicated indicator windows can be set to symbols I don't monitor/trade, or just no symbol at all, in order to occupy dedicated threads. Of course, the other option is to make them EA's instead of indicators. I'm used to thinking in terms of "indicators for displaying stuff, EA's for trading stuff" but really that's just a convention.

Additionally, I can make a separate indicator, or EA, for each specific dedicated toolbox-esque tab. Thus, there's no need to create any type of multi-functionality. At worst (or best, should I say) some of the functions of these indicators will end up being shared, perhaps with input parameters for their different requirements. Ideally each detached chart window used for viewing these toolbox-esque readouts will have nothing but the text label table of what I'm looking at, visually configured to my specifications (with some configurability/flexibility) without any type of buttons or complex interface, aside from indicating where in the log it's showing (current, beginning, where in the middle) and responsiveness to keyboard/mouse inputs for navigating. I've already demonstrated that it's easy to scroll a bunch of text label objects in sync with each other through keyboard/mouse actions in an indicator, and control their positioning. It works marvelously, in fact. I love chart events!

My job will be to make that display read from data, and display the correct data based on positioning of scrolling. I think this shouldn't be too difficult. I haven't decided on whether I want to just use arrays, structures, or arrays of structures, or structures of structures, or structures of arrays :D I'm new to this.

What I can say almost for sure is that it's probably wise to parse this data through an actual database rather than attempting to do it with my own code, except maybe for active positions which is limited in number of items. The arrays/structures would be used for holding the contents/etc. of the label chart objects. Perhaps it would even be useful to have intermediary arrays/structures for caching stuff from the SQLite database and then pull from those to populate the label contents.

You will find lots of limitations, you need to manage to overcome..

It is no small project, and you should think of a general structure, you can maintain throughout the code.

Especially, you need some basic tools, like inter-process communication to exchange data between your instances. And you should encapsulate your data containers in some unified way.

Detached charts behave a little different than attached charts, log and check the call to OnChartEvent, see for yourself.

Since it seems, you will be doing a lot of stuff in your app, you should consider laying out where you will process the majority of your code.

If you run into the situation that your app is lagging, you might end up rewriting most of your code, especially if you are using a monolithic approach. The more modular you design it, the easier it will be to push code around.

As a start (but not a good example) take a look at how MQL standard library is designed. You can draw some conclusions from that, maybe.

Another project, worth a look, is EasyMQL.


I personally would say, you are aiming high for a beginner project, but that's ok. Learning curve will be steep.(Don't use so many windows, I counted more than 3....)
New comment