That sounds great, Perry! Thank you for the detailed explanation.
Naomi
That should suffice to meet all styles of workflow.
I still think it’s a little bit dangerous to have two places to configure the same thing. And I think, a setting which only controls the behaviour on the simulator while the behaviour on the device is handled somewhere else will lead to mistakes.
I also think, event handlers for runtime errors are generally a very good thing, I’d like to use them. The popups wouldn’t hurt me at all if the handler was working as expected. But at least from my experience there are still issues (version 1057).
For example the code from:
http://www.coronalabs.com/blog/2013/03/06/run-time-error-handling/
does not disable the popups in the simulator. It does disable them on the device. This happens always. On my own projects, the handler sometimes suppress the popups and sometimes doesn’t. I always return true from it and it’s registered long before the error happens. I wasn’t able to pin it down reliably, perhaps others are experiencing similar problems?
I’d really like to help with that, because it’s already been taking quite a lot of my time experimenting with the new feature…
Another thing that is worth considering: perhaps there’s a way to not let the popups steal the window focus as they pop up and to not prevent the simulator from reloading automatically. This way one doesn’t need to actually click them and just correct the error in the editor, save and auto-rerun as it was before. This way we still would be pushed onto seeing errors which might have been overseen while nobody has to change workflow habits => no need for other configuration options
Try the latest daily build since we tweaked several things (not the window focus though, I’ll take a look at that).
Perry
hi,
as far as I understood (please correct me), the popups on the device get suppressed by the error handler whereas the popups in the simulator don’t get suppressed at all. (Version 2013.1056)
For the sake of consistency, they should be suppressed on both the device and the simulator. It’s always good to have the simulator as near as possible to the device.
No need for a checkbox, it would be a source of errors resulting from simulator ~= device. But I wouldn’t mind.
But I really mind screen locking popups which prevent the simulator from reloading.
i dont see the Simulator preferences Show Runtime Errors, you mentioned.
im using build 1074. and no matter what i try i can not disable the popups in the simulator.
Can you post a screenshot of your Preferences screen?
This is mine … you can see the Show Runtime Errors option near the bottom.
Thanks i just reinstalled the build and it matches your screen shot.
We’ve been listening to your feedback and hope we’ve come up with a scheme that works well for both newcomers to Corona and for the old hands who know what they’re doing. It allows control at both the Simulator and application levels.
There is now a setting in the Simulator preferences called Show Runtime Errors which defaults to on and which causes runtime errors to always pop up when the application is run in the Simulator. If you don’t like this or it doesn’t fit with your workflow you can turn it off. It’s global for all applications.
We also added a setting to config.lua that can be used to control the display of errors in applications running on the device. It’s called showRuntimeErrors and takes a boolean value ( true or false ). It defaults to off (false)_. _If you explicitly set showRuntimeErrors to false in your config.lua that will override the preference in the Simulator for that application (to turn it off, just comment it out rather than setting it). Remember that turning off the display of errors doesn’t mean they aren’t happening and changing the way your app works, almost certainly in bad ways. We want you to know about errors because they are causing your users’ mileage to vary and diminishing their enjoyment of your apps.
Note that even if you turn off the display of runtime errors, the unhandledError listener still gets called but it doesn’t matter what you return from it, the popup error is never displayed. This allows you to implement your own error reporting if you want to. Having an unhandledError listener is completely optional.
In writing this I’ve realized that I’ve neglected the documentation for this so I better get to that. Let me know what you think of the new scheme.
That sounds great, Perry! Thank you for the detailed explanation.
Naomi
That should suffice to meet all styles of workflow.
I still think it’s a little bit dangerous to have two places to configure the same thing. And I think, a setting which only controls the behaviour on the simulator while the behaviour on the device is handled somewhere else will lead to mistakes.
I also think, event handlers for runtime errors are generally a very good thing, I’d like to use them. The popups wouldn’t hurt me at all if the handler was working as expected. But at least from my experience there are still issues (version 1057).
For example the code from:
http://www.coronalabs.com/blog/2013/03/06/run-time-error-handling/
does not disable the popups in the simulator. It does disable them on the device. This happens always. On my own projects, the handler sometimes suppress the popups and sometimes doesn’t. I always return true from it and it’s registered long before the error happens. I wasn’t able to pin it down reliably, perhaps others are experiencing similar problems?
I’d really like to help with that, because it’s already been taking quite a lot of my time experimenting with the new feature…
Another thing that is worth considering: perhaps there’s a way to not let the popups steal the window focus as they pop up and to not prevent the simulator from reloading automatically. This way one doesn’t need to actually click them and just correct the error in the editor, save and auto-rerun as it was before. This way we still would be pushed onto seeing errors which might have been overseen while nobody has to change workflow habits => no need for other configuration options
Try the latest daily build since we tweaked several things (not the window focus though, I’ll take a look at that).
Perry
I wish I’d seen this thread earlier – I installed 1076 the day after it came out (I generally *only* work with the release builds) and am SO FREAKING FRUSTRATED with this.
The change in the simulator is the one I’m talking about. The check box option is STUPID because you don’t give me the functionality I had before. In the old release when an error in my code would happen I’d get the Growl notification that would pop up to alert me and then it would go away.
Now the Preferences option only gives me Growl + STINKING blocking pop-up, or NOTHING.
I sit and wait at the first black screen because maybe it’s just slow getting started? Then finally I realize something “bad” must have happened and open my terminal pane to see an error waiting for me.
Why was this change made? Who complained about the Growl pop-up? Is this really something that needed to be "fixed?"
I am so pissed right now.
Jay
Jay,
I haven’t really thought about such scenario. Here we always have both simulator and terminal opened side by side or on separate displays.
I have never used growl with corona [since I can see everything in terminal].
I possibly was a little more “passionate” about the problem than I should have been, but I’d just run into another (major) problem with the new build and the one built on the other.
I love seeing new features, but sometimes it seems like a feature was decided on by someone who doesn’t actually use the product for development.
“I love Corona SDK, I just wish there was a blocking pop-up that would show up when there’s an error in my code.”
Who said that? Correct answer: Nobody.
Jay
PS - I understand I’m being a little harsh. But the $600 price will (eventually) only affect me once a year – this issue will affect me every time I code a bug. (Hint - that’s a lot.) 
i dont see the Simulator preferences Show Runtime Errors, you mentioned.
im using build 1074. and no matter what i try i can not disable the popups in the simulator.
Can you post a screenshot of your Preferences screen?
This is mine … you can see the Show Runtime Errors option near the bottom.
Thanks i just reinstalled the build and it matches your screen shot.
I wish I’d seen this thread earlier – I installed 1076 the day after it came out (I generally *only* work with the release builds) and am SO FREAKING FRUSTRATED with this.
The change in the simulator is the one I’m talking about. The check box option is STUPID because you don’t give me the functionality I had before. In the old release when an error in my code would happen I’d get the Growl notification that would pop up to alert me and then it would go away.
Now the Preferences option only gives me Growl + STINKING blocking pop-up, or NOTHING.
I sit and wait at the first black screen because maybe it’s just slow getting started? Then finally I realize something “bad” must have happened and open my terminal pane to see an error waiting for me.
Why was this change made? Who complained about the Growl pop-up? Is this really something that needed to be "fixed?"
I am so pissed right now.
Jay
Jay,
I haven’t really thought about such scenario. Here we always have both simulator and terminal opened side by side or on separate displays.
I have never used growl with corona [since I can see everything in terminal].