Trying to use RGB() function from Core to set Color on .Net control...

[Chris]

Just to explain why we need to make it work in a compatible way with VFP:

I guess it is very possible that people in VFP have written code like that:

LOCAL color
...
color = RGB(30,50,100)
...

LOCAL blue
blue = Mod(color , 256)
....

LOCAL newcolor
newcolor = RGB(255,0,blue) // create a new color based on the previous one

With the current X# implementation of RGB(), this code will continue working just fine. If we made RGB() return a system.Drawing.Color object instead, then the above code would still compile, but would throw an error at runtime. So VFP programmers would need to go to all such occurrences in their code and change it (possibly in thousands of lines...) so that it takes into account the new behavior of RGB().

Obviously nobody would want to do that and we also do not want to force people to make such and so many changes. And that does not apply only to RGB(), but the same concept applies to every other VFP function and code construct.

[lumberjack]

RGB is a VO compatibilty function. We should probably move it out of XSharp.Core and into XSharp.VO.
VO did not know System.Drawing.Color

I initially thought the problem can be solved by a mere overloaded function, but alas VO RGB() return a Number (DWORD), while the VFP RGB() return a Color object. I second what you suggest.
Just my 2c worth.

[FoxProMatt]

Chris - Indeed, it is complex, and will need to be figured out.

The use case that I was tackling was a .net UI control where I needed to apply a set of rgb integers from VFP to a .net Color, so I assumed RGB(), or some version of it, was the way to go.

It’s easy to teach or document what to do when writing new code, but I don’t know the answer of how to easily handle this when converting exiting VFP code to work with native .Net UI controls.

[FoxProMatt]

Johan - Native VFP RGB() returns an integer, not a Color object. VFP has no such thing as a Color object.

The RGB() function in the VFP Toolkit for .Net does return a Color object.

[Karl-Heinz]

Hi Karl-Heinz,

Are you absolutely sure? I do not have SP3 to check, but I checked it in VO27 and already in it it returned a DWORD.

Hi Chris,

I´m absolutely sure.

The 2.8 SP3 declaration looks a a little bit strange ( note the two missing AS BYTE ) :

_DLL FUNCTION RGB (bR, bG, bB AS BYTE) AS INT PASCAL:VO28RUN.Rgb

But it works as expected:

Code: Select all

LOCAL iColor AS INT  
   
    iColor := RGB ( 127 , 0 , 127 )  

while this throws the error:

"overflow or loss of data possible converting longint -> dword:51422"

Code: Select all

LOCAL dwColor AS DWORD

    dwColor := RGB ( 127 , 0 , 127 )  

I´ve never used 2.7, but i´ve started in a VM VO 2.5b3 and indeed a DWORD is returned - can´t remember that It seems that at least 2.8 SP3 introduced the INT, while SP4 switched back to a DWORD again.

There are also some places in the x# GitHUb VO sources that indicate that RGB () did return an INT:

e.g.

CLASS MailTreeView INHERIT TreeView

METHOD CustomDraw(lParam)
LOCAL pNMCustomDraw AS _winNMLVCUSTOMDRAW
LOCAL dwDrawStage AS DWORD

pNMCustomDraw := PTR(_CAST, lParam)
dwDrawStage := pNMCustomDraw.nmcd.dwDrawStage

IF dwDrawStage = CDDS_PREPAINT
RETURN CDRF_NOTIFYITEMDRAW
ELSEIF dwDrawStage = CDDS_ITEMPREPAINT
IF _And( pNMCustomDraw.nmcd.uItemState , CDIS_SELECTED ) > 0
pNMCustomDraw.clrText := DWORD(RGB(255, 255, 255))
pNMCustomDraw.clrTextBk := DWORD(RGB(0, 0, 128))
ELSE
pNMCustomDraw.clrText := DWORD(RGB(0, 0, 0))
pNMCustomDraw.clrTextBk := DWORD(RGB(190, 255, 255))
ENDIF
ENDIF

RETURN CDRF_DODEFAULT


regards
Karl-Heinz

[lumberjack]

Hi Matt,

The use case that I was tackling was a .net UI control where I needed to apply a set of rgb integers from VFP to a .net Color, so I assumed RGB(), or some version of it, was the way to go.
(snipped...)but I don’t know the answer of how to easily handle this when converting exiting VFP code to work with native .Net UI controls.

The standard UI Winform do it this way, no need to call RGB()

Code: Select all

SELF:oTextBox2:BackColor := System.Drawing.Color.FromArgb( 0,0,170 )
SELF:oTextBox3:BackColor := System.Drawing.Color.Brown

[robert]

Karl-Heinz, Chris,

I know it's strange but you are both right. The function RGB in VO has been defined twice with a different prototype:

In VOLIBSysLibStdLib.prg as
_DLL FUNCTION RGB (bR, bG, bB AS BYTE) AS DWORD PASCAL:VO28RUN.Rgb

However the repo has this function ion SysLib.prg
_DLL FUNCTION RGB (bR, bG, bB AS BYTE) AS INT PASCAL:VO28RUN.Rgb

I am not sure how this difference was created but it should have been the same, since the repo was created from this SysLib.prg.
Apparently the source in SysLib.prg has been changed since the last time the repo was built.
In 2.8 SP4 both definitions are:
_DLL FUNCTION RGB (bR, bG, bB AS BYTE) AS DWORD PASCAL:VO28RUN.Rgb

Robert

Robert




There is also a (commented out) source code version of this in the Win32 source (wingdi.prg)

[FoxProMatt]

Johan - Here is what I have coming out of a VFP repo:

2019-05-05 15_33_35-H__Work_Repos_XSharp.VFP_VFP Conversion Test 1_VFP Repo Exported_SampleClasslib1.png (12.6 KiB) Viewed 489 times

So, a string of 3 numbers, separated by 2 commas. Now I have to render that into a corresponding .Net control property with a function of some sort to get in into a Color object.

It's basically just some string manipulation, so it's not rocket science, but there are lots of "xxxColor" properties in VFP, and they have to be mapped to the correct .Net Color property, if present, or add a wrapper property with the same name as the VFP property and map it to the correct .Net property in the Setter.

[lumberjack]

Johan - Here is what I have coming out of a VFP repo:

2019-05-05 15_33_35-H__Work_Repos_XSharp.VFP_VFP Conversion Test 1_VFP Repo Exported_SampleClasslib1.png

So, a string of 3 numbers, separated by 2 commas. Now I have to render that into a corresponding .Net control property with a function of some sort to get in into a Color object.
It's basically just some string manipulation, so it's not rocket science, but there are lots of "xxxColor" properties in VFP, and they have to be mapped to the correct .Net Color property, if present, or add a wrapper property with the same name as the VFP property and map it to the correct .Net property in the Setter.

Can you give some examples of the Color formats for "Black, Cyan, etc."? Am sure those directly map onto the same name in .NET...

[FoxProMatt]

2019-05-08 09_30_20-Untitled 1 - LibreOffice Calc.png (14.49 KiB) Viewed 489 times