Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!njin!princeton!udel!wuarchive!cs.utexas.edu!uunet!mcsun!inesc!jmc From: jmc@inesc.UUCP (Miguel Casteleiro) Newsgroups: comp.sys.amiga Subject: Re: Xoper Bug Figured Out. Summary: Is it? Message-ID: <114@inesc.UUCP> Date: 1 Nov 89 21:07:06 GMT References: <970@unsvax.NEVADA.EDU> Distribution: all Organization: INESC - Inst. Eng. Sistemas e Computadores, LISBOA. PORTUGAL. Lines: 46 In article <970@unsvax.NEVADA.EDU>, 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). Sorry to disapoint you, but Xoper works fine for me. > First of all, Xoper will hang if you don't have "xoper.startup" in s:, > but this could be related to another bug. I tried running Xoper with or without xoper.startup and it runs fine. > 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. I don't use "usescreen", Xoper opens a WB window and does not hang. > 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. I tried to run Xoper with the -b option, and it stays in the background until I hit LA-RA-X. At that point it starts running normaly. The hold command works fine too, and makes it go to the background again. > > In other words, you must have a file "xoper.startup" in s:, and you > must also specify "usescreen" as an option in that file. I don't think that is the solution. To resume everything, Xoper has never hanged on me, does everything the docs say it does and is a fine utility. My system: A2000 + 1.5MB + 20MB MiniScribe KS 1.3, WB 1.3, ARP 1.3, QMouse, MyMenu. > > Eric Schwertfeger, UNLV, maniac@arrakis.nevada.edu -- __ Miguel Casteleiro at __ /// INESC, Lisboa, Portugal. "I know exactly what I'm doing." \\\/// Only UUCP: ...!mcsun!inesc!jmc -- Famous last words \XX/ Amiga