Hi,
Could you please include an option to disable those annoying popups with errors?
That’s what terminal is for, and this is just adding additional clicks/focus changes to the testing process.
Thanks,
K
PS
btw… since you have introduced this annoyance I keep experiencing crashes on application reload/refresh!
@krystian6, take a look at the following. You can find the error handling code that would disable the popups:
http://www.coronalabs.com/blog/2013/03/06/run-time-error-handling/
http://www.coronalabs.com/blog/2013/03/13/wednesday-faq-runtime-error-listener/
BTW, I’m assuming that this code would be placed in main.lua only, and I don’t need to add them locally in each individual lua modules. If I’m mistaken, I’d like to hear about it. (I need to download the daily build 1044 or later to get it to work, and I’m still using 1041. It’s probably time for me to download the latest…)
Naomi
Edit: We need build 1047 or later to enable unhandled error listener.
Hi @krystian6,
Thanks for the feedback. We’re aware that this has irritated some users and we’re looking into resolving it a.s.a.p. The intention is to alert developers to code errors if they’re not using or currently viewing the Terminal/console. However, I understand that every developer codes in their own unique way, and this popup is not a desired feature for all.
To all reading this, if you have any specific and constructive comments on how you “want this feature to work”, it will help us resolve it soon according to the needs of the overall Corona developer community. Please post your comments in this thread and I’ll keep track of them.
Thanks,
Brent Sorrentino
Hey, Brent, I’m definitely setting the unhandled error listener to true so that I don’t have to see the popup.
I would like it if we can simply set a flag to true or false at the top of main.lua to decide if we want to see the runtime error without console/terminal. Setting it to true would feel more intuitive if we want the feature activated, and false if we don’t want the feature activated.
And if we choose to activate the feature, developers could further refine it for their own use, including the function like the unhandled error listener.
Naomi
Both of these ideas sound reasonable at first thought. Expanding on this, if a user does want to use the error popups, do you have a preference on how they behave? For example, what is displayed in the popup itself? Options (buttons) below? Or perhaps something closer to a “Growl-like” notification that doesn’t need confirmation at all? Just curious on your thoughts…
Brent
@Brent Sorrentino I think there is already Corona simulator output and people use it when they are testing an app. If an error occurred and output window is minimized then you should bring it to front. The simulator should be as simple as possible and please remove that annoying error popup.
@Naomi solution involves people to change all projects.
Naomi’s solution wouldn’t neccessarily require changing all projects. If the default was false it would require nothing on the part of anyone or any project. However I see the problem in that Corona Labs may be doing this for people perhaps that are not aware of the terminal or are confused on how to see debug information. The terminal is one thing but it’s more involving when you want to do so on a device and need xcode or adb.
I understand boths sides (if my thoughts on Corona are even close to their reasoning). However I feel this should be an opt-in sort of functionality rather than an opt-out. Perhaps just setting debug=true in the projects config file or something. If not present it defaults to false and everything is as it was before adding the pop-ups.
@Brent, I think your question would need to be answered by the developers who would want to use this option. Since I’ve been happy with the way I debug my code using console/terminal with print statements, I haven’t really spent time thinking about how it can be improved. That said, terminating the app after any and all runtime errors caught by the popup is a bit too much.
I had a case where I show Facebook friends on my app, with each of the friends profile pix displayed using display.loadRemoteImage function. Well, some of the friends’ profile pix may not always get displayed quickly. In fact, occasionally, event.target makes it to the app much much later even though I’ve already moved on to another scene. When that happens, I have a flag (global variable) that tells event.target to be removed and nil’ed instead of being inserted to display.newImageRect (and hopefully this does clear out the event.target from memory and no lingering items from already closed scene to remain.) However, with this runtime error popup thing, my app seemed as if it got terminated out of blue for a reason totally unrelated to what was happening with the app at the time. In a case like this, I’d rather have the app go on without terminating. I haven’t seen this latency issue to cause any problem with my app until this popup was activated.
@vovasoft and @Anderoth, I like the simple solutions you are suggesting.
Naomi
Simple checkbox in preferences to enable/disable this feature would be great.
+1
+1
I disagree on the checkbox. That would be a global setting and I feel this needs to be on case by case basis per project. Some projects I would like this on, while others no.
I would prefer it in the config.lua file or near the top of your main.lua file over a global checkbox as well, but it definitely needs to be toggle-able.
At the moment there are two types of error popups:
There should be two options in **File -> Preferences ->
@voasoft
Why do we need a checkbox AND code? I can see you really want checkboxes badly.
However again, I disagree. Nothing about how my code works is currently in “Preferences” and I prefer it not to be going forward. Keep in it in the code were all options currently are. Do not mix and match how we do things.
@Anderoth checkboxes are very simple.
Nothing about how my code works is currently in “Preferences”
Yes but I’m talking about popups in simulator. Why should I change code in my projects to configure the simulator popups ?
And I agree with @BeyondtheTech that popups on devices should be “toggle-able” in config.lua.
Agreed. If you want a check-box to allow/disallow them in simulator and the config controls the device. Fine by me.
The biggest point of my first post is this should all be opt-in. If it’s opt-in, then no worries, everything goes back to the way it was unless you want to see them.
Although I disagree with @BeyondtheTech [why would anyone want to mix external tool setting in the code??], I can’t see why wouldn’t you just include the checkbox in the preferences + add possibility to control simulator from within the code. It’s not like it’s going to dramatically change your testing process 
.
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.