display.newLine(sceneGroup, centerX, centerY, centerX, centerY) bug?

@gregbrady - FYI (in case of confusion), I was not responding to you above. I was responding to CoronaChris saying … oh well it must be a Corona bug.

The premise was wrong though because he is using the feature incorrectly to begin with and any unexpected results are then because of this incorrect usage.

@roaminggamer, i don’t agree with you. if the function let you define the value to 0 and behave wrong it’s a bug with that function, not the people that use it wrong. as a programmer when i do a function i always try to think about all the possibilities a user can do with that function, including bad practices, ofc it’s almost impossible to think of all, depending of the complexity of that function, so bugs appear time to time.

Of course our API’s need to be hardened to protect against invalid input, so if you find a way that causes it to misbehave we should look at addressing it. But if it’s fixable on the user end by not doing the invalid input, file a bug report and work around the problem.

That said, we need a sample project that demonstrates the error. This should include at a minimum a main.lua, config.lua and build.settings and any assets needed to duplicate the problem. Put this in a .zip file. It needs a project that we can simply build and install on a device and see the error happen. Once you have that, use the “Report a bug” link at the top of the forum page to file the report.

Thanks

Rob

I hear you and agree in part w/ what you’re saying, but at the same time I dont’ want to see any Corona functions over engineered to protect against things that don’t make sense and may cost a lot of cycles to detect and handle. i.e. I worry about the trade-off between robustness and performance.

Still. You make a good point. Sometimes zero (or near-zero) length segments can be introduced as part of a calculation on the user side and these are hard to catch, so having the SDK handle it would be nice.

@roaminggamer, I understand and agree with your point of over engineering and making more cycles than we need to make a function work properly. we have to make those decisions every day. it will depend in each function and the sweet spot  is hard to get sometimes.

But, usually those measures to make the function more rebust, are neglectable. It’s far more important to focus and optimize the rest of the code than those measures that can break your code in a second. I revise my code all the time to get it smaller/faster every day I look at it.