HMGforum.com

Posted: **Wed Apr 01, 2015 3:45 pm**

I can not considere an error when cancel during at GetColor selection and returns {Nil,Nil,Nil}
but...
in my criteria, when we define at first parameter as aDefaultColor, the returned value must be aDefaultColor at least.

: Screen1.png (17.88 KiB) Viewed 5205 times

IMHO, If this would be fixed, most of runtime errors and extra routines needed would it be avoided.

As it is now, when we use GetColor() is needing an user routine in order to avoid this error.

It would be marvel if we can count to use nested function without runtime error...

Like this, for example:

My_SetStatusBarBackColor("Form_1",GetColor(My_StatusBarColor))

Without the main concern of user cancel during GetColor selection.

This is my point of view. I do not know what my colleagues thinks. But this it could be easy improved.

Posted: **Wed Apr 01, 2015 4:35 pm**

Pablo César wrote:...
This is my point of view. I do not know what my colleagues thinks.

As a rule, all system dialog function returns an invalid value, when user canceled dialog. This give checking possibility to programmer if user canceled or enter a valid value.

Such as GetFile() function; if user canceled dialog, function return an empty string and empty string isn't a valid file name.

IMO checking return value of any system function is our opportunity:

Code: Select all

aCurColor := <aAnyValidColorArray>
aNewColor := GetColor( aCurColor )
IF aNewColor[ 1 ]  = NIL                         // User canceled dialog
   aNewColor :=  aCurColor
ENDIF

More, returning <aDefaultColor> means returning the parameter; since this is parameter came to the function. Personally I never seen a function returns parameter accepted.

Posted: **Wed Apr 01, 2015 4:53 pm**

Thanks for your interest, Esgici.

esgici wrote:More, returning <aDefaultColor> means returning the parameter; since this is parameter came to the function. Personally I never seen a function returns parameter accepted.

Just it would be the case of third parameter in MsgYesNo, where expected the cancel and returns according third parameter.

The main idea is to avoid extra checking return procedures and instead to let to use direct.

But I guess in this case should be created a new parameter like as aReturn, concerning retro-compatibility.

It's just an idea.

Posted: **Wed Apr 01, 2015 5:06 pm**

When selecting nothing (by CANCEL) old colors should be kept as it was (IMHO); so I prefer Pablo's solution.

Serge

Posted: **Wed Apr 01, 2015 5:12 pm**

Thank you Serge for your interest.

I also thinking that why checking return when is Nil if this would assume like as default color ?

I think we can wait for more opinions or probably HMG Development Team could explain something that we are not considering...

I wish to have automactic return with default value.

Posted: **Wed Apr 01, 2015 5:59 pm**

serge_girard wrote:When selecting nothing (by CANCEL) old colors should be kept as it was...

...kept as it was...

Are you sure ?

This code :

Code: Select all

MsgBox( HB_ValToExp( GetColor()), HMGVersion() )

produced same result with both HMG 3.0.46 and 3.4.0 when canceled GetColor() dialog box:

: GetColorTest3046.JPG (11.19 KiB) Viewed 5168 times

: GetColorTest340.JPG (11.47 KiB) Viewed 5168 times

in my machine; and yours ?

Happy HMG'ing

Posted: **Wed Apr 01, 2015 6:08 pm**

esgici wrote:in my machine; and yours ?

In everyone its the same. Upto this last HMG version, GetColor when be cancelled is returning {NIL,NIL,NIL} value.
(See at my first attached picture in this topic, what hmgdoc says)

I think is still very practical and do not need special treatment for any retro-compatibility (I guess) if will return as Default color (of course when have it been informed).

In case you want to continue checking return when is Nil and in that case you want to atribute different color than the current one, you could it have two options:

By GetColor() (without any parameter) then it could still return as {NIL,NIL,NIL}
By GetColor(<YourDefaultColor>)

By the second option at your old source codes, certaily will never be attended, because a DefaultColor was defined.
Of course if any modification will be approved in this suggested way.

Posted: **Wed Apr 01, 2015 7:05 pm**

Pablo César wrote:I can not considere an error when cancel during at GetColor selection and returns {Nil,Nil,Nil}
but...
in my criteria, when we define at first parameter as aDefaultColor, the returned value must be aDefaultColor at least.

Screen1.png
IMHO, If this would be fixed, most of runtime errors and extra routines needed would it be avoided.

As it is now, when we use GetColor() is needing an user routine in order to avoid this error.

It would be marvel if we can count to use nested function without runtime error...

Like this, for example:

My_SetStatusBarBackColor("Form_1",GetColor(My_StatusBarColor))

Without the main concern of user cancel during GetColor selection.

This is my point of view. I do not know what my colleagues thinks. But this it could be easy improved.

Pablo,
aDefaultColor --> specifies the color initially selected when the dialog box is created, for default is black.

Posted: **Wed Apr 01, 2015 9:32 pm**

Hi Claudio, thank you for your prompt reply !

srvet_claudio wrote:aDefaultColor --> specifies the color initially selected when the dialog box is created, for default is black.

Thi I know. The big step is to make this propose allied with the case of user make cancel of GetColor(aDefaultColour) and which normally returns {NIL, NIL, NIL} to be changed for returning aDefaultColour.
There is a logic intention to keep default color as initial and when be called by the suggested option.

I do not see any advantage to get {NIL, NIL, NIL} by returning when is cancelled by user, because this is not value color and the main propose is to get a new color or keeping the current color.

I know that we can make the checking value of returning. But if we add a simple path for GetColor function we will able to use it without in nested function too, avoiding runtime error when aDefaultColour parameter has been informed.

Here is source code for GetColor function at HMG library:

: Screen3.png (57.83 KiB) Viewed 5146 times

At indicated line by red arrow, I propose to be replaced by:

Code: Select all

	  If ValType ( aDefaultColor ) == "A"
	     aRetVal := aDefaultColor
	  Else
	     aRetVal := { NIL , NIL , NIL }
	  Endif

This changing will work with { NIL , NIL , NIL } return when be cancelled by user and not be informed aDefaultColor parameter for who wants to use for checking return. But also will work without runtime error when aDefaultColor is informed and user cancel the color selecting.

IMHO, will be great to be considered specially when we want to make something like this (nested function):

My_SetStatusBarBackColor("Form_1",GetColor(My_StatusBarColor))

This is a wish that I considered important for me. The big question is: how this it will be usefull for others without any retro-incompatibility.

I don't know if you know what I meaning.

Rgds

HMGforum.com

GetColor() return

GetColor() return

Re: GetColor() return

GetColor() return

Re: GetColor() return

GetColor() return

Re: GetColor() return

GetColor() return

Re: GetColor() return

GetColor() return