Bug? obj.strokeWidth breaking obj.width increases

Solar2D General Questions/Discussion
#1 
local cat2=display.newRect(160, 90.0, 0, 100)
cat2:setFillColor( 1 ) 
cat2:setStrokeColor( 1, 0 ,0 )
cat2.strokeWidth = 5 --problem line; breaks cat2

local cat1=display.newRect(160-100, 90, 0, 100)
cat1:setFillColor( 1,0,0 ) 
cat1:setStrokeColor( 0, 1 ,0 )
-- cat1.strokeWidth = 5 --problem line

Runtime:addEventListener("enterFrame", function(event)
	if cat1.width<50 then 
		cat2.width=cat2.width+ 1/2 --cat2.strokeWidth breaks the 1/2 value increase
		cat1.width=cat1.width+ 1/2
		print(event.frame.." ".. cat2.width)
	end
end)

These should increase at the same rate, they aren’t. The problem is the .strokeWidth line, comment it out and it’ll work as expected. If you flatout define .width as a new value it’ll work fine, but the gradual increase value is …messed up when .strokeWidth is defined.

I’m trying to make a beam (the laser sci fi type) …beams being lines that startout with a small width that gradually increases in width. Rectangles would seem appropriate in this case. The strokeWidth should make this easier, but without it I guess I have to define 1 rectangle for each side colour. Am I missing something or is this bugged? Again the value increase of 1/2 is skewed in a weird way, the skewed increases seems to be the same once u get to 1/10…so 1/100000 isn’t any different than 1/10.

Does it have something to do with it being .strokeWidth instead of :strokeWidth? I don’t understand why these aren’t all defined the same way with just : or just … Or why you can’t write cat2.setFillColor(cat2,1) to make them consistent. Is this a design decision or is there some reason I’m not understanding why I have to second guess if it’s : or . all the time? When I setup a lua function its a design decision whether to make it a function of self, and there’s never an instance where I can’t write a function call of self as player.update(player) instead of player:update()

cat2:setFillColor( 1 ) 
cat2:setStrokeColor( 1, 0 ,0 )
cat2.strokeWidth = 5

*transition.to seems able to change the strokeWidth over time without issue.

#2

Very interesting indeed, yes I think you have found a bug, or at least very weird behavior. I tried your code and you are right, strokeWidth really breaks setting the width of the object. What it seems to be doing is that after you set width of the object it adds another outer stroke width to it. However it adds it each frame, on top of previous width that already had strokeWidth added to it.

I found 2 workarounds around it.

  1. Setting strokeWidth to 0 before changing width and then immediately reapplying
Runtime:addEventListener( "enterFrame", function( event )
	if cat1.width < 50 then 
        cat2.strokeWidth = 0
		cat2.width = cat2.width + 0.5
        cat2.strokeWidth = 5

		cat1.width = cat1.width + 0.5
	end
end )
  1. On width change you manualy subtract outer strokeWidth of both sides, so it is not added again:
Runtime:addEventListener( "enterFrame", function( event )
	if cat1.width < 50 then 
		cat2.width = cat2.width + 0.5 - ( ( cat2.strokeWidth + cat2.strokeWidth % 2 ) )
		cat1.width = cat1.width + 0.5
	end
end )

As for other things you have mentioned:
1 )

.strokeWidth instead of :strokeWidth

because strokeWidth is not a function, therefore you can’t use object:strokeWidth = 5

2 )

Or why you can’t write cat2.setFillColor(cat2,1) to make them consistent.

You can if you want to, your example works just fine, you can rewrite all your : to . if it bothers you so much, personally I consider cat2.setFillColor( cat2, 1 ) just slightly less elegant and clean then usual cat2:setFillColor( 1 ).