Still Seems to be broken for widget.newButton… Corona?
Can you put together a small sample project that demonstrates the bug and file a bug report with the “Report a Bug” link above please?
Thanks
Link referenced earlier has a post by J.Whye where he says he submitted a report on 7 Jan. Is a new bug report still needed? Thanks.
I’m using 1094 and the bug for which I submitted the report is still there.
You can work around it fairly easily but putting a rect behind everything in the overlay and using that to catch all taps and touches, but it’s an annoying bug, nevertheless.
Jay
You know, might be cool if Corona Labs offered a 1-month extension of your subscription for every bug report you submitted, complete with sample code. If it’s the first report of that bug, of course.
Would give people some incentive to put together the samples you guys want. 
Jay
That is an excellent idea!!!
If only one person reports a bug that’s easily worked around, should we stop and fix this or should we fix other more important bugs and add more important features?
Rob,
I have a feeling you’re annoyed. Not sure why.
First off, more than one person seems to be affected by this issue. I counted 6 just in this thread. Secondly they have waited patiently so far only asking for occasional updates. Where in this thread did you get the idea that folks would like CL to drop all else and fix this particular bug? Jay even shared his simple workaround and indicated this bug is only annoying but not a high priority fix. Why the overreaction?
Just please don’t ask for a new bug report which will start the clock all over again from 0. Let this bug, as reported on Jan 7 age along with all others waiting for their day under the sun! We trust CL to make the best judgement as to when and how this bug should be fixed.
Have a great weekend. Rest and relax. All the best.
Kerem
I’m not annoyed in the least. I’m just trying to say that we have to rank our work and the more reports a bug has the more traction it can get. Remember the subject is “still broken”. The op wanted to know why. I’m just pointing out that there is no magic system for counting forum reports. There is a magic system using report a bug.
Ahh this is a revelation for me. I didn’t know that you need more bug reports for the same issue, like the voting system implemented for features, to see the impact of the bug.
This is very tedious and counter-productive though. After all, who wants to spend time making new sample apps showing the already reported bug to file yet another bug report? It would be great if the bug reporting system allowed a “Me too” report of some sort.
Anyways, like I said, we trust you guys to make the right judgment. Have a good weekend.
Kerem
If only one person reports a bug that’s easily worked around, should we stop and fix this or should we fix other more important bugs and add more important features?
Q. Stop and fix this? No, but put it in the queue with other bugs.
Q. Fix more important bugs than this one? Yes, by all means.
Q. Add more important features instead of fixing this? No. This fix should go in before new features.
(Hey, you asked!)
I’m all for new features, but this bug in particular bites a LOT of people. I’ve seen multiple people complain about it here and you can even find it on sites like StackOverflow. If you use isModal in storyboard overlay, it will probably affect you.
And while the workaround is easy, you can spend a lot of time trying to figure out “where you went wrong” before discovering it’s a problem with the SDK.
You guys have a list of bugs none of us know about. And there may even be “data munching” bugs that obviously have to be higher on the priority list.
But asking people to submit duplicate bugs, complete with sample code, is a waste of our time. It really seems like a non-optimal system.
Voting on possible features, yeah. On bugs? Not so much. 
Jay
It is dismaying to learn the effort required to put together a “simple, reproducible test case” for a bug, usually easier said than done, is really just an elaborate voting scheme. There is not much transparency into your bug base for your customers to learn what the reported issues are, or how many people have reported the same thing. You are asking your customers to do a lot of the leg work on these issues, but in return we are given very little information on their priority.
Most of us are using Corona to ship actual products that we will have to support, so while we will jump through any necessary hoops to get these things fixed we would prefer not to have to do it blindfolded.
I have to agree with J.A. Whye. This bug cost me 2 hours of time already. Bugs should take a higher priority then features. I know that can be harmful to your business model to some extent, but frustrated users can be harmful as well. I know that many others are patiently waiting or a feature to complete their game would disagree! We are all on the same business and know how the priority game works.
Mike
I too am running into this issue. I think that fixing it should be high priority, as it can cause all manner of unpredictable behavior in your app. There’s a reason why I’m using isModal, and my code relies on it working as advertised.
Hi guys,
I found the original bug Jay posted in January. I’ll be looking at this and update the thread.
Thanks,
Alex
I too am running into this issue. I think that fixing it should be high priority, as it can cause all manner of unpredictable behavior in your app. There’s a reason why I’m using isModal, and my code relies on it working as advertised.
Hi guys,
I found the original bug Jay posted in January. I’ll be looking at this and update the thread.
Thanks,
Alex
I wanted to add another ‘Me too’ to this issue, and also ask for further help on the workaround. The overlay I’m using is a simple tutorial popup with text and an ‘OK’ button. The button is a widget.newButton. The function that is called onRelease for the button is returning true. I’ve also tried the rectangle behind the whole overlay to try to catch taps and touches, but that’s not working either. Here’s the relevant code from the overlay :
-- forward declarations and other locals local okBtn -- 'onRelease' event listener for okBtn local function onOkBtnRelease() storyboard.hideOverlay() return true -- indicates successful touch end function scene:createScene( event ) local group = self.view -- overlay fix; to prevent taps from going thru to underlying screen local oFix = display.newRect( group, 0, 0, screenWidth, screenHeight ) oFix:setFillColor(0,0,0) oFix.alpha = .7 oFix:addEventListener( "tap", catchStrays ) oFix:addEventListener( "touch", catchStrays ) local myRoundedRect = display.newRoundedRect(10, 10, 250, 250, 12) myRoundedRect.strokeWidth = 3 myRoundedRect:setStrokeColor(180, 180, 180) group:insert(myRoundedRect) local wrappedText = display.newText( event.params.msg, 25, 25, 200, 200, native.systemFont, 18 ) wrappedText:setTextColor(0,0,0) group:insert( wrappedText ) -- create a widget button okBtn = widget.newButton{ label="OK", labelColor = { default={255}, over={128} }, defaultFile="button.png", overFile="button-over.png", width=154, height=40, onRelease = onOkBtnRelease -- event listener function } okBtn:setReferencePoint( display.TopLeftReferencePoint ) okBtn.x = 50 okBtn.y = 200 group:insert(okBtn) end