Wishes for MT5 - page 23

[Вадим]

It is not very convenient that the classes cannot be described at the end of the programme, but only at the beginning.

[Вадим]

It would be good to make a slider in the editor that divides the editing window into two independent ones, like in Word. It would be convenient to copy, write and watch two sections of the programme at the same time.

[Yuriy Zaytsev]

MetaDriver:

I wish...

The only exception (and not a necessary one) is weekends. They can also be skipped, but again GUARANTEED to be in sync across different instruments.

Did you know ? that in fact on weekends forex works

it's just that most brokers don't work

---

some even give you quotes on the weekend and let you work on your orders.

which is very convenient.

they can widen the spread on the weekend because there's no liquidity

but there is a way to cover up and change things

[Вадим]

It would be a good idea to add a function to the standard libraries to handle a string of the form: Decompose the string into modules limited by "beginning", "end" and write them to an array of strings. For example: int count=(string, array,"<h1>","</h1>",flag); Where string is the input string, array is the output array of strings, "<h1>" - The beginning of the module in the string, "</h1>" - Module end in string. flag - specifies whether to include or not to include module limiters in the output array strings, count - number of modules found.

In this case, int count=(string, array,"<h1>","</h1>",flag); - will create the array of all headers, which are in string.

[Rashid Umarov]

This can also be done with existing tools, see the article Parsing HTML with MQL4

[Вадим]

Rosh:
This can be done with existing tools, read the article Parse HTML with MQL4 tools

Well, it's clear that you can do it step by step with existing tools. But it's better to have one ready-made function that does everything at once than two pages of code....

[Dmitry Voronkov]

Rinng:
Well, it's understandable that you can do it step by step with the available tools. But better than two pages of code to have one ready-made function that does everything at once....

Add it to a library or mqh file and no problem ;))

[Вадим]

In the editor, it would be useful to hide/open some blocks of program code. For example "functions", "definitions", "classes"..., or you can hide/open sub-codes, e.g. for, if...

[x572intraday]

Rosh писал(а) # :
Read Organisation of data access, it says how to request history correctly.

Report. And partitioned. And the one I've mastered. It's quite possible to figure it out if necessary. I have yet to learn MQL, so almost any question I have about the language risks being silly.

I don't understand another one: "The parameter "Max bars in charts" limits the number of bars available to charts, indicators and mql5-programs in HC format. This limitation applies to all timeframe data and is designed primarily to save resources.

When setting high values of this parameter, we should remember that if there is a deep enough history of price data for low timeframes, the memory consumption for storing timeseries and indicator buffers can reach hundreds of megabytes and reach the memory limit for the client terminal program (2 GB for 32-bit applications of MS Windows).

Perhaps, I haven't really understood what's what in this episode, and at the same time I want to stress once again that I will not ask any questions here and now about MQL programs, but the above motivation to save resources looks strange in relation to automatic history request by the terminal when working directly with a chart manually. Your code is closed, so I cannot judge how it all works. I don't know if each candlestick is a real object with a large bunch of properties and attributes or if it is a simplified graphical drawing/rendering of the structural image of the market. If we omit the topic of downloading the missing history and focus on the one we already have, then we raise a question about the rationality of the drawing approach. Even if we set a certain and large amount of bars in the chart in the settings, even if we compress the chart bars to a needle and use a very high resolution of the monitor, I cannot believe that the whole picture will use the RAM if the bars are correctly loaded from the history DBMS to the screen. Are you using the LIFO principle? The maximum number of bars on the chart can be infinitely large, but what is behind the screen (both left and right) should not be in memory at all, and when scrolling, it should be loaded into the main memory and unloaded instantly, because we are not working with the network, but only with locally available history. What horrible 2Gb limitations could we be talking about?

...I'm probably very much out of the loop, so pardon the redneck in advance.

[Renat Fatkhullin]

Each price bar is described by the MqlRates structure (no other characteristics) with a size of 52 bytes:

struct MqlRates
  {
   datetime time;         // время начала периода
   double   open;         // цена открытия
   double   high;         // наивысшая цена за период
   double   low;          // наименьшая цена за период
   double   close;        // цена закрытия
   long     tick_volume;  // тиковый объем
   int      spread;       // спред
   long     volume;       // объем
  };

To estimate the size of the working databases, you need to look in the directory /bases/server name/symbol/. For example, for EURUSD you can see the following:

In this directory lie the original compressed minute containers as they are given by the trading server. You can see that on average the minute containers take about 15 mb over 1 year. This is a very specific compression format to minimise traffic.

The cache directory contains the work databases which have been compressed as needed:

As you can see, since 1993 minutki (actually, until 1999 daily databases instead of minutki) are about 231 megabytes, compressed and ready to use. The adjacent clocks, however, take up only 4 mb.

If we multiply 52 bytes by 4 400 000 bars, the resulting value is about 230 MB. A simple Moving Average indicator with one working buffer (double) will require 4 400 000 * 8 = 35 megabytes of memory.

When the trader sets "Maximum bars in the window" in the terminal settings, he explicitly specifies "not more than the specified number of bars to be loaded into memory for working". If the entire minute history is loaded (we work on the M1 chart), some heavy multi-buffer indicators are applied and Expert Advisors are used, the memory cost can be significant. And we cannot think "I work with one window and see 500 bars, so I can unload the rest". You cannot unload them - indicators, Expert Advisors, etc. live and work on this data.

We have implemented a very effective caching model, when data and indicators are always stored in a single number. It means that opening 5 windows on EURUSD:M1 does not require creation of 5 data buffers, and several indicators, absolutely equal in parameters, have only one copy. When indicators or charts are not used for a long time, their data is automatically released and pulled back as needed.

In addition, we have a 64 bit version of the client terminal, which can handle a huge amount of history without any limitations. This version will be released as soon as we finish testing MQL5 under 64 bit environment.