How to test if Color == CLR_NONE ? - page 2

 
RaptorUK:
I'm trying to use CLR_NONE in the same way it is used in OrderSend() or OrderClose()  for the default arrow colour . . .   color arrow_color=CLR_NONE   . . . I don't see it as a misuse.  

CLR_NONE  can be manually selected as a valid colour for any Object,  create an Object,  change it's colour and you will see the option of None at the top of the colour picker box. If the colour is set to None how does one then test for this ?


I understand your point of view, it's a weakness of MT4. I think in OrderSend() for example, CLR_NONE is very special as this implies NO OBJECT AT ALL. If you set a color MT4 draw an object with this color. If you use CLR_NONE does not draw any object. So I don't think you use CLR_NONE in the same way, or I'am wrong.

May be the simplest way to test is:

if (objcolor < 0) {   // COLOR is NONE
   ....
}
Is this working in all case ?
 
angevoyageur:

I understand your point of view, it's a weakness of MT4. I think in OrderSend() for example, CLR_NONE is very special as this implies NO OBJECT AT ALL. If you set a color MT4 draw an object with this color. If you use CLR_NONE does not draw any object. So I don't think you use CLR_NONE in the same way, or I'am wrong.

May be the simplest way to test is:

Is this working in all case ?

My end result may be something slightly different but the same test still needs to be done, the code for OrderSend()  will need to test if   arrow_color   is equal to CLR_NONE to determine if an arrow is to be drawn,  I wish to perform a similar test.

I am now doing this . . .

if (variable > White || variable < Black) 

 . . .  to test if  variable is equal to CLR_NONE and it seems to be working as intended.  

I perform this check inside my function for all color variables passed to the function,  for any that result in true I then set the variable to CLR_NONE,  this allows me to simply check if a variable is then equal or not equal to CLR_NONE later in the function,  for example . . .

// at the start of the Function after I have declared any local variables . . .

if (lProfitLine > White  || lProfitLine < Black) lProfitLine = CLR_NONE;


// then later I can do this test without any issues . . .
 
if (lProfitLine == CLR_NONE && OPType == OP_BUY) lProfitLine = lBuyLine; 

I did this so I could maintain the readability of my code. 

 

Without opening the inputs box in my test code everything seems to work,  it seems to be as  ubzen suggested ( almost )  is seems that the opening the inputs box changes the value held for any colour variables set to CLR_NONE to   - (White + 1)

:-) 

 
RaptorUK: Without opening the inputs box in my test code everything seems to work,  it seems to be as  ubzen suggested ( almost ).

Of-Course It's what I was suggesting. As soon as I opened that Script and Looked at the Default_Color for CLR_NONE. I knew it was part of the problem. 

Those Default Boxes seems to screw things up. I noticed this a long time ago with custom indicators. Sometimes you'll default values for Line_Color and Thickness, but when Loading Indicators, the Lines would sometimes be Black and Thicker than coded. Then when you hit the Reset button, it'll go back to what you intended.

Well, I'd never had the time to test my accusation above. Just wondering if anyone else noticed that before.

 
ubzen:
Of-Course It's what I was suggesting. As soon as I opened that Script and Looked at the Default_Color for CLR_NONE. I knew it was part of the problem. 

I knew what you meant . . .  but what you said was  "The show inputs is somehow changing it into -White."  it is being changed into  -(White + 1) , White is  16777215  hence why I said almost  ;-)


 
ubzen:


Well, I'd never had the time to test my accusation above. Just wondering if anyone else noticed that before.


I had noticed something similar with indicator line widths but assumed it was just me confusing things with changing defaults of line thickness etc. so I never investigated further.
 
RaptorUK:
I knew what you meant . . .  but what you said was  "The show inputs is somehow changing it into -White."  it is being changed into  -(White + 1) , White is  16777215  hence why I said almost  ;-)
Ah, humm, perhaps it wasn't White I was looking at. Something Whiter than White I suppose :))). Wait, that doesn't explain the negative. Man, I'd like to see some of these hidden functions like this one which determines how to Print Color.
 
ubzen:
Ah, humm, perhaps it wasn't White I was looking at. Something Whiter than White I suppose :))). Wait, that doesn't explain the negative. Man, I'd like to see some of these hidden functions like this one which determines how to Print Color.
Whiter than white ?  perhaps color "Tonny" ?
 

it seems indepth discussion going on n its interesting...may b i'll join sooner than later!

 
It seems that this issue has been fixed, I have no idea of what Build it was fixed in, I never had any reply to my Service Desk ticket . . .
Reason: