CHART_FIRST_VISIBLE_BAR seems to give inconsistent result after rescaling the chart

Martin Bittencourt 2026.02.26 20:12

Hi!

While trying to code something with chart scaling and navigation, I came across the following result:

The results above where produced by this code:

            Print("DEBUG: Reset: First bar before scaling: ",ChartGetInteger(glChartID,CHART_FIRST_VISIBLE_BAR));
            
            if (!ChartSetInteger(glChartID,CHART_SCALE,glFocus.prevChartState.scale))
            {
               
//... inform error 
               
               return;
            }
            
            Print("DEBUG: Reset: First bar after scaling: ",ChartGetInteger(glChartID,CHART_FIRST_VISIBLE_BAR));
            
            Print("DEBUG: Reset: First bar after scaling: ",ChartGetInteger(glChartID,CHART_FIRST_VISIBLE_BAR));
            
            Print("DEBUG: Reset: First bar after scaling: ",ChartGetInteger(glChartID,CHART_FIRST_VISIBLE_BAR));

As you can see, it seems that right after rescalling a chart by code, the CHART_FIRST_VISIBLE_BAR becomes temporarily inconsistent in providing the correct first visible bar's ID: the expected results is that calling CHART_FIRST_VISIBLE_BAR would produce the exact same results before and after rescalling, but it's temporarily giving a wrong result until its soon corrected (Note: considering the scaling behaviour just talked about in this thread, what I'm presenting here happens with the chart moved to the left size, away from the last produced bar).

Here goes the print of another occasion a little to the left of the case above with the same "temporarily wrong result" appearing:

And here is a complementary funny thing: the actions I performed in this last case were basically identical to another (I missed the points by one bar), and yet they produced a very different result:

In this instance, scaling didn't produce a temporary wrong return by CHART_FIRST_VISIBLE_BAR, but a definitive one. If it was always like the first 2 prints, I could probably just add a tiny Sleep() call right after any scalling operation and the problem would be mitigated, but it seems the situation is a bit worse (though adding Sleep(1000) did minimize the occurances of the first mentioned problem).

I attached an EA with a simple code which may be used to reproduce the problem and I added a "bonus bug" into it: ChartNavigate also seems untrustworthy since it fails from time to time.

Reference for scaling the chart: intentional or bug?

2026.02.26
www.mql5.com

General: Reference for scaling the chart: intentional or bug?

Files:

ChartProblems.mq5 5 kb

Alain Verleyen 2026.02.26 22:13 #1

Martin Bittencourt:

Hi!

While trying to code something with chart scaling and navigation, I came across the following result:

The results above where produced by this code:

Here goes the print of another occasion a little to the left of the case above with the same "temporarily wrong result" appearing:

I don't know why the value is changing, that doesn't matter it's internal business, though :

- ChartSetInteger is asynchronous. ChartGetInteger is synchronuous.

- Set after you set CHART_SCALE, it is NOT executed immediately.

- Most of the time only the 2nd or 3rd get CHART_FIRST_VISIBLE_BAR gives the correct value. It could be the first or none, or all wrong.

To get updated value, you should work with events (better than sleep).

      case CHARTEVENT_CHART_CHANGE:
         res=ChartGetInteger(ChartID(),CHART_FIRST_VISIBLE_BAR,0,v);
         printf("CHARTEVENT_CHART_CHANGE: Reset: First bar after scaling: %i - %lli - #%i",res,v,_LastError);

It will always give you the correct value.

CHART_BRING_TO_TOP property is not Indicator Question Machine learning in trading:

Alain Verleyen 2026.02.26 22:22 #2

Martin Bittencourt:
... I added a "bonus bug" into it: ChartNavigate also seems untrustworthy since it fails from time to time.

Why could not it fails ? If ChartNavigate returns a bool, it's because it can fail.

I can't reproduce it though, you should print the _LastError, so maybe it would be possible to understand why it fails.

 Print("Error advancing 50 bars ",_LastError);

Martin Bittencourt 2026.02.28 17:26 #3

Alain Verleyen #:
- ChartSetInteger is asynchronous. ChartGetInteger is synchronuous.

Well that does make sense. Gosh that didn't even come to my mind!

Alain Verleyen #:
To get updated value, you should work with events (better than sleep).

Indeed. I guess I'll implement a State Machine, since its many calls to ChartSetInteger.

Alain Verleyen #:
Why could not it fails ? If ChartNavigate returns a bool, it's because it can fail.

I'm sorry, but in my rush to finish the post and go to the gymn, I wasn't precise in my explanation: by "it fails" I mean the navigation/chart movement doens't happen even if the function returns true. Funny thing: I tried to reproduce this buggy behaviour now to show the evidence and, after many attempts, I failed to reproduce it. Maybe it only happens with the market open as it was yesterday. So, next week, I try again and record a video to show.

For the time being, thanks!

Terminal failing to completely Gold Fx Sniper's by one-click trading not working

Martin Bittencourt 2026.03.02 19:46 #4

Martin Bittencourt #:
Maybe it only happens with the market open as it was yesterday. So, next week, I try again and record a video to show.

Hi!

I recorded a video showing ChartNavigate not working despite returning true (using the EA I loaded in a previous post in this thread):

Alain Verleyen 2026.03.02 20:20 #5

Martin Bittencourt #:

Hi!

I recorded a video showing ChartNavigate not working despite returning true (using the EA I loaded in a previous post in this thread):

I tried hard to reproduce that and I could not.

Please show your config details (from Journal log).

Martin Bittencourt 2026.03.03 01:55 #6

Alain Verleyen #:
Please show your config details (from Journal log).

You mean this info:

MO      0       15:47:03.600    Terminal        MetaTrader 5 x64 build 5660 started for MetaQuotes Ltd.
PJ      0       15:47:03.600    Terminal        Windows 10 build 19045, 16 x AMD Ryzen 7 1800X Eight-Core, AVX2, 8 / 15 Gb memory, 119 / 237 Gb disk, UAC, GMT-3

? In this case, here is the bonus info:

KP      0       15:47:05.826    Network '60598024': authorized on XPMT5-DEMO through MT5 DEMO Access Server SP2 03 (ping: 31.03 ms, build 5430)
CQ      0       15:47:05.826    Network '60598024': previous successful authorization performed from 189.6.233.107 on 2026.03.02 11:09:15
DO      0       15:47:06.546    Network '60598024': terminal synchronized with XP Investimentos CCTVM S/A: 0 positions, 0 orders, 48657 symbols, 0 spreads
HG      0       15:47:06.546    Network '60598024': trading has been enabled - hedging mode

And extra bonus: attached file with the log visible in the video.

Files:

MT5_For_Forum.txt 9 kb

Martin Bittencourt 2026.03.03 01:56 #7

Alain Verleyen #:
I tried hard to reproduce that and I could not.

P.S.: remember to do it with live market, so chart updating with sufficiently liquid asset. When I tried to reproduce the problem with market closed, nothing happened to me as well.

Alain Verleyen 2026.03.03 13:42 #8

Martin Bittencourt #:

You mean this info:

? In this case, here is the bonus info:

And extra bonus: attached file with the log visible in the video.

Thanks.

I finally got the issue after a lot of attempts. Though I am not sure what the problem is, from your log :

LK 0 16:23:55.661 ChartProblems (WIN$N,M2) DEBUG: Clicked 1 CG 0 16:23:55.661 ChartProblems (WIN$N,M2) DEBUG: CHART_FIRST_VISIBLE_BAR 1: 473 GD 0 16:23:55.661 ChartProblems (WIN$N,M2) ChartNavigate returned true ER 0 16:23:55.661 ChartProblems (WIN$N,M2) DEBUG: CHART_FIRST_VISIBLE_BAR 2: 423 OF 0 16:23:56.107 ChartProblems (WIN$N,M2) DEBUG: Clicked 2 JL 0 16:23:56.107 ChartProblems (WIN$N,M2) DEBUG: CHART_FIRST_VISIBLE_BAR 1: 423 LJ 0 16:23:56.111 ChartProblems (WIN$N,M2) ChartNavigate returned true MH 0 16:23:56.111 ChartProblems (WIN$N,M2) DEBUG: CHART_FIRST_VISIBLE_BAR 2: 473 HQ 0 16:23:58.073 ChartProblems (WIN$N,M2) DEBUG: Clicked 1 LI 0 16:23:58.073 ChartProblems (WIN$N,M2) DEBUG: CHART_FIRST_VISIBLE_BAR 1: 423 CQ 0 16:23:58.073 ChartProblems (WIN$N,M2) ChartNavigate returned true GE 0 16:23:58.073 ChartProblems (WIN$N,M2) DEBUG: CHART_FIRST_VISIBLE_BAR 2: 373

First visible bar '473' seems to be wrong as after the click it's then reported as '423'. If ChartNavigate failed, then why is First visible bar changed ?! Strange.

Anyway, I will report it and we will see.

Reference for scaling the ChartNavigate problem in EA Scrolling charts along the

Martin Bittencourt 2026.03.03 14:43 #9

Alain Verleyen #:
Anyway, I will report it and we will see.

OK. Thanks!

Alain Verleyen 2026.03.10 13:59 #10

So here are some clarifications about your code and it's execution.

            Print("DEBUG: CHART_FIRST_VISIBLE_BAR 1: ",ChartGetInteger(ChartID(),CHART_FIRST_VISIBLE_BAR));
            
            if (!ChartNavigate(ChartID(),CHART_CURRENT_POS,50))
            {
               Print("Error advancing 50 bars");
         
               return;
            }
            
            ChartRedraw();
            
            Print("DEBUG: CHART_FIRST_VISIBLE_BAR 2: ",ChartGetInteger(ChartID(),CHART_FIRST_VISIBLE_BAR));

As I already explained ChartGetInteger() is synchronous, while ChartNavigate() AND ChartRedraw() are synchronous (I was not sure about that, thanks to MetaQuotes developers for their help).

So when ChartNavigate() returns true it only means the statement was queued, not that it was executed (or failed). That means use "Get" function AFTER an asynchronous function call is NOT guaranteed to give correct values.

Please note that the current behaviour is by design and will not be changed.

CHARTEVENT_CHART_CHANGE - Missing events ChartNavigate during initialisation Errors, bugs, questions

1 2

New comment