setFillColor bug ?

[bbk]

I started a topic yesterday where I had problems using the setFillColor function on display.newText

One reply was a short test code that should work, and it did.

I then found out that my code had once used the “setFillColor” function wrong, and thereafter this function does not work.

This works:

local black = { 0, 0, 0, 1 } local red = { 1, 0, 0, 1 } local tmp = display.newText( "Hi this is a test", display.contentCenterX, 150 ) tmp:setFillColor( unpack( black ) ) timer.performWithDelay( 1000, function() tmp:setFillColor( unpack( red ) ) end)

this (without unpack()) does not work

local black = { 0, 0, 0, 1 } local red = { 1, 0, 0, 1 } local tmp = display.newText( "Hi this is a test", display.contentCenterX, 150 ) tmp:setFillColor( black ) timer.performWithDelay( 1000, function() tmp:setFillColor( unpack( red ) ) end)

I am using Corona SDK - on the Mac: Version 2018.3319 (2018.6.18)

[nick_sherman]

Does the second set of code generate any errors? If you’re getting a runtime error, how your app behaves after this may be unpredictable.

Of course, the solution is to just fix the code, it can’t really be called a bug in Corona if you are calling a function with invalid parameters.

[Develephant]

Hi,

As noted, this would not be considered a bug. The documentation states that the arguments are numbers, not a table (https://docs.coronalabs.com/api/type/ShapeObject/setFillColor.html).

The Lua unpack method just transforms the table data into comma delimited values, so…

tmp:setFillColor( unpack( red ) )

actually becomes…

tmp:setFillColor( 1, 0, 0, 1 )

at runtime.

Using the table with unpack is just a clean way to create a color constant.

-dev

[davebollinger]

in my opinion there IS a bug here:  setFillColor should be raising an error when passed invalid arguments, something along the lines of

main.lua: 11:  bad argument #1 to 'setFillColor' (number expected, got table)

like most other API calls would generate.

because as the OP notes (although it’s perhaps not obvious that this is his point) once you issue this “bad” command, apparently without error, then subsequent “good” commands no longer take effect because the rect’s fill is now somehow bugged:

local rect = display.newRect(100,100,50,50) rect:setFillColor({}) -- invalid syntax, but no error, causes rect fill to be bugged rect:setFillColor(1,0,0) -- valid syntax, and no error, but no longer works, remains black

[nick_sherman]

Fair point, I hadn’t realised this doesn’t raise an error.

[rob]

Can we get someone to file a bug report on this?

Thanks

Rob

[davebollinger]

i’ll bet this will be tricky to fix.  why?

consider this sort of thing:

local rect = display.newRect(100,100,50,50) rect.fill = { type = "gradient", color1 = { 1, 1, 1 }, color2 = { 1, 0, 0 } }

then contrast with this:

local rect = display.newRect(100,100,50,50) rect:setFillColor({ type = "gradient", color1 = { 1, 1, 1 }, color2 = { 1, 0, 0 } })

so obj:setFillColor is just meta-magic with obj:fill – not in the docs, but works, and is probably “why” it accepts a table without error

[bbk]

Even though a wrong value for :setFillColor does not work, it is strange that it should break the objects method, so that it is not possible to set/change its color.

[nick_sherman]

Does the second set of code generate any errors? If you’re getting a runtime error, how your app behaves after this may be unpredictable.

Of course, the solution is to just fix the code, it can’t really be called a bug in Corona if you are calling a function with invalid parameters.

[Develephant]

Hi,

As noted, this would not be considered a bug. The documentation states that the arguments are numbers, not a table (https://docs.coronalabs.com/api/type/ShapeObject/setFillColor.html).

The Lua unpack method just transforms the table data into comma delimited values, so…

tmp:setFillColor( unpack( red ) )

actually becomes…

tmp:setFillColor( 1, 0, 0, 1 )

at runtime.

Using the table with unpack is just a clean way to create a color constant.

-dev

[davebollinger]

in my opinion there IS a bug here:  setFillColor should be raising an error when passed invalid arguments, something along the lines of

main.lua: 11:  bad argument #1 to 'setFillColor' (number expected, got table)

like most other API calls would generate.

because as the OP notes (although it’s perhaps not obvious that this is his point) once you issue this “bad” command, apparently without error, then subsequent “good” commands no longer take effect because the rect’s fill is now somehow bugged:

local rect = display.newRect(100,100,50,50) rect:setFillColor({}) -- invalid syntax, but no error, causes rect fill to be bugged rect:setFillColor(1,0,0) -- valid syntax, and no error, but no longer works, remains black

[nick_sherman]

Fair point, I hadn’t realised this doesn’t raise an error.

[rob]

Can we get someone to file a bug report on this?

Thanks

Rob

[davebollinger]

i’ll bet this will be tricky to fix.  why?

consider this sort of thing:

local rect = display.newRect(100,100,50,50) rect.fill = { type = "gradient", color1 = { 1, 1, 1 }, color2 = { 1, 0, 0 } }

then contrast with this:

local rect = display.newRect(100,100,50,50) rect:setFillColor({ type = "gradient", color1 = { 1, 1, 1 }, color2 = { 1, 0, 0 } })

so obj:setFillColor is just meta-magic with obj:fill – not in the docs, but works, and is probably “why” it accepts a table without error

[bbk]

Even though a wrong value for :setFillColor does not work, it is strange that it should break the objects method, so that it is not possible to set/change its color.