w-colinp@microsoft.UUCP (Colin Plumb) (01/17/89)
An acquaintannce of mine from Toronto (who I can't readily get in touch with now) told me about two calls, AddDosNode and DeleteDosNode (or it may be DOS; this was verbal) that do All The Right Things in hitting the di_DevInfo list to add volumes, devices, etc. He mentioned they were documennted in some obscure CATS publication, an "AmigaDos Technical Reference" (or something similar-sounding), that was not, repeat *not* the one in the back of the 1.0 RKM's, published by Bantam in the AmigaDos manual, etc. Something *entirely* different, just having a similar-sounding name. Now, nobody I've talked to has heard of anything of the sort. Has anyone out there heard of such a thing? I'm starting to have serious doubts about its existence. The problem I'm really trying to manage is to signal open "Please insert volume..." requesters, so the user doesn't have to click "retry." I believe most else can be handled by hitting the list directly, using Forbid() and Permit(). Does anyone know how to solve this problem? I could, I suppose, keep a MsgPort open for each volume I know about and put up the requesters myself, but this is somewhat expensive in terms of memory, and some experiments by others in using something other than a process' pr_MsgPort for the packet port have uncovered difficulties. It seems much simpler to use existing Dos features. And no matter what I do, I can't otherwise handle the requester for a volume that has never been mounted. Thanks for any assistance, and remember that this semi-mythical "Technical Reference" is *not* the obvious one. -- -Colin (uunet!microsof!w-colinp)
jesup@cbmvax.UUCP (Randell Jesup) (01/18/89)
In article <284@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes: >An acquaintannce of mine from Toronto (who I can't readily get in touch with >now) told me about two calls, AddDosNode and DeleteDosNode (or it may be >DOS; this was verbal) that do All The Right Things in hitting the di_DevInfo >list to add volumes, devices, etc. Yes, use them. There are autodocs for them in the 1.3 developers update (call/write CATS), and I believe they are in expansion.library (I could be wrong). >The problem I'm really trying to manage is to signal open "Please insert >volume..." requesters, so the user doesn't have to click "retry." I believe >most else can be handled by hitting the list directly, using Forbid() and >Permit(). They do this already. Wait a second or two. The one exception is the requesters WB puts up when you do a loadwb, and some disks aren't in drives. Those you have to Retry (will be fixed). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
billk@pnet01.cts.com (Bill W. Kelly) (01/18/89)
Colin (uunet!mocrosof!w-colinp) writes: >The problem I'm really trying to manage is to signal open "Please insert >volume..." requesters, so the user doesn't have to click "retry". By the sorts of things you had tried to accomplish this, I figgure you already know about what I'm going to suggest, and that it doesn't do what you want. Anyway, if you set pr_WindowPtr to -1, the "Please insert volume..." requesters will not come up in the first place. (For YOUR process, at least.) -- Bill W. Kelly billk@pnet01.cts.com {nosc ucsd hplabs!hp-sdd}!crash!pnet01!billk crash!pnet01!billk@nosc.mil
shimoda@infohh.rmi.de (Markus Schmidt) (01/20/89)
In article <3734@crash.cts.com> billk@pnet01.cts.com (Bill W. Kelly) writes: >Anyway, if you set pr_WindowPtr to -1, the "Please insert volume..." >requesters will not come up in the first place. (For YOUR process, at least.) Is this guaranteed to be so in WB 1.4, 1.5 and 2.0 too? Or is it just another "break the amiga soon"-hack? .-----------------------------------------------------------------. | shimoda@rmi.de `---' The last remaining adventure | | shimoda@gopnbg.UUCP |O o| since there are no more tigers: | | ==Y== Doublebuffered async. I/O _ | |----------------------- `U' ------------------------------ _ // | | Good terminalpackages begin with A: AmigaCall, A-Ta.. \// | `-----------------------------------------------------------------'
billk@pnet01.cts.com (Bill W. Kelly) (01/22/89)
shimoda@infohh.rmi.de (Markus Schmidt) writes: >In article <3734@crash.cts.com> billk@pnet01.cts.com (Bill W. Kelly) writes: >>Anyway, if you set pr_WindowPtr to -1, the "Please insert volume..." >>requesters will not come up in the first place. (For YOUR process, at least.) >Is this guaranteed to be so in WB 1.4, 1.5 and 2.0 too? >Or is it just another "break the amiga soon"-hack? No. This is perfectly legal, and is documented pretty clearly in the AmigaDOS Technical Reference Manual. Quoted without permission: "The value of WindowPtr is used when AmigaDOS detects an error that normally requires the user to take some action. Examples of these errors are attempting to write to a write-protected disk, or when the disk is full. If the value of WindowPtr is -1, then the error is returned to the calling program as an error code from the AmigaDOS call of Open, Write, or whatever. If the value is zero, then AmigaDOS places a request box on the WorkBench screen informing the user of the error and providing the oppertunity to retry the operation or to cancel it. If the user selects cancel then AmigaDOS returns the error code to the calling program. If the user selects retry, or inserts a disk, then AmigaDOS attempts the operation once more. "If you place a positive value into the WindowPtr field, then AmigaDOS takes this to be a pointer to a Window structure. Normally you would place the Window structure of the window you are currently using here. In this case, AmigaDOS displays the error message within the window you have specified, rather than using the Workbench screen. You can always leave the WindowPtr as zero, but if you are using another screen, then the messages AmigaDOS displays appear on the Workbench screen, possibly obscured by your own screen. [not true anymore because Workbench Screen is always brought to front] "The initial value of WindowPtr is inherited from the process that created the current one. If you decide to alter the WindowPtr from within a program that runs under the CLI, then you should save the original value and restore it when you finish; otherwise, the CLI process contains a WindowPtr that refers to a window that is no longer present." IN FACT, IT REALLY ****BUGS**** ME WHEN PROGRAMMERS OPEN CUSTOM SCREENS AND WINDOWS AND FAIL TO SET THIS POINTER!!!!!!! :-/ Anyway, a couple years ago, I wrote tiny (276-byte) program called FixReq that fixes this problem for those naughty programs. FixReq is meant to be run in your Startup-Sequence. It installs itself (patches AutoRequest()) and returns (so there is no need to actually 'RUN' fixreq. Once installed, all "System Requests" will pop up in the active window, on the active screen. (As opposed to bringing the Workbench Screen to front.)) I'll be happy to UUEncode it and post it, if anyone's interested. NOTE: Programmers should STILL set pr_WindowPtr whether they have FixReq or not. :-) -- Bill W. Kelly billk@pnet01.cts.com {nosc ucsd hplabs!hp-sdd}!crash!pnet01!billk crash!pnet01!billk@nosc.mil