oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/10/89)
I was reading some source code that comes with the THINK C compiler (Also
known as LightSpeed C version 3) and I came across the following in a main
event loop:
switch (event->what) {
case diskEvt:
if(noErr != HiWord(event->message)){
InitCursor();
DIBadMount(0x00640064, event->message);
}
break;
followed by more stuff, of course. A quick check of Inside Mac Vol. 2,
the Disk Initialization package, says, yes:
Application programs should watch for disk inserted events in their main
event loops. If the high word of the message of the event is an error,
then pass it to DIBadMount() so it can put up a dialog asking the user
what he wants to do about the bad floppy.
My question:
Is this still recommended?
Apple, what do you say?
--- David Phillip Oster --"When we replace the mouse with a pen,
Arpa: oster@dewey.soe.berkeley.edu --3 button mouse fans will need saxophone
Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu --lessons." - Gaseebillkatt@sol.engin.umich.edu (Steve Bollinger) (01/11/89)
In article <27435@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >I was reading some source code that comes with the THINK C compiler (Also >known as LightSpeed C version 3) and I came across the following in a main >event loop: > [some code deleted] >followed by more stuff, of course. A quick check of Inside Mac Vol. 2, >the Disk Initialization package, says, yes: > >Application programs should watch for disk inserted events in their main >event loops. If the high word of the message of the event is an error, >then pass it to DIBadMount() so it can put up a dialog asking the user >what he wants to do about the bad floppy. > >My question: > >Is this still recommended? It never was recommended. If you read a little farther (bottom of page 395, and top of 396 it says Note: Disk-inserted events during standard file saving and opening are handled by the Standard File Package. You'll call DIBadMount only in other, less common situations (for example, if you program explicitly ejects disks, or if you want to respond to the user's inserting an uninitialized disk when not expected). When your Application received the DiskEvt, the system has aldready tried to mount the volume. If it was successful, great, if not, it will sit in the drive until the SFGet(or Put)File comes up. This is fine because most file operations take place in the SFGet(/Put)File. As a side note, I think that this works a little differently under MultiFinder. +----------------------+----------------------------------------------------+ | Steve Bollinger | Internet: billkatt@caen.engin.umich.edu | | 4297 Sulgrave Dr. +------+---------------------------------------------+ | Swartz Creek, Mi. 48473 | "My employer doesn't take my opinion any | +-----------------------------+ more seriously than you do." | | "You remember the IIe, it +---------------------------------------------+ | was the machine Apple made before they decided people didn't need | | machines with big screens, color, or slots." | | - Harry Anderson (from NBC's Night Court) | +---------------------------------------------------------------------------+
lsr@Apple.COM (Larry Rosenstein) (01/19/89)
In article <40cd6a85.a590@mag.engin.umich.edu> billkatt@caen.engin.umich.edu (Steve Bollinger) writes: >It never was recommended. If you read a little farther (bottom of page 395, >and top of 396 it says > >When your Application received the DiskEvt, the system has aldready tried to >mount the volume. If it was successful, great, if not, it will sit in the >drive until the SFGet(or Put)File comes up. This is fine because most file I have to disagree with this. What good is it to have the diskette sit in the drive, where the only way to get it out is to type Cmd-Shift-1? It also doesn't make sense to make the user wait for Std File before s/he can format the disk. I think applications should call DIBadMount, so that the user has a chance to eject the disk or format it. (BTW, MacApp calls DIBadMount in this case.) -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr