Hyperion Entertainment Message Boards

I'm working on an old OS3 program that's ported to OS4 and uses Intuition DisplayAlert(). When testing the compiled program, I get a Grim Reaper instead of an alert. The example code in the WIKI DisplayAlert() documentation also brings up a Grim Reaper instead of an Intuition alert. Has the DisplayAlert() command been rerouted to a Grim Reaper or is there a bug in the DisplayAlert() command?

I plan to eventually replace the DisplayAlert() function calls with requesters but I spent a lot of time trying to debug the program when I got unexpected Grim Reapers. Eventually I suspected that the Grim Reapers might be due to a change in OS4 and not a bug in the program. Compiling & running the DisplayAlert() example in the WIKI convinced me that it's either an undocumented change in OS4 or an OS4 bug.

If this was an intentional change in DisplayAlert(), can someone please update the WIKI documentation so others don't waste time like I did? If it's a bug, could someone else confirm it and add it to the bugzilla?

From the Releasenotes of intuition...

intuition.library 53.51 (11.6.2014)
- TimedDisplayAlert() and DisplayAlert() now output only via DebugPrintF() and then call IExec->Alert().

Can you provide your code (that crashes) and a serial log showing the crash stack trace? You could send it to me if you don't want to make it public.

tonyw wrote:Can you provide your code (that crashes) and a serial log showing the crash stack trace? You could send it to me if you don't want to make it public.

It's not really a crash. It's a recoverable alert posted by old code. Colin Wenzel already comfirmed that DisplayAlert() has been rerouted to serial output and IExec->Alert(). If you really want to see what's happening, just compile the example code on the "Intuition Alerts" page of the AmigOS Documentation WIKI.

Most of the "Intuition Alerts" page needs to be replaced with a short explanation of the changes that were made. I need to replace most of the DisplayAlert() function calls in the code I'm working on, so this post is just about outdated documentation and the need to fix it.

xenic wrote:I'm working on an old OS3 program that's ported to OS4 and uses Intuition DisplayAlert(). When testing the compiled program, I get a Grim Reaper instead of an alert.

Yes, IExec->Alert() now alerts via a GrimReaper with the alert number in the first window.

The reason being that old style Alerts kill multitasking and render most OS4 machines unusable.

It's not a bug.

And it still does exactly what's asked of it, insofar as it alerts you to a problem, just via a GR window (which you can continue from) rather than a system disabling retro trick.... you even get a stack trace, so you can tell which point your program dis something nasty.

You should not use them in new code IMHO or even porting old code, unless there is no way out.

broadblues wrote:You should not use them in new code IMHO or even porting old code, unless there is no way out.

As I said in my original post I plan on replacing them. However, I'm in the process of fixing other stuff first and my first impression when I got a Grim Reaper was that DisplayAlert() was crashing. I wasted time trying to diagnose the problem because the OS4 AutoDocs and OS4 Documentation WIKI contain outdated information. Now that I know it's not a bug and that DisplayAlert() is being rerouted to a Grim Reaper, I'm requesting that the AutoDocs and Documentation WIKI be updated to reflect the change and possibly declare DisplayAlert() obsolete. A single sentence at the top of the documentation would eliminate the kind of confusion I experienced.

xenic wrote:

broadblues wrote:You should not use them in new code IMHO or even porting old code, unless there is no way out.

As I said in my original post I plan on replacing them. However, I'm in the process of fixing other stuff first and my first impression when I got a Grim Reaper was that DisplayAlert() was crashing. I wasted time trying to diagnose the problem because the OS4 AutoDocs and OS4 Documentation WIKI contain outdated information. Now that I know it's not a bug and that DisplayAlert() is being rerouted to a Grim Reaper, I'm requesting that the AutoDocs and Documentation WIKI be updated to reflect the change and possibly declare DisplayAlert() obsolete. A single sentence at the top of the documentation would eliminate the kind of confusion I experienced.

I used also some time before forum search told me this to be a new feature. I also hope that in the future the Autodocs show this change.

Marko

P.S: BTW, I should replace my "Out of memory" and "Window won't open" Alerts with some other way of communicating. Which would be the recommended route when an error requester may not be available?

blmara wrote:Which would be the recommended route when an error requester may not be available?

An error requester

I may be wrong, but logic tells me that a GR would need the same or more memory to open than a simple requester. So if you are that low on memory, you won't be able to open anything anyway. I'm not sure if the system falls back to the old displayalert in that case - even though most users on't be able to interact with it after that?

Best regards,

Niels

nbache wrote:

blmara wrote:Which would be the recommended route when an error requester may not be available?

An error requester

I may be wrong, but logic tells me that a GR would need the same or more memory to open than a simple requester. So if you are that low on memory, you won't be able to open anything anyway. I'm not sure if the system falls back to the old displayalert in that case - even though most users on't be able to interact with it after that?

That's why I replaced the DisplayAlert() function calls with serial debug output. The DisplayAlerts were only used for debugging anyway; they weren't active in a user version of the program.