mouse@thunder.mcrcim.mcgill.edu (der Mouse) (10/14/90)
Okay, I give up. Why does this program coredump? #import <appkit/appkit.h> void main(void) { NXBeep(); } The only even semi-plausible explanation that anyone around here has offered is that NXBeep() requires that it be called inside an Application Kit main loop (eg, [NXApp run]). However, that seems like a very strange requirement, and the manual doesn't even hint at it as far as I can tell. /NextLibrary/Documentation/NeXT/SysRefMan/23.CFunctions.wn is "the manual" I refer to here. Answers? Or even comments or hints? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
wiml@milton.u.washington.edu (William Lewis) (10/15/90)
In article <1990Oct14.053814.6719@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >Okay, I give up. Why does this program coredump? > > #import <appkit/appkit.h> > void main(void) { NXBeep(); } > >The only even semi-plausible explanation that anyone around here has >offered is that NXBeep() requires that it be called inside an >Application Kit main loop (eg, [NXApp run]). However, that seems like >a very strange requirement, and the manual doesn't even hint at it as >far as I can tell. OK, I haven't actually TRIED it, but I think that whoever it was was right. Beeping is handled by a special detached PostScript context that just sits in a loop, monitoring a lock, and beeping when appropriate. I think the reason for this is that "beeping" is (a) sometimes a complex behavior, as when you've defined a visual beep rather than the normal audio beep (b) sometimes a lengthy activity, again such as when you have a visual beep, and you want your PS context to be able to do other things instead of waiting around for the beep to finish. (b) is probably the better reason. Anyway, to do either of these things requires a window server connection, and in most applications, the Application object in NXApp takes care of creating and managing your window server connection. Certainly the minimal program you have doesn't create a WS connection. If you don't want an App. object running, look up DPSCreateContext() and friends in the manual. This probably isn't a terrible restriction, since your program either: 1. Is a GUI program, in which case it has a WS connection; 2. Is a non-gui program being run under a Shell or Terminal, in which case you can just output a \a or \007 and let your emulator do the beeping; 3. Is a daemon and shouldn't be beeping in the first place. DISCLAIMER: Who knows, I may be wrong. If it's incredibly important, ask someone who ought to know, like NeXT. I'm just an undergrad. -- wiml@milton.acs.washington.edu Seattle, Washington (William Lewis) | 47 41' 15" N 122 42' 58" W "These 2 cents will cost the net thousands upon thousands of dollars to send everywhere. Are you sure you want to do this?"