[Solved] RGB Colours As Long won't work

[mango]

I put RGB-Colours to variables like this:

Code: Select all

Dim myBLACK__ As Long, myGREY__  As Long, myRED__  As Long, myWHITE__  As Long
myBLACK__ = RGB(0,0,0)
myGREY__ = RGB(100,100,100)
myRED__ = RGB(255,0,0)
myWHITE__ = RGB(255,255,255)

Writing long integers to a text file and comparing the results to RGB-output results - as expected - in the same numbers

Code: Select all

oText.insertString ( oText.End, "myBLACK__: " + myBLACK__ + " myGREY__: " + myGREY__  + "  myRED__: " +  myRED__ + "  myWHITE__: " +  myWHITE__ + Chr(13), False )
oText.insertString ( oText.End, "myBLACK__: " +  RGB(0,0,0) + " myGREY__: " + RGB(100,100,100)  + "  myRED__: " +  RGB(255,0,0) + "  myWHITE__: " +  RGB(255,255,255) + Chr(13), False )

myBLACK__: 0 myGREY__: 6579300 myRED__: 16711680 myWHITE__: 16777215

Writing long integers as FillColor for example to a Textfield won't work. Everything is filled with black.

Code: Select all

               With oTextf
                 .FillColor = myGREY__
               End With

What works is:

Code: Select all

               With oTextf
                 .FillColor = RGB(Red(myGREY__),Blue(myGREY__),Green(myGREY__))
               End With

or of course

Code: Select all

               With oTextf
                 .FillColor = RGB(100,100,100)
               End With

If RGB calculates a long integer value internally to represent the three colour values and .FillColor itself requires a long integer, why then isn't it possible to use the defined variable?
I did this in LO Version: 6.2.3.2 (x64)

[Villeroy]

StarBasic is not a professional programming language. It is a little extra to this office suite. I've seen other problems with implicit type conversions. Same with Python as a macro language but the UNO bridge to Python provides helper functions to enforce type conversions when things don't work.

Anyway, I think your macro is too complex. Whenever it comes to formatting this or that snippet of text, I would resort to character styles. Make sure that your document is comes from a predefined template with predefined styles. Applying an arbitrary complex set of formatting attributes is a matter of one oSnippet.CharStylName = "MyHighlight"

[JeJe]

It might just be coincidence but if the long value was treated as a system color it would give black on my machine.

Code: Select all

Private Declare function GetSysColor Lib "user32" ( ByVal nIndex As Long ) As Long
Sub Main
icolor = rgb(100,100,100)
msgbox  GetSysColor (icolor) '0 = black
End Sub

[Lupp]

@mango: Why don't you attach your actual test file?
Its annoying to "study" as-if code. And if I want to test whether LibreOffice acts differently (based on a bugfix e.g.) I need to write code again-that may then differ in an unexpected and undetected way from the original. No use in wasting time this way.
And the generally repeated statements about Basic being "bad" are not very useful as long as there isn't evidence concerning what was treated in a wrong way by Basic. We all know that StarBasic isn't a "professional" programming language. Nonetheless it is a kind of reference language concerning the usage of the OOo/AOO/LibO API, and it's the shortest bridge to it.

[Villeroy]

And the generally repeated statements about Basic being "bad" are not very useful as long as there isn't evidence concerning what was treated in a wrong way by Basic.

https://bz.apache.org/ooo/show_bug.cgi?id=120069

[JeJe]

Re: https://bz.apache.org/ooo/show_bug.cgi?id=120069

So instead of declaring as long the OP should declare myGREY__ as a variant and see if that works. Like Lupp I don't want to go to the trouble of trying to recreate the OP's problem to test that...

[RPG]

I have somewhere read that BASIC types are not the same as UNO types for that reason there is maybe the function createunovalue. I have used it for a textbox in stead of a text field but it does not work goed without createunovalue.

Code: Select all

.BackgroundColor =CreateUnoValue("long",myGREY__)

[Lupp]

@Villeroy:
https://bugs.documentfoundation.org/sho ... ?id=125627

[mango]

Oh, sorry, it's not my intention to annoy anyone, nor to claim that Basic is "bad". On the contrary, I'm glad to have opportunities in basic to go ahead.
Admittedly I'm not an expert user as you surely are, but I'm doing my best to understand. When I'm asking, it's just to get a better understanding or to know if there might be a bug.
I understand that out of my scatterred code snippets it's hard to reproduce, so I compiled a snippet you can execute more easily.
Here we go

Code: Select all

Sub test_RGB

Dim mPoint As New com.sun.star.awt.Point   
Dim mSize As New com.sun.star.awt.Size    

Dim myBLACK__ As Long, myGREY__  As Long, myRED__  As Long, myWHITE__  As Long
Dim myBLUE__  As Long, myLIMEGREEN__  As Long, myYELLOW__  As Long, myBROWN__  As Long
Dim myMAGENTA__  As Long, myLIGHTGREY__  As Long
 
Dim oWriteDoc  ' Newly created Write document to contain the names.
Dim oText      ' Document text object.
Dim s : s = "private:factory/swriter"
'oWriteDoc = StarDesktop.loadComponentFromURL(s, "_blank", 0, Array())
'oText = oWriteDoc.getText()
'oText.insertString ( oText.End, "myBLACK__: " + myBLACK__ + " myGREY__: " + myGREY__  + "  myRED__: " +  myRED__ + "  myWHITE__: " +  myWHITE__ + Chr(13), False )
'oText.insertString ( oText.End, "myBLUE__: " + myBLUE__ + " myLIGHTGREY__: " + myLIGHTGREY__  + "  myLIMEGREEN__: " +  myLIMEGREEN__ + "  myYELLOW__: " +  myYELLOW__ + Chr(13), False )
'oText.insertString ( oText.End, "myBROWN__: " + myBROWN__ + " myMAGENTA__: " + myMAGENTA__  + "  myCOLOURS_Sept: " +  myCOLOURS_Sept + Chr(13), False )
'oText.insertString ( oText.End, "myBLACK__: " +  RGB(0,0,0) + " myGREY__: " + RGB(100,100,100)  + "  myRED__: " +  RGB(255,0,0) + "  myWHITE__: " +  RGB(255,255,255) + Chr(13), False )

myBLACK__ = RGB(0,0,0)
myGREY__ = RGB(100,100,100)
myRED__ = RGB(255,0,0)
myWHITE__ = RGB(255,255,255)
myBLUE__ = RGB(0,0,255)
myLIMEGREEN__ = RGB(50,205,50)
myYELLOW__ = RGB(255,255,0)
myBROWN__ = RGB(140,40,0)
myMAGENTA__ = RGB(255,0,255)
myLIGHTGREY__ = RGB(220,220,220)


file_$ = "D:\xxx\test_RGB.ods"
oDoc = FileOpen(file_$)
oSheets = oDoc.getSheets()          'Liste aller Tabellenblätter

oSheet = oDoc.createInstance( "com.sun.star.sheet.Spreadsheet" )

If Not oSheets.hasByName("test_RGB") Then
  oSheets.insertByName("test_RGB", oSheet)
Else
  oSheets.removeByName("test_RGB")
  oSheets.insertByName("test_RGB", oSheet)
End If

oSheet = oSheets.getByName("test_RGB")
oDrawPage = oSheet.DrawPage

oTextf = oDoc.createInstance("com.sun.star.drawing.TextShape")
mPoint.X = 2000
mPoint.Y = 2000
mSize.Width = 2000
mSize.Height = 1000
            
oDrawPage.add(oTextf)
With oTextf
   '.FillColor = RGB(Red(myLIGHTGREY__),Blue(myLIGHTGREY__),Green(myLIGHTGREY__))
   .FillColor = myLIGHTGREY__
   .LineStyle = com.sun.star.drawing.LineStyle.SOLID
   '.LineColor = RGB(Red(myGREY__),Blue(myGREY__),Green(myGREY__))
   .LineCOLOR = myGREY__
   .textVerticalAdjust   = com.sun.star.drawing.TextVerticalAdjust.CENTER
   .textHorizontalAdjust = com.sun.star.drawing.TextHorizontalAdjust.CENTER
   .FillStyle = com.sun.star.drawing.FillStyle.SOLID
   .String = "test_RGB"
   .CharFontName = "Arial"
   .CharHeight = 12
   '.CharColor = RGB(Red(myRED__),Blue(myRED__),Green(myRED__))
   .CharColor =myRED__
   .CharWeight = com.sun.star.awt.FontWeight.BOLD
End With
oTextf.setPosition(mPoint)
oTextf.setSize(mSize)

End Sub

Thanks again for helping

[JeJe]

That's better! I had to comment out the line oDoc = FileOpen(file_$) and put oDoc = ThisComponent

