BackgroundWidth required for NewSwitch?

Solar2D Widgets
#1

Is anyone else getting this error for widget.newSwitch() on the latest daily?

“/scene.lua:87: ERROR: widget.newSwitch: backgroundWidth expected, got nil”

87 local switch1 = widget.newSwitch

88    {

89        left = 20,

90        top = 10,

91        initialSwitchState = true

92    }

I did a quick check for backgroundWidth, apparently this is required for picker wheels?

Upon addition of backgroundWidth and other required lines, I added:

        backgroundWidth = 0,

        backgroundHeight = 0,

        overlayWidth = 0,

        overlayHeight = 0

and ended up with an error of:

WARNING: display.newImage( imageGroup, frameIndex ) given an invalid frameIndex (0). Defaulting to 1.

ERROR: sequenceData missing data. One of the following must be supplied: a pair of properties ‘start’/‘count’ or an array value for the property ‘frames’.

Though, I’m not surprised, given that I’m using 0 and its doing strange things already.

Edit: I’m a fool. I assigned the iOS theme as a default theme, thus making it a custome theme. So I think it wants me to tell it the size of the image. Ah well.

Edit: Edit: Nope, appears not to be the problem. I took out the setting of theme, so that it does what it has always does, the problem remains, so I don’t know what is wrong.

#2

Hi @Mourdos,

Please review the property names specific to the On/Off switch (which I assume you want, since you didn’t specify “radio” or “checkbox”, and on/off is the default type of switch). The property names vary from widget to widget.

http://docs.coronalabs.com/api/library/widget/newSwitch.html

Best regards,

Brent

#3

Yes, I get the same problems by going to a recent build to try to solve another problem with list; and now I get this as well.

T he switch I have worked fine and is a basic ordinary slide switch with new corona image. I was really pleased as it  worked and avoided worrying about visual image setups. Straight forward and easy to use and avoided me going to  use third party widgets such as Candy Widgets.

I will have to back off until this problem is resolved because it now looks as it is expecting visual modifications -I hope it is just a bug and not a design and specification change.

I have just run the example that Brent referenced and that fails the same way.

----here is the example that fails

local widget = require( “widget” )

– Handle press events for the switches
local function onSwitchPress( event )
    local switch = event.target

    print( switch.id, “is on?:”, switch.isOn )
end
– Create a default on/off switch (using widget.setTheme)
local onOffSwitch = widget.newSwitch
{
    left = 130,
    top = 300,
    initialSwitchState = true,
    onPress = onSwitchPress,
    onRelease = onSwitchPress,
}

#4

Just gone back to my prior Corona level Version 2013.1135 (2013.6.3) and this is working fine.

with or without widget.setTheme( “widget_theme_ios” ).

So which build is wrong?

Thanks

#5

Please file a bug report on this.

#6

Rob,

This may be the process but I am getting very frustrated at this end as i feel we are Corona testers rather than Corona developers.  You have sufficient details on these forum postings to put in and solve the bug without us having to spend more time as system testers.

I know you will remove this but I think you and staff should know our(my feelings).

We are paying good money for a rather over (hyped) advertised product that is good in some places but is like touching a tower of cards in others.

#7

Please be aware that the widgetDemo is broken as well due to this issue.

#8

Hi Cockle.  Why would we remove this?  It’s a perfectly valid opinion.  We welcome valid criticism.  Its far different that someone trolling the forums on an anonymous account created 10 minutes ago who’s only post is “You guys stink”.  Trolling, not permitted.  Speaking your mind because you don’t like what we are doing is more than welcome.  It’s part of how we improve our product. 

Now to address your concerns. 

Daily builds are builds with the latest features and bug fixes.  Daily builds, by their nature are cutting edge and from time to time, bugs get introduced.  Some programmers don’t use daily’s at all because they want to release on the stable code base.   It takes time to QA these things but in the quest to get you features and fixes faster, there is the risk that bugs can get introduced.  This looks like a regression bug.

Forums by their nature are great to help us solve bugs that are not bugs.  If you filed bug reports on everything that didn’t work, our bug tracker would be overwhelmed.  So the forums are kind of the first line of defense in sorting out if it’s a bug or not and what the severity and the impact of a bug is.  I would say that 95% of the things people report as bugs in the forums end up being bugs in their code.  Asking the engineers to filter though that much noise is problematic.

