hsgj@batcomputer.UUCP (02/05/87)
[] Is there any way to turn off the system requester that is displayed when one attempts to access a 'disk' that is not mounted? I have a helpfile displayer. By default, the help files it should display are located in the current directory. However, I thought it would be 'user friendly' if the user could ASSIGN HELP: my/help/dir so that he/she could locate the help files anywhere. Unfortunately, when I test to see if HELP: has been defined, if it *hasn't* been defined, an 'Insert HELP disk' system requester appears. This is not good... The real question, I guess, is whether it is possible to check for an ASSIGNed name without attempting to access the file system via that name. Any replies on this will be appreciated. The enclosed fragment should make this dilemma clear. --------------------------- start code fragment ---------------------- #define HELPDIR "HELP:" openfile(filename) char *filename; { long templock; char helpfile[64]; /* create helpfile name */ if ((templock = Lock(HELPDIR,ACCESS_READ)) == 0) strcpy(helpfile,filename); else { UnLock(templock); strcpy(helpfile,HELPDIR); strcat(helpfile,filename); } /* open and display helpfile */ /* [...] */ } --------------------------- end code fragment ---------------------- -- Dan Green -- ARPA: hsgj%vax2.ccs.cornell.edu@cu-arpa.cs.cornell.edu UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella
higgin@cbmvax.UUCP (02/06/87)
In article <108@batcomputer.tn.cornell.edu> hsgj@batcomputer.tn.cornell.edu (Dan Green) writes: $[] $ Is there any way to turn off the system requester that is $displayed when one attempts to access a 'disk' that is not mounted? Yes - set the pr_WindowPtr in the Process structure associated with the program to -1 (I think that's the value). Then AmigaDOS doesn't know where to stick requesters and so just returns error codes (probably via IoErr()). E.g: ToggleRequesters(Flag) int Flag; { extern struct Task *FindTask(); static APTR WindowPtr; struct Process *Me; Me = (struct Process *)FindTask(NULL); if (Flag) { Me->pr_WindowPtr = WindowPtr; } else { WindowPtr = Me->pr_WindowPtr; Me->pr_WindowPtr = -1; } } Note: if you call the function with 1 first you will get in trouble. $-- Dan Green $ $-- $ARPA: hsgj%vax2.ccs.cornell.edu@cu-arpa.cs.cornell.edu $UUCP: ihnp4!cornell!batcomputer!hsgj BITNET: hsgj@cornella Paul Higginbottom Disclaimer: I work for Commodore, but my opinions and certainly the above hack are mine only.
dillon@CORY.BERKELEY.EDU.UUCP (02/06/87)
>[] > Is there any way to turn off the system requester that is >displayed when one attempts to access a 'disk' that is not mounted? >I have a helpfile displayer. By default, the help files it should >display are located in the current directory. However, I thought it >would be 'user friendly' if the user could ASSIGN HELP: my/help/dir >so that he/she could locate the help files anywhere. Unfortunately, >when I test to see if HELP: has been defined, if it *hasn't* been >defined, an 'Insert HELP disk' system requester appears. This >is not good... Very easily. Simply set the pr_WindowPtr in your Process structure to (APTR)-1. This causes DOS to return an error code to you rather than put up a requester. Be sure to restore the pr_WindowPtr to it's original state before exiting. (If you have MY.LIB, this would corrospond to the mountrequest(bool) call.). Here is a code fragment: -------------------------- extern struct Process *FindTask(); struct Process *proc; APTR save_window_ptr; proc = FindTask(0L); save_window_ptr = proc->pr_WindowPtr; proc->pr_WindowPtr = -1; ( do stuff here ) proc->pr_WindowPtr = save_window_ptr; -------------------------- Note: By this method, if HELP: were assigned to a disk which is not currently mounted, it would be the same as if HELP: were not assigned at all. -Matt
aaron@uwmacc.UUCP (02/08/87)
In article <1358@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom SALES) writes:
) Me = (struct Process *)FindTask(NULL);
) if (Flag)
) {
) Me->pr_WindowPtr = WindowPtr;
) }
) else
) {
) WindowPtr = Me->pr_WindowPtr;
) Me->pr_WindowPtr = -1;
) }
)
) Paul Higginbottom
)
It seems to me that there should be a Forbid()..Permit() around those
references to the process structure, or at least writes to it. As this same
case came up in Matt Dillons code fragment doing the same thing, could
someone please respond, letting me know if I'm even close to right in
suggesting this.
Aaron Avery ({seismo,harvard,caip,topaz,allegra,ihnp4}!uwvax!uwmacc!aaron)
(aaron%maccunix@rsch.wisc.edu)
(aaron@unix.macc.wisc.edu)
higgin@cbmvax.UUCP (02/09/87)
In article <1035@uwmacc.UUCP> aaron@unix.macc.wisc.edu.UUCP (Aaron Avery) writes: $In article <1358@cbmvax.cbmvax.cbm.UUCP> higgin@cbmvax.UUCP (Paul Higginbottom SALES) writes: $) ...My code to disable requesters... $ It seems to me that there should be a Forbid()..Permit() around those $references to the process structure, or at least writes to it. As this same $case came up in Matt Dillons code fragment doing the same thing, could $someone please respond, letting me know if I'm even close to right in $suggesting this. $ $Aaron Avery ({seismo,harvard,caip,topaz,allegra,ihnp4}!uwvax!uwmacc!aaron) $ (aaron%maccunix@rsch.wisc.edu) $ (aaron@unix.macc.wisc.edu) The only reason I can think of for doing Forbid/Permit around it is if the program has done something prior to this code which could cause a requester (opening a file on a disk no longer in a drive, for example). People shouldn't get Forbid/Permit paranoid because each time a program does this it's effectively "stopping the world", doing whatever it feels like, and then allowing the world to start again. Hardly in the spirit of multi-tasking! Paul. Disclaimer: I work for Commodore, but opinions expressed are mine only.