.ForeGround not accepting color constants - Gambas 3.3.4

[GoogleCodeExporter]

1) Describe the problem.

I created a config file that includes, [StartUp]
LabelColour="Color.Black".

The program includes:
lblTest.ForeGround =
      Settings["StartUp/LabelColour",
      "Color.White"]

When started, Gambas3 generates a line error,
"Type Mismatch: Wanted string got integer instead"

BreakPoints and debugging around the issue get what is expected,
Settings["StartUp/LabelColour",
      "Color.White"] = "Color.Black"

***Strange thing, when I wrote a test program it worked perfectly.***

Also:
lblTest.ForeGround = "Color.Black" generates no error messages.

I thought the Gambas3 code was the culprit but a removed and re-installed 
Gambas3 but still have the problem.

I checked the form and class codes but all seems in order.

This problem is not limited to this label. I tried textlabels and buttons also 
and the problem is duplicated with .ForeGround and .BackGround.

This is not normal behavior. I thought a reinstall would help. I also thought 
removing the Gambas3.conf and starting over but that doesn't help.

Any help . . .

2) GIVE THE FOLLOWING INFORMATIONS (if they are appropriate):

[System]
OperatingSystem=Linux
Kernel=3.2.0-35-generic-pae
Architecture=i686
Memory=3095920 kB
DistributionVendor=Ubuntu
DistributionRelease="Kubuntu 12.04.1 LTS"
Desktop=KDE4

[Gambas 2]
Version=2.23.1
Path=/usr/bin/gbx2

[Gambas 3]
Version=3.3.4
Path=/usr/local/bin/gbx3

[Libraries]
Qt4=libQtCore.so.4.8.2
GTK+=libgtk-x11-2.0.so.0.2400.10

3) Provide a little project that reproduces the bug or the crash.
A sample project does not duplicate the issue.

4) If your project needs a database, try to provide it, or part of it.

5) Explain clearly how to reproduce the bug or the crash.
include ???.Foreground = Settings[ ... and the problem arises.

6) By doing that carefully, you have done 50% of the bug fix job!

IMPORTANT NOTE: if you encounter several different problems or bugs, (for
example, a bug in your project, and an interpreter crash while debugging
it), please create distinct issues!

Original issue reported on code.google.com by t4769_a...@cogeco.ca on 23 Dec 2012 at 9:41

[GoogleCodeExporter]

further info . . .

I have a work around. I converted all the colours to numbers and came up with 
this

  ' set the foreground colour for the taglines and date/time
  lblMonthTime.ForeGround = Choose(Settings["StartUp/LabelColour", "4"],
    "0", "16711680", "65280", "16776960",
    "255", "16711935", "65535", "16777215")

It isn't elegant but it works.

FYI --- My program grabs a different full form image with each startup. 
Sometimes the image colours do not contrast enough with the label text so I 
came up with a few colours to change.

Also, I have a duplicate of the code that doesn't work in another form in the 
program and it works as expected.

I tried selecting all and pasting the code and controls onto another form but 
it didn't work.

Hope this helps.

Original comment by t4769_a...@cogeco.ca on 24 Dec 2012 at 12:48

[GoogleCodeExporter]

Color constants are... constants. Not strings.

In other words, you must type Color.Black, not "Color.Black".

Original comment by benoit.m...@gmail.com on 27 Dec 2012 at 6:30

• Changed state: WontFix
• Added labels: Version-TRUNK
• Removed labels: Version

[GoogleCodeExporter]

Thank You for the reply.

One of the options I tried during my debugging was your suggestion. I tried the 
option as an integer, string, and variant.

The attached file is a compressed project that shows that the .ForeGround 
property will accept strings contrary to your statement. This is what has me 
confused. Sometimes strings are accepted and sometimes (as your reply) not.

Sorry, but it works for me. I think (?)

May I suggest that this loophole be plugged.

Hope this helps.

Original comment by t4769_a...@cogeco.ca on 27 Dec 2012 at 2:53

Attachments:

• testing.tar.gz

[GoogleCodeExporter]

I have never said that the property won't accept strings. 

Actually the property does *not* accept strings, *but* in that case the 
language does automatic datatype conversion (note that it does automatic 
datatype conversion almost everywhere).

Do not rely on automatic datatype conversion if you don't understand it, and 
use normal constants as in any other programming language.

Original comment by benoit.m...@gmail.com on 27 Dec 2012 at 3:15