If we ask you to file a bug report, it’s not because we are being an pain in the behind, but you are the one experiencing it and you are the best one to communicate it.  You have code that can demo the problem and so on.  The work engineers do with regards to bugs is based mostly on what is in our bug tracking problem.  There are a couple of notable exceptions:

   Major issues like:  we can’t build.  B&N is rejecting evey app. 

   Major releases of new functionality, like Widgets 2.0.  The engineer was using the forums in the first couple of weeks because it was a good way to communicate with you.  But now that Widgets 2.0 is pretty solid, the engineers are now back to using things in the bug tracker.

When we ask you to file a bug report, it’s because we believe that it is a bug that we need to address, that we can’t get you a good workaround too and that we want the engineers to look at.  Stuff posted here isn’t tracked and its simply the wrong software for this most of the time.

#9

Rob,

Thanks for your tolerance and careful response!

Generally your comment is correct and in general I would agree, if, and only if, the problem was unique to an individual.

Here it is not unique.

Here the case is different and demonstrates to us (me) that no real regression testing is done. These problems are showing up on simple examples that you guys put together as code for your paying and non-paying users  to help them understand the widgets.

The example of this particular problem is posted here, stated as being your code, and it would be encouraging to me to see that someone in your team being proactive and pick these simple and easily copy pasted code (from your examples which you must have around as well) and went fixed it.

So that’s my point I sit here with a paid up subscription (getting really annoyed that it is being raised so high for a product that is not ‘finished’, is in a state of daily flux and is not properly unit tested).

Going to a daily build is a ‘risk’ , we know, but when things on a public announced release don’t work, or you announce a new and improved ‘thingy’ change not in the public release,  your team advise us ‘it is fixed in the daily build’.  We are told to use the daily build to verify and check the good work you are doing on widgets. Then if we  find simple ‘examples’ have regressed rather than a problem is fixed,  it is not what I would expect from a quality product with good routine (in house!!)regression testing.

Also I would expect a ‘war room’ team verifying and approving any changes  to the daily build (or at least the public release and change announces) since this is a critical window on your product. I am not confident any of this is happening.

So to re-state.

It is your code, your examples, your development so why do you think we should do all the work to create test cases against your examples. Come-on I was not born yesterday and  a quality team would not have shipped this, even in a daily build.

I mentioned Candy-Widgets third party product earlier , a stable, easy to use and ‘cheap’ . I am considering switching to their widgets until your widgets are ‘stable’ and re-look at Xcode longer term.

I am spending too much time trying to decide if a widget  problem is either,  a bug  in my code, or yours, a need for re-training  or re-testing  after each news letter and build update of ‘improvements’ to widgets. Widgets that have been changing for three years or more. So using a stable high quality third party product seems the safer interim until I go Xcode.

Alec

#10

Hi @cockle,

Your points are logical, and so are Rob’s… they remain as the official policy for the reasons he explains. In this particular case with newSwitch(), it is a regression bug, and because of that I will discuss it with engineering this week. It should be fixed in an upcoming daily.

Best regards,

Brent

#11

Hi @Mourdos,

Please review the property names specific to the On/Off switch (which I assume you want, since you didn’t specify “radio” or “checkbox”, and on/off is the default type of switch). The property names vary from widget to widget.

http://docs.coronalabs.com/api/library/widget/newSwitch.html

Best regards,

Brent

#12

Yes, I get the same problems by going to a recent build to try to solve another problem with list; and now I get this as well.

T he switch I have worked fine and is a basic ordinary slide switch with new corona image. I was really pleased as it  worked and avoided worrying about visual image setups. Straight forward and easy to use and avoided me going to  use third party widgets such as Candy Widgets.

I will have to back off until this problem is resolved because it now looks as it is expecting visual modifications -I hope it is just a bug and not a design and specification change.

I have just run the example that Brent referenced and that fails the same way.

----here is the example that fails

local widget = require( “widget” )

– Handle press events for the switches
local function onSwitchPress( event )
    local switch = event.target

    print( switch.id, “is on?:”, switch.isOn )
end
– Create a default on/off switch (using widget.setTheme)
local onOffSwitch = widget.newSwitch
{
    left = 130,
    top = 300,
    initialSwitchState = true,
    onPress = onSwitchPress,
    onRelease = onSwitchPress,
}

#13

Just gone back to my prior Corona level Version 2013.1135 (2013.6.3) and this is working fine.

with or without widget.setTheme( “widget_theme_ios” ).

So which build is wrong?

Thanks

#14

Please file a bug report on this.

#15

Rob,

