Path: utzoo!attcan!uunet!wuarchive!rex!uflorida!ukma!dftsrv!ames!pacbell!rtech!cpsc6a!crs
From: crs@cpsc6a.att.com (Chris (I'm Outta Here!) Seaman)
Newsgroups: comp.sys.amiga
Subject: Re: Xoper Bug Figured Out.
Message-ID: <2347@cpsc6a.att.com>
Date: 8 Nov 89 19:05:29 GMT
References: <970@unsvax.NEVADA.EDU>
Distribution: comp
Organization: AT&T (CPSC), Oakland, CA
Lines: 39

First, let me say that Xoper 2.0 works well on my 2500 (3 megs RAM, SetCPU,
ARP, dmouse, MyMenu, SimGen, ...).

maniac@arrakis.nevada.edu (ERIC SCHWERTFEGER) writes:
<      Well, after much fighting, I think I finally figured out the problems
< with Xoper 2.0 (yes, I meant plural).
<      First of all, Xoper will hang if you don't have "xoper.startup" in s:,
< but this could be related to another bug.

Hmmmm...  I was lucky enough to copy the file to s: before I tried it the
first time, so this one  never bit me.

<      Second, if you don't specify "usescreen" in the xoper.startup file,
< Xoper will attempt to open a window on the WB screen, and will hang.

Oops!  Putting 'usescreen' in my Xoper.startup GURU'd my Amy every time.
In fact, it only starts up when there is NO usescreen present.  As an
aside, if I specify usescreen AFTER popping up the window the first time,
everything is OK.

<      Finally, you can't use the -b command on the CLI line, nor can you
< use the "hold" command in the xoper.startup file, because both cause
< XOper to get hung up.

Don't know about 'hold', but I have 'xoper >NULL: -b' in my
startup-sequence, and it works just dandy.

<      In other words, you must have a file "xoper.startup" in s:, and you
< must also specify "usescreen" as an option in that file.

Probably for some, but not all Amy's.

< Eric Schwertfeger, UNLV, maniac@arrakis.nevada.edu

-- 
Chris (Insert phrase here) Seaman |  /|__|\__/|__|\
crs@cpsc6a.att.com <or>           | |              |     Where does he get
...!att!cpsc6a!crs                | |  /\/\  /\/\  |   those Wonderful toys?
The Home of the Killer Smiley     |  \|    \/    |/