How to set indicator level color to transparent?

New comment
 

As title, i've already set INDICATOR_LEVELCOLOR =  clrNONE but it still show level color on initialize. 

    for(int i = 0; i < 8; ++i) {
      IndicatorSetDouble(INDICATOR_LEVELVALUE, i, i + 1);
      IndicatorSetInteger(INDICATOR_LEVELCOLOR, i, clrNONE);
      IndicatorSetInteger(INDICATOR_LEVELWIDTH, i, 1);
      IndicatorSetInteger(INDICATOR_LEVELSTYLE, i, STYLE_DOT);
      IndicatorSetString(INDICATOR_LEVELTEXT, i, allLabels[i]);
    }

I have to set color is None manually after load the indicator, it's very irritating


Any solution? Thanks in advance!

 
have you tried maybe setting the visual objects in the indicator to clrNone?
 
Le Minh Duc: As title, i've already set INDICATOR_LEVELCOLOR =  clrNONE but it still show level color on initialize. I have to set color is None manually after load the indicator, it's very irritating
I've never tried setting a level colour to clrNONE, but then consider simply removing the level instead.
 
Fernando Carreiro #:
I've never tried setting a level colour to clrNONE, but then consider simply removing the level instead.

Yes it's a solution but I need to show the label to identify which color belongs to which plot, just in case I have drawn many plots

 
phade #:
have you tried maybe setting the visual objects in the indicator to clrNone?

yes, it's disappeared when I set to "None" in the Level setting, but when i use clrNONE in code it will change automatically to clrWhite after load.

 
Le Minh Duc:

As title, i've already set INDICATOR_LEVELCOLOR =  clrNONE but it still show level color on initialize.

I have to set color is None manually after load the indicator, it's very irritating

Any solution? Thanks in advance!

Can you please supply a fully working example code to reproduce the issue, that we can compile and test on our end as well?
 

I took the time to create my own test example code, and these are my findings:

  • When setting the "Levels" via the terminal's Indicator properties tab, the Colour, Line Style and Line Width are set globally to affect ALL the levels (this differs from the MQL method).
  • When setting the "Levels" programmatically via MQL, each level can have it's own local Colour, Line Style and Line Width (this differs from the properties tab).
  • When programmatically setting the colour to "clrNONE", this always produces "white" and not "None" as what happens when setting from the properties tab.

This confirms, the OP's findings that setting the level colour to "clrNONE" does NOT work as expected.

This could be considered a bug, but I don't know if MetaQuotes is going to do anything about it.


#property indicator_separate_window
#property indicator_maximum 10
#property indicator_minimum -1

input color i_clrLevel = clrNONE;

int OnInit() {
   IndicatorSetInteger( INDICATOR_LEVELS, indicator_maximum );
   for(int i = 0; i < indicator_maximum; i++ ) {
      IndicatorSetDouble(  INDICATOR_LEVELVALUE, i, (double) i            );
      IndicatorSetInteger( INDICATOR_LEVELCOLOR, i, i_clrLevel            );
      IndicatorSetInteger( INDICATOR_LEVELWIDTH, i, 1                     );
      IndicatorSetInteger( INDICATOR_LEVELSTYLE, i, STYLE_DOT             );
      IndicatorSetString(  INDICATOR_LEVELTEXT,  i, "Level " + (string) i );
   };
   
   return INIT_SUCCEEDED;
};

int OnCalculate(const int rates_total,
                const int prev_calculated,
                const int begin,
                const double &price[]) {
   return rates_total;
};
 
Fernando Carreiro #:

I took the time to create my own test example code, and these are my findings:

  • When setting the "Levels" via the terminal's Indicator properties tab, the Colour, Line Style and Line Width are set globally to affect ALL the levels (this differs from the MQL method).
  • When setting the "Levels" programmatically via MQL, each level can have it's own local Colour, Line Style and Line Width (this differs from the properties tab).
  • When programmatically setting the colour to "clrNONE", this always produces "white" and not "None" as what happens when setting from the properties tab.

This confirms, the OP's findings that setting the level colour to "clrNONE" does NOT work as expected.

This could be considered a bug, but I don't know if MetaQuotes is going to do anything about it.

I will give my opinion....

According to the documentation "clrNONE" equals -1.

And about "IndicatorSetInteger" it says the following:

Numbering of properties (modifiers) starts from 1 (one) when using the #property directive, while the function uses numbering from 0 (zero). In case the level number is set incorrectly, indicator display can differ from the intended one.

So I deduce that using "IndicatorSetInteger" with "clrNONE" is technically unfeasible because it may return a zero which is equal to the colour white (The numerical values of a colour component are between 0 and 255).

I insist, I haven't tested any of this, I'm just trying to shed some light on the subject.

 
@Miguel Angel Vico Alba #:

I will give my opinion....

According to the documentation "clrNONE" equals -1.

And about "IndicatorSetInteger" it says the following:

Numbering of properties (modifiers) starts from 1 (one) when using the #property directive, while the function uses numbering from 0 (zero). In case the level number is set incorrectly, indicator display can differ from the intended one.

So I deduce that using "IndicatorSetInteger" with "clrNONE" is technically unfeasible because it may return a zero which is equal to the colour white (The numerical values of a colour component are between 0 and 255).

I insist, I haven't tested any of this, I'm just trying to shed some light on the subject.


That refers to "0" indexing of the modifier parameter, not the property value parameter.

 
Fernando Carreiro #: That refers to "0" indexing of the modifier parameter, not the property value parameter.

I understand the point, but... What if the behavior is the same in modifier properties and property values and what we really have in front of us is a problem in the documentation?

Hopefully MQ will take note and fix it soon whatever the reason is.

Good job to all! ;-)

 
Miguel Angel Vico Alba #:

I understand the point, but... What if the behavior is the same in modifier properties and property values and what we really have in front of us is a problem in the documentation?

Hopefully MQ will take note and fix it soon whatever the reason is.

Good job to all! ;-)

Already reported ...

New comment