Page 2 of 2

Re: Exec Bug Report

Posted: Tue Apr 30, 2019 12:53 pm
by Hypex
thomasrapp wrote:Interesting suggestion because the documentation says that if the requester fails to open, it will revert to an alert. Now we have an infinite loop, don't we.
Revert to an alert. LOL. :-)
I wouldn't say something about IExec-Alert, because it is meant to show an error code. Displaying this in a GrimReaper is ok.
Though it could be suitably displayed in a system requester the Grim does show an alert code. Might not be as obvious as if you have to dig for info and go deeper than the first window.
But the GR also opens for IIntuition->DisplayAlert and IIntuition->TimedDisplayAlert. I surely consider this a bug. These functions are meant to give some information to the user if everything else fails. But if a GR opens instead, the information is lost.
That's what I found. This would have been the function I used. The input string now rendered useless.

Re: Exec Bug Report

Posted: Tue Apr 30, 2019 5:49 pm
by broadblues
@thomas
Besides that these functions are meant as a last resort if the system is almost dead. In such situation the GR cannot run any more, too.
The "Grim Reaper" may not open but the "Reaper" will most likely still catch the alert and send the initial debug otput to serial (or debug buffer). If the Reaper can't start then the system is really messed up and the alert likely wouldn't show anyway.

Re: Exec Bug Report

Posted: Tue Apr 30, 2019 5:52 pm
by broadblues
@Hypex
Though it could be suitably displayed in a system requester the Grim does show an alert code. Might not be as obvious as if you have to dig for info and go deeper than the first window.
You can also get a stack trace from the GR which you couldn't from the plain old yellow alert, so you are better off, especially if the alrt was thrown up by the system, rather than directly from your own program.

Re: Exec Bug Report

Posted: Thu May 02, 2019 7:00 am
by trixie
@Thomas Rapp
thomasrapp wrote: Interesting suggestion
No, the suggestion actually made good sense. It was my understanding that Hypex used a system alert function to display some error-kind information to the user, for which a requester is indeed a preferred choice. I hadn't known what his program was in fact up to because he only revealed that later.

Re: Exec Bug Report

Posted: Sat May 04, 2019 12:55 pm
by Hypex
broadblues wrote:You can also get a stack trace from the GR which you couldn't from the plain old yellow alert, so you are better off, especially if the alrt was thrown up by the system, rather than directly from your own program.
You can. But in the case of a recovery alert the system should still be working fine and such things as a stack are trace are beyond the scope of a casual user. It does make sense to use a system requester for a yellow alert.

Re: Exec Bug Report

Posted: Sun May 05, 2019 10:57 am
by broadblues
You can. But in the case of a recovery alert the system should still be working fine and such things as a stack are trace are beyond the scope of a casual user. It does make sense to use a system requester for a yellow alert.
The casual user should never be presented with an alert, I would receomend never using them in new software. there is absolutly no advantage to be gained and everything to be lost. Alerts might be low resource option on classic hardware but that is hardly the case on OS4 given that a window must be opened on an RTG screen.

The program can be continued with Continue program.

Most common cause of a GR fron a receverable alert is a 0100000C (corrupt memory list) you'll need to reoot soon after one of those anyway.

Re: Exec Bug Report

Posted: Wed May 08, 2019 11:52 am
by Hypex
broadblues wrote:The casual user should never be presented with an alert, I would receomend never using them in new software
But Andy, the yellow and red alerts are a classic of the Amiga generation. Just isn't the same without the red guru meditating. ;-)
Most common cause of a GR fron a receverable alert is a 0100000C (corrupt memory list)
That and freemem twice. There may be others. But they tend to be few and far in between.