Conference hydra::amiga_v1

    I'd like to see it....
    

    OK.  Here it is.  Brace yourselves:
    
    	struct Process *proc;
    	struct Task *FindTask();
    
    		.
    		.
    		.
    
    	proc = (struct Process *)FindTask(0L); /* Get Pointer to CLI */
    	proc->pr_WindowPtr = (APTR)-1L;        /* Suppress Requesters */
    
    Or, if you want to requesters to appear on a new screen, you can
    open a window on that screen, called window, and try the following:
    
    	proc->pr_WindowPtr = (APTR)window;    /* Assign new window */
    
    
    
    I was thinking about modifying the code to make a program called
    Requester.  Requester Off suppresses requesters, and Requester On
    turns them back on.  However, in order to do this, I'd have to save
    the value of the current window pointer somewhere.  Any suggestions
    on the best way to do this?  Resident, maybe?  I want to try to
    avoid actually having the program running in the background with
    a window.
    
     - Chris
    
    

How about as an Environment Variable (ala WB1.3).

You could then save it as an ASCII Hex string.

John

    re .3
    	That might work.  I had also thought of making a program that
    spawned another task that held the variable, and went to sleep until
    it was called again.  That way, the program could check for the
    task before doing anything.  Any other suggestions?
    
     - Chris
    

    re .4
        You could also hack this feature into your favorite window-clock
    program and attach a menu structure to it (A la rslclock)
    
    Robb

Re: .2

First, a "problem".  The system requester window is a part of the process
context.  Each process, whether started from the CLI or Workbench, has its
own pr_WindowPtr.  So your code fragment properly turns off requesters for
its own process, but not for any other.

Thus, using the above code fragment will work if you envision a CLI command
that turns of requesters for the CLI that executes it: in other words, you
want to use a CLI on a terminal connected via AUX:, and the user types
the Requester command before doing anything that might cause a system
requester.  But note that the user can not give a command like:

	run requester

because the run command starts a separate CLI process to run the command in.
Thus, the requester program would turn off System Requesters for the non-
interactive CLI it is running in (not very useful since that CLI then
kills itself as soon as the requester program exits).

Also, the pr_WindowPtr can have three values:

	-1	Do not display system requesters
	0	Display system requesters in the Workbench Screen
	ptr	A pointer to a window in a Custom screen to be used to
		display system requesters.

By default, processes are created with a pr_WindowPtr equal to 0.

Since your requester program is only useful for CLIs, and unless you
are doing something tricky all CLI windows are open on the Workbench
Screen, why not just have your program either set pr_WindowPtr to
-1 or 0?

By the way, all of this is documented in "The AmigaDOS Manual" by
Bantam in the chapter on system data structures.

    Re .6
    Randy is right.  I tried using the thing with my AUX: device last
    night, and found that it did indeed still bring up the requesters.
    I solved the problem by typing:  NEWCLI AUX: FROM VD0:Stomp where
    VD0:Stomp was a script file that ran the requester program.  It
    is possible to turn off selected process if you have their names.
    You can just use FindTask to find them too.
    
     - Chris
    

>    VD0:Stomp was a script file that ran the requester program.  It
>    is possible to turn off selected process if you have their names.
>    You can just use FindTask to find them too.


Yeh, but lots of processes have the same name! Like "Background CLI"
or "trackdisk.device"  etc..


John

    Just disable them all! :-)  Actually, the cases under which you would
    want to suppress requesters are few.  You would probably want to
    get rid of all of them, or just the AUX: one, or one for a program
    that you are writing.  At any rate, doing this shouldn't be too
    difficult.
    
     - Chris