This may be the process but I am getting very frustrated at this end as i feel we are Corona testers rather than Corona developers.  You have sufficient details on these forum postings to put in and solve the bug without us having to spend more time as system testers.

I know you will remove this but I think you and staff should know our(my feelings).

We are paying good money for a rather over (hyped) advertised product that is good in some places but is like touching a tower of cards in others.

#16

Please be aware that the widgetDemo is broken as well due to this issue.

#17

Hi Cockle.  Why would we remove this?  It’s a perfectly valid opinion.  We welcome valid criticism.  Its far different that someone trolling the forums on an anonymous account created 10 minutes ago who’s only post is “You guys stink”.  Trolling, not permitted.  Speaking your mind because you don’t like what we are doing is more than welcome.  It’s part of how we improve our product. 

Now to address your concerns. 

Daily builds are builds with the latest features and bug fixes.  Daily builds, by their nature are cutting edge and from time to time, bugs get introduced.  Some programmers don’t use daily’s at all because they want to release on the stable code base.   It takes time to QA these things but in the quest to get you features and fixes faster, there is the risk that bugs can get introduced.  This looks like a regression bug.

Forums by their nature are great to help us solve bugs that are not bugs.  If you filed bug reports on everything that didn’t work, our bug tracker would be overwhelmed.  So the forums are kind of the first line of defense in sorting out if it’s a bug or not and what the severity and the impact of a bug is.  I would say that 95% of the things people report as bugs in the forums end up being bugs in their code.  Asking the engineers to filter though that much noise is problematic.

If we ask you to file a bug report, it’s not because we are being an pain in the behind, but you are the one experiencing it and you are the best one to communicate it.  You have code that can demo the problem and so on.  The work engineers do with regards to bugs is based mostly on what is in our bug tracking problem.  There are a couple of notable exceptions:

   Major issues like:  we can’t build.  B&N is rejecting evey app. 

   Major releases of new functionality, like Widgets 2.0.  The engineer was using the forums in the first couple of weeks because it was a good way to communicate with you.  But now that Widgets 2.0 is pretty solid, the engineers are now back to using things in the bug tracker.

When we ask you to file a bug report, it’s because we believe that it is a bug that we need to address, that we can’t get you a good workaround too and that we want the engineers to look at.  Stuff posted here isn’t tracked and its simply the wrong software for this most of the time.

#18

Rob,

Thanks for your tolerance and careful response!

Generally your comment is correct and in general I would agree, if, and only if, the problem was unique to an individual.

Here it is not unique.

Here the case is different and demonstrates to us (me) that no real regression testing is done. These problems are showing up on simple examples that you guys put together as code for your paying and non-paying users  to help them understand the widgets.

The example of this particular problem is posted here, stated as being your code, and it would be encouraging to me to see that someone in your team being proactive and pick these simple and easily copy pasted code (from your examples which you must have around as well) and went fixed it.

So that’s my point I sit here with a paid up subscription (getting really annoyed that it is being raised so high for a product that is not ‘finished’, is in a state of daily flux and is not properly unit tested).

Going to a daily build is a ‘risk’ , we know, but when things on a public announced release don’t work, or you announce a new and improved ‘thingy’ change not in the public release,  your team advise us ‘it is fixed in the daily build’.  We are told to use the daily build to verify and check the good work you are doing on widgets. Then if we  find simple ‘examples’ have regressed rather than a problem is fixed,  it is not what I would expect from a quality product with good routine (in house!!)regression testing.

Also I would expect a ‘war room’ team verifying and approving any changes  to the daily build (or at least the public release and change announces) since this is a critical window on your product. I am not confident any of this is happening.

So to re-state.

It is your code, your examples, your development so why do you think we should do all the work to create test cases against your examples. Come-on I was not born yesterday and  a quality team would not have shipped this, even in a daily build.

I mentioned Candy-Widgets third party product earlier , a stable, easy to use and ‘cheap’ . I am considering switching to their widgets until your widgets are ‘stable’ and re-look at Xcode longer term.

I am spending too much time trying to decide if a widget  problem is either,  a bug  in my code, or yours, a need for re-training  or re-testing  after each news letter and build update of ‘improvements’ to widgets. Widgets that have been changing for three years or more. So using a stable high quality third party product seems the safer interim until I go Xcode.

Alec

#19

Hi @cockle,

Your points are logical, and so are Rob’s… they remain as the official policy for the reasons he explains. In this particular case with newSwitch(), it is a regression bug, and because of that I will discuss it with engineering this week. It should be fixed in an upcoming daily.

Best regards,

Brent