Errors, bugs, questions - page 679

[Renat Fatkhullin]

No one is ignoring it, make allowance for Friday's build release download and the weekend. We'll be sure to check it out.

[x572intraday]

Twenty-five again.

I've found a lot of questions and answers about error 4802 in different branches of forum. I have checked everything in my code (paths on the disk and in my iCustom), compiled the custom indicator, compiled the main one too - the terminal shows error:"2012.03.24 16:44:31 11 (NZDUSD,H4) cannot load custom indicator 'C:\Program Files\MetaTrader 5\MQL5\Indicators\Examples\iCFractals.mq5' [4802]".

   handle=iCustom(_Symbol,PERIOD_CURRENT,
//                  TerminalInfoString(TERMINAL_DATA_PATH)+"\\MQL5\\Indicators\\Examples"+"\\iCFractals.mq5"
                  "C:\\Program Files\\MetaTrader 5\\MQL5\\Indicators\\Examples\\iCFractals.mq5"
                 );

iCFractals.mq5 is a copy of the standard Fractals.mq5, the main indicator is a copy of iFractals from the Help file with substitution:

handle=iFractals(_Symbol,PERIOD_CURRENT);

to the above code.

Build 619 x32.

[Rashid Umarov]

Are you sure you've done everything as described in the help? https://www.mql5.com/ru/docs/indicators/icustom There's also an example below.

[x572intraday]

Rosh:

Are you sure you did everything as described in the help? https://www.mql5.com/ru/docs/indicators/icustom There is also an example below.

Did the whole thing. Even pinched myself just in case. No luck.

Then I did it again, which was hopeless, because it didn't work last time: I removed the extension from the indicator name. Now it worked.

Thank you!

[x572intraday]

What disasters will happen to the terminal if we introduce for every bar (except for M1 timeframe) such an additional parameter such as accurate(M1) time of high- & low-extremes? For now, all accurate time values of bars of higher timeframes must be resource-intensively calculated by means of MQL. Personally I miss the access to the exact values ready-made. If history is calculated in minutes and other timeframes are generated locally from M1, the terminal can simply calculate accurate values at the same time and add them to the database that will grow a bit. In general, not being ready with exact times for bars involves a whole bunch of problems, such as the necessity to bother with them myself and impossibility in principle to limit the number of bars in the terminal window, because refining calculations go deep into the history which cannot be limited and as a consequence they cause memory overflow, not to mention the duration of calculations... This is not a secondary problem.

[Mykola Demko]

x100intraday:
What disasters will result from introduction of such an additional parameter as accurate(M1) times of high- & low-extremes for each bar (except for M1 timeframe) for the terminal? For now, all accurate time values of bars of higher timeframes must be resource-intensive calculated by means of MQL. Personally I miss the access to the exact values ready-made. If history is calculated in minutes and other timeframes are generated locally from M1, the terminal can simply calculate accurate values at the same time and add them to the database that will grow a bit. In general, not being ready with exact times for bars involves a whole bunch of problems, such as the necessity to bother with it and impossibility in principle to limit the number of bars in the terminal window, because refining calculations go deep into the history which cannot be limited and as a consequence they cause memory overflow, not to mention the duration of calculations... It's not a secondary problem in any way.

In principle, memory costs will not increase much, because we do not need to store datetime high & low, but only the difference with bar opening.

But I think it's not the exact time of high & low that's more important for many of those who are interested, but which one came first. It's not always a bull's candle goes low first, sometimes it is vice versa, but it's rare. But as long as the modeling is correct, I think it won't do any harm to code the earliest.

And it is a minimum memory consumption (1 additional bit).

[Renat Fatkhullin]

Urain:

But since it is stated that the modelling is accurate, I don't think it would do any harm to code who has gone before.

The modelling is accurate and is based on information from the minutes.

But if someone on the Daily wants to know some sketchy data from the previous story, it is necessary to take that story (minute-by-minute) and analyse it. There is no need to come up with variants of "extremum high-low, etc." - these are just special cases.

[x572intraday]

Renat:

The modelling is accurate and is based on information from the minutes.

But if someone on the Daily wants to know some sketchy data from a previous story, then you have to take that story (minute-by-minute) and analyse it. There is no need to come up with variants of "extremum high-low, etc." - these are just special cases.

If the problem is not solved at the terminal level, the case will remain private, extremely slow and unclaimed. I would like to write not only for myself and those who have computer cabinets nearby, but for any potential users. After all, you're not shifting the generation of non-M1 timeframes bars to MQL programmers, and hence the access to the exact values of bar times may well be facilitated. The MQL programmer must not know such a routine, he/she must think about trading strategies and algorithms, not about this fuss.

[Vladimir Gomonov]

Renat:

The modelling is accurate and based on information from the minutes.

If someone on the Daily wants to know some snippet of data from a previous story, then you need to take that (minute) story exactly and analyse it. There is no need to make up variants of "extreme high-low, etc." - these are just special cases.

Renat, your minute history is unusually labor-intensive to analyze. Such an analysis is fraught with a lot of "nice glitches" [(c) MetaQuotes Software Corp.] And you know why - because of missed bars.

--

If you want to make an advanced terminal, you have to systematically introduce advanced features in the terminal. Do things that none of the competitors have. That is, move away from tradition in favour of more informativeness, speed, consistency (interconnectivity), cost-effectiveness and other usability. You regularly make the same strategic mistake - focus your decision-making on the statistical size of consumer groups of a particular service.

To make a product convenient (= somehow attractive?) for a statistical majority of users and assume that this majority will automatically begin to consume the product en masse is a utopian policy. The herd has a hierarchical structure and always follows the leaders of subgroups. Until this becomes an axiom of your usability strategy, you will continue to make gross miscalculations in assessing the potential appeal of your services.

In the context of the above, there are tremendous resources for increasing the attractiveness of the terminal for the masses - for example, to finally implement a "hole-free" minute history, the possibility to test it on third-party quotes, CCA orders, and many other "statistically unclaimed" services that are of real (not just written out of thin air) interest to intellectual leaders in your own forums.

[Renat Fatkhullin]

MetaDriver:

Renat, your minute history is unusually time consuming to analyze. Such analysis is fraught with a lot of "nice glitches" [(c) MetaQuotes Software Corp.] And you know why - because of missed bars.

It is up to the programmer to analyse the data. The above query was purely private and has nothing to do with us or the terminal.

The questions about missed bars are from ignorance of the market situation. Look at stock or futures charts to broaden your horizons and questions about "there shouldn't be any holes" will instantly disappear.

If you want to make an advanced terminal, you should systematically implement advanced features in the terminal. Do something that none of your competitors have. I.e. depart from the tradition in favor of more informativeness, speed, consistency (interconnectivity), economy and other usability. You regularly make the same strategic mistake - focus your decision-making on the statistical size of specific service consumer groups.

These are general words. Especially about strategy.