This works (and a constant not a variable is what you should use when the value doesn't change anyway):

Code: Select all

const myLIGHTGREY= 14474460
.FillColor = myLIGHTGREY

An array works as well:

Code: Select all

 cols = array(14474460,myLIGHTGREY__)
.FillColor =cols(0) 'or cols(1)

and so does

Code: Select all

   .FillColor = clng(myLIGHTGREY__)

[JeJe]

What appears to be the problem is the underscores at the end of your variable name
change myLIGHTGREY__ to myLIGHTGREY and it works fine

[Lupp]

Oh, sorry, it's not my intention to annoy anyone, ...

I didn't assume you intended. I stated you did.

... nor to claim that Basic is "bad".

This second part of my statement was addressed to Villeroy - and he responeded in a way I could act on.

I simply don't understand: You still didn't post an attachment allowing me (us) to simply reproduce your results - or to find out that the results depend on some specifics of the environment if they appear to be different on our systems. There are details on any level depending on
the exact version of AOO / LibO
the Operating System
the user profile
the ... (whatever).
You can trust in the contributors here to know a lot about such effects. What were your reasons to refuse the attachment?

When I'm asking, it's just to get a better understanding or to know if there might be a bug.

Of course, but
I'm also interested in both these directions...
The best way to find out is running tests...
Test should be based on exactly the same code you used. Errors introduced by editing / copying should be excluded.

I'm not an expert user as you surely are, ...

I'm not claiming to be an expert user. If you consider me being one, however, you first of all should be ready to act on my suggestions concerning the proceedings in the forum. Among them very often: "Attach the real thing!"

[JeJe]

_my_LIGHTGREY_1 works _my_LIGHTGREY_ fails

Don't end a variable name in an underscore.

Edit:

Or use Clng.

The below works okay so maybe the problem is confined to setting these properties and maybe it occurs other places too...

Code: Select all

sub dotest
dim my_LIGHTGREY__ as long
my_LIGHTGREY__= RGB(220,220,220)
msgbox my_LIGHTGREY__
testf my_LIGHTGREY__
msgbox my_LIGHTGREY__
end sub

sub testf(v_) 
v_=v_+1
end sub

[Lupp]

The underscore at the end should be allowed. The fact that it may cause an error is not due to the syntax for chosen names in AOO/LibO Basic. It is a bug that may be caused by the Basic parser ("compiler") misinterpreting an underscore character at the end of a line as a "continued after line break".
Concerning such issues Basic actually is "bad". I read a lot about different dialects of Basic (mainly some decades ago), but I nowhere (and in specific not for Star/OOo/AOO/LibO -Basic) found a clear and complete syntax.

Thus
Syntax for names

Code: Select all

<name> ::= <letter>|<name><letter>|<name><decimal digit>|<name>_

Semantical restriction concerning StarBasic:
A name used at the very end of a command line is not allowed to end with an underscore. If you want to use such a variable name as the last term of an expression, you need to disambiguate it, best by enclosing it in parentheses.
For names of variables used for numbers you can instead append a "+0". In case of use for string variables the respective alternative is obvious.
Whitespace behind the problematic underscore will not disambiguate it.

Amendments:
In fact StarBasic also accepts an underscore as the first character of a name. Some macros included with the installation are named this way. I would suggest as a rule of good practise to not employ this in everyday work.

See also: https://bugs.documentfoundation.org/sho ... ?id=125637

[JeJe]

Yeah, its a general problem. The following assignment fails in both OO and LO:

Code: Select all

Sub Main
dim a_ as long,  b as long
a_ = 7

b = a_
msgbox b '=0 not 7
End Sub

DON'T USE AN UNDERSCORE AT THE END OF A VARIABLE NAME.

[Lupp]

(I edited my post above an hour ago.)

[JeJe]

Adding ' at the end of the line is another simple fix. This works:

Code: Select all

Sub Main
dim a_ as long,  b as long
a_ = 7

b = a_ '
msgbox b 'correctly 7 without the ' on the above line its 0
End Sub

Edit: option explicit will pick up that there's a problem and give a variable not defined error - another reason to use that.

Code: Select all

option explicit
Sub Main
dim a_ as long,  b as long
a_ = 7

b = a_ 
msgbox b
End Sub

[mango]

Thanks all, leaving the underscores at the end solved the problem.

@ Lupp

the exact version of AOO / LibO
the Operating System

I couldn't find quickly how to adapt my signature, so I wrote that in my first post.

I'm also interested in both these directions...
The best way to find out is running tests...
Test should be based on exactly the same code you used. Errors introduced by editing / copying should be excluded.

I understand that. That's why I added the snippet in the second post, it exactly showed the problem in the TextShape created (o.k. I should have left out the text file output). Using the variables ending with underscore will result in a black box. My original macro is about 1000 lines, who would read that? And what's the difference putting it in a snippet or attaching it?