"len turner" <len.turner@canrem.uucp> (06/01/91)
I've seen this asked fairly often before, but I've never seen an answer.
So, I'll try asking again.
First a bit of preliminary. I'm using an A500 under 1.3, programming
with DICE 2.06.17R.
The program I'm writing is an offline mail reader for QWK mail packets
from PCBoards. The progam is in a working stste, if still crudly so (I'm
using it to enter this via a UseNet GateWay, which is my only net access)
This program has to call external programs to do some of it's work.
Most notably archiving/unarchiving utilities and a text editor.
Most such programs are either CLI based or open their own windows on the
WorkBench screen. In either case I want them to use my CustomScreen
instead of the WorkBench screen.
So, the question is "How do I get a FileHandle to pas via Execute()
that will cause output to a window on my CustomScreen instead of the
WorkBench screen?"
I know this can be done with ConMan, but I prefer not to require anything
not a part of the original system, no matter how worthwhile that product is.
And related to that, how do I get a program that expects to open a window
on the WorkBench screen to open it's window on my CustomScreen?
(E.g. If my program were to call DME, how would I get it to open it's
window on my screen.)
I've seen this done but have no idea how to do it myself.
Would this require putting together some sort of "fake" FileHandle and
somehow linking it into the system?
The RKM: I&A is very sparse in it's doc of FileHandles and the Bantam
AmigaDOS Manual has a (slightly) fuller description, but it ends with the
short paragraph:
This description does NOT match dosextens.h or .i. Use
the include file information instead.
Somehow that reduces my faith in the Bantam description. :-(
Anyway please e-mail any help you can give, I'll summarize any
information received that helps.
Thanks in advance.
--Len
len.turner@canrem.uucp (or len.turner%canrem.uucp@lsuc.on.ca)
...lsuc!canrem!len.turner
---
# Amy Reads Her Mail v0.77 # (ALPHA)
--
Canada Remote Systems. Toronto, Ontario
NorthAmeriNet Host"john russell" <john.russell@canrem.uucp> (06/01/91)
(Under KS 1.3) When a custom screen is in front of the WB screen, and its flag bits contain the value WBSCREEN, any window that tries to open on WB opens on the custom screen instead. Nothing special about the filehandle. Note that the flag bits are only part of a word, so you can't just assign WBSCREEN, you have to use a combination of and/or operations. (Under KS 2.0) I understand there is a system-supported way of doing it, but don't know details. John -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host
"len turner" <len.turner@canrem.uucp> (06/02/91)
On 06-01-91 at 12:09 John Russel replied:
JR>(Under KS 1.3) When a custom screen is in front of the WB screen, and
JR>its flag bits contain the value WBSCREEN, any window that tries to open
JR>on WB opens on the custom screen instead. Nothing special about the
How system friendly is this? If I do something like:
twiddle bits to make my screen WB;
Execute("pgm-name",NULL,NULL);
untwiddle the bits I twiddled before
then during the time that other program is running, my screen _is_ the WB
screen. Unfortunately, since the Amiga multi-tasks, there may be another app
running that decides this would be a good time to open a window on the
workbench. Would not that window end up on my screen?
This seems to make it all too possible for my app to exit, closing its
screen, while someone else's window is still open on it. I suspect this
would not have a pleasing effect on the user.
Is there a safe way to get around this?
I could reduce the time when that could happen by using
Execute("run pgm-name", NULL,NULL);
but for the purposes of my app I want the other program to be run
synchronously. Other wise the user would have an opportunity to muck things
up himself. ("never underestimate the stupidity of an end user.").
JR>filehandle. Note that the flag bits are only part of a word, so you
I managed to mix two separate questions together. The need for a
filehandle arises when my app has been called from WB, so has no stdin or
stdout and I need to use a routine that only runs from CLI and confidently
expects to find valid stdin & stdout (or at very least stdout).
In some cases at least I could use something like
BPTR hndl=Open("NIL:",MODE_OLDFILE);
if(hndl!=NULL) Execute("pgm-name",hndl, hndl);
else {do something intelligent about the situation}
but I don't know if that would be safe in general.
JR>can't just assign WBSCREEN, you have to use a combination of and/or
JR>operations.
JR>(Under KS 2.0) I understand there is a system-supported way of doing it,
JR>but don't know details.
I don't have 2.0 on my 500, and considering the current state of my
finances it may be quite a while after it becomes available that I do get
it. Consequently, information about how easy this would be under 2.0 is not
only not very helpful, it's downright depressing. :-(
Thanks for the quick reply & help.
--Len
len.turner@canrem.uucp (len.turner%canrem.uucp@lsuc.on.ca)
...lsuc!canrem!len.turner
---
# Amy Reads Her Mail v0.77 # (ALPHA)
--
Canada Remote Systems. Toronto, Ontario
NorthAmeriNet Host