reduce the number (counting) of color-settings in the color-tab ?

New comment
 

Hello,

Another question slows me out... I've made an indicator with several lines in the main-chart. But I need only two different colors. So it is kidding to set each used buffer one by one.

This simple trick isn't working:

#property indicator_width1 1
#property indicator_color1 clrFireBrick
#property indicator_style1 STYLE_SOLID

...

SetIndexStyle( 2, DRAW_LINE, indicator_style1, indicator_width1, indicator_color1);
SetIndexStyle( 3, DRAW_LINE, indicator_style1, indicator_width1, indicator_color1);
SetIndexStyle( 4, DRAW_LINE, indicator_style1, indicator_width1, indicator_color1);

The result is the same as with every #property command per indicator.

Is there a trick for two style selectors in the color-tab working on many buffers ?

Thanks again :-)

 

Something more like this?

input int   width1=1;
input color color1=clrFireBrick;
input ENUM_LINE_STYLE style1=STYLE_SOLID;

int OnInit()
  {
   for(int i=2; i<5; i++) 
     {
      SetIndexStyle(i,DRAW_LINE,style1,width1,color1);
     }
 

Ah ! Ok, it's a 'yes, but...' reply:

At first I thought, wow that's cool, he steels the written index, so the compiler can't catch the bufferLines... But it could :-(    Perhaps because I have to link a buffer with SetIndexBuffer(...)

Again, yours is a solution and thanks for that ! But I like the idea of seperating the cosmetic properties and the mathematics (the colour-tab and the input-tab).

Within the input-tab you are the cheef of content with 'input double xy'. In the colour-tab the compiler seem to list every line it has to paint against any coding. And this is sad, sometimes. I would like to say also what has to be in there and what not.

But i'm not sure if we are the end of all knowledge...


One additional notice: Coincidental I find out, that

#property indicator_buffers 4

is dominant against 

IndicatorBuffers(8);

The first command reduce the count of indicator-Lines AND with it the count of properties in the colour-tab whatever you say with 'IndicatorBuffers()'. But then the other lines above 4 (here) are not paint as well :-(

 
Abejorro:

Ah ! Ok, it's a 'yes, but...' reply:

At first I thought, wow that's cool, he steels the written index, so the compiler can't catch the bufferLines... But it could :-(    Perhaps because I have to link a buffer with SetIndexBuffer(...)

Again, yours is a solution and thanks for that ! But I like the idea of seperating the cosmetic properties and the mathematics (the colour-tab and the input-tab).

Within the input-tab you are the cheef of content with 'input double xy'. In the colour-tab the compiler seem to list every line it has to paint against any coding. And this is sad, sometimes. I would like to say also what has to be in there and what not.

But i'm not sure if we are the end of all knowledge...

I think that you have missed the point of Honest Knave's post.

By having the color etc as an input, there is no need for

#property indicator_width1 1
#property indicator_color1 clrFireBrick
#property indicator_style1 STYLE_SOLID
//And so on for each indicator line
 
GumRai:

By having the color etc as an input, there is no need for

Oh yes, this is for sure ! And this is helpful !

But if I like to seperate the colour and design-stuff in a different tab on the user-side ?

So let me change my question a little: What is the way to rule the properties (number over all) in the colour-tab ?

 
Abejorro:

So let me change my question a little: What is the way to rule the properties (number over all) in the colour-tab ?

Can you change the question a little more please? I don't know what you are asking.
 

Yes, with pleasure:

1. target: A lot of Indicatorlines, may be 8.

2. target: the mathematic-properties in the INPUT-tab to the user (input decl name;)

3. target: they have made the COLOUR-tab to the user. And to me it seems to be straight to seperate the cosmetics to that area. But the compiler is collecting every indicatorline there and put it in a list. (ALL of them) I would like to see THERE (in the colour-tab) only - e.g. - two rows with selections influencing all the 8 lines.

With my recent knowledge I must say, in this tab are all IndicatorLines listed, whatever you do. Of course, you can ignore and work with input. But may be, there is a simple trick to controll the quantity of rows in that colour-tab ?

I hope, I could describe my wishes ? It's not the battle of my life but may be nice to have.
 

It is my personal preference to totally ignore the colors tab. Primarily because the lines were only given a number and when there are 8 (or more now) buffers it wasn't always easy to change the actual intended line.

In my opinion, it is much better to have the color in the inputs where you can easily know which line you are changing the color.

Things may have changed now, I don't know as I haven't checked. I just think that it is more sensible to have the color as an input parameter. 

 
Abejorro:

One additional notice: Coincidental I find out, that

is dominant against

The first command reduce the count of indicator-Lines AND with it the count of properties in the colour-tab whatever you say with 'IndicatorBuffers()'. But then the other lines above 4 (here) are not paint as well :-(

#property indicator_buffers sets the number of drawn buffers

IndicatorBuffers() sets the total number of buffers (drawn buffers + calculation buffers)

There is an entry in the IndicatorBuffers() help file, but it isn't very well written: 

 The amount of buffers cannot exceed 512 and be less than the value set in #property indicator_buffers. If a custom indicator requires additional buffers for counting, IndicatorBuffers() function should be used for specifying the total amount of buffers.

 

 

Abejorro:

Yes, with pleasure:

1. target: A lot of Indicatorlines, may be 8.

2. target: the mathematic-properties in the INPUT-tab to the user (input decl name;)

3. target: they have made the COLOUR-tab to the user. And to me it seems to be straight to seperate the cosmetics to that area. But the compiler is collecting every indicatorline there and put it in a list. (ALL of them) I would like to see THERE (in the colour-tab) only - e.g. - two rows with selections influencing all the 8 lines.

With my recent knowledge I must say, in this tab are all IndicatorLines listed, whatever you do. Of course, you can ignore and work with input. But may be, there is a simple trick to controll the count of rows in that colour-tab ?

By the way: What is the perfect and most precise word in english for "result of counting rows", not numbering (what is done there as well) ?

I hope, I could describe my wishes ? It's not the battle of my life but may be nice to have.

 I don't think you can override the color tab - it will always show you a entry for each drawn buffer. But I'm happy to be proven wrong! 

 
GumRai:

It is my personal preference to totally ignore the colors tab. Primarily because the lines were only given a number and when there are 8 (or more now) buffers it wasn't always easy to change the actual intended line.

In my opinion, it is much better to have the color in the inputs where you can easily know which line you are changing the color.

Things may have changed now, I don't know as I haven't checked. I just think that it is more sensible to have the color as an input parameter. 

That's my personal preference too.
 

muchas gracias for your answers ! You have strong arguments, sure the color of a indicator might be usefull organised together with its further parameters. Particularly with that argument it should be better, we could set this whole tab invisible to prevent any confusion... Anyway, up to now this will be the end of this road.

Reflecting this - and the new knowledge of 'IndicatorBuffers()' ! - brings me a few steps deeper in this software.  So, thanks again !

New comment