Path: utzoo!utgpu!watserv1!watmath!att!att!emory!wuarchive!julius.cs.uiuc.edu!psuvax1!rutgers!njin!uupsi!sunic!news.funet.fi!ra!rosenber
From: rosenber@ra.abo.fi (Robin Rosenberg INF)
Newsgroups: comp.sys.amiga
Subject: Re: Printer icon (was: Why is everyone bitching about Workbench)
Message-ID: <400@ra.abo.fi>
Date: 29 Oct 90 22:39:19 GMT
References: <35239@cup.portal.com> <6895@sugar.hackercorp.com> <15446@cbmvax.commodore.com>
Organization: Abo Academy, Finland
Lines: 59

In article <15446@cbmvax.commodore.com>, ken@cbmvax.commodore.com (Ken Farinsky - CATS) writes:
> In article <1990Oct26.202218.23039@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes:
> >In article <29244@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes:
> >>And as an author of YAWBR (Jazzbench), I wouldn't mind putting in a few of
> >>my own:
> >>	4.  No access to devices like prt: par: ser: pipe:, etc.
> >	It would be TRIVIAL to create an icon that would copy the
> >file. Under 2.0 you can open a window or an icon which will
> >recognize when an icon is dropped on it...Use AppIcon and do it!
> This kind-of assumes a very simple file structure (can you say ASCII?).
> You could make your program more complicated and have it handle IFF files,
> but what would you do with word processor data files, 3-D objects,
> postscript, and the like?  What happens when you copy a SMUS file to ser:?
> This all works only if you have very simple data files or a very smart
> program.

 The printer icon is the most interesting one. Dropping an icon on the
printer and get the file printer. It's a very appealing approach, with
the drawback just noted; How does the printer know how to do it. The
real answer is of course that only the application that created it
(and perhaps a few other programs) knows it. The only information
available is the Default Tool in the icon that belongs to the file.

There might be a way. Start the application and give it a message
telling it to print the file and exit. The command can be passes as an
ARexx message (or two).

Launch the application.
Send the command 'Print' via ARexx
Send the command 'Quit'.
Finished.

A few things needs to be standardized.
1. Can the application receive messages?
2. What is the name of the rexx port?

Suggested solution(s) to
1) This is tricky. I know of no way. So why not take a chance. Let
   the printer launch the application and IF a rexx port comes up
   with a name according to (2) then send the commands. IF no port
   comes up within some period of time. Just skip it.

2) The rexx port has the same name as the Application.
   or A tooltype says REXXPORT=name_of_rexxport. The latter applies
   if present.

With a scheme like this, even some of TODAY's programs 'could happen'
to work, and it would be very easy to incorporate the capability in
future programs.  Of course if the printer can't find a rexx port to
send commands to, the application that was launched will just sit
there, waiting for the user to quit it manually, no harm done.

If the application doesn't understand the PRINT or QUIT commands.
Still no harm done. Perhaps the application doesn't support printing.

Comments, flames >nil:,  ideas?

------
	Robin Rosenberg