U46050@UICVM.BITNET ("JOHN ZAFIRIS 543-0971") (04/04/89)
I am in the process of, well, almost finished writing a shell to run programs from obscure corners of my hardrive by just clicking on a square on the screen as in like a GEM button but much faster. Anyway, suffice it to say it is a shell. I have run into two annoying problms. One: The mouse cursor is not handled properly by some programs most notably STWRITER. It cannot be shut off after the offensive program is run and control is back to the shell. It makes a mess of the screen. Has anybody run accross this problem and do you know how to solve it? I am working entirely in machine language so please translate any 'C' lingo into something I could understand. TWO: Some programs also seem to mishandle window closing. After the program is run the windows that it uses sometimes do not get erased. The next GEM program that is run magically inherits the former's windows. This makes a mess of the screen and usually confuses the program that does not know what to do with the extra windows. Again, I am very interested in solutions. I'm all ears. Neither of the above problems occur when the programs are executed from and return to the desktop. What is it doing that I can also do to cure my ills? I am using the TOS exec command directly with a null environment string (whatever that is). Thanks for any info... ...John
USQB015@LIVERPOOL.AC.UK (04/05/89)
Easy,
Use A-line instruction 10 $a i.e. opcode $a00a
e.g. put exactly this instruction in your code (if you've not heard of line
A instructions this may seem a bit wierd, but I assure you it works)
dc.w $a00a
Mark Powellkloppen@gmdzi.UUCP (Jelske Kloppenburg) (04/13/89)
I read your question a while ago, and I read the answers, I think they
are not very helpful. So I'll try to explain what I know.
I mostly program in Modula2 and never used a line-A instruction.
The AES has a graf_mouse call (AES 78). I remember, but dont know
exactly, that after several show mouse (#257) calls, you have to
call hide mouse (#256) as often until the mouse is killed.
But when you call it whith show mouse, the mouse appeares independent
of hide mouse calls.
The VDI has show cursor (VDI 122) and hide cursor (VDI 123). The VDI
has the opposite counting: "Once the cursor is visible, a single Hide
Cursor causes the cursor to disappear. GEM VDI keeps track of the
number of times the Hide Cursor is called..."
What happens if these calls are mixed, what can be the case in calling
foreign programs, I dont know. But in a similar case I call the
VDI Hide Cursor and the mouse is always invisible.
The second problem arises - I think - when programs dont close their
windows and your shell inherits them. The desktop always cleares the
entire window system after program termination. I'd try do make close
window calls for 1, 2, ... 8? after return of a called progam.
kloppenburg@kmx.gmd.dbp.de
UUCP: kloppen@gmdzikbad@atari.UUCP (Ken Badertscher) (04/14/89)
In article <8904051001.AA18434@ucbvax.Berkeley.EDU> USQB015@LIVERPOOL.AC.UK writes: |Easy, | Use A-line instruction 10 $a i.e. opcode $a00a That's also a good way to get the AES confused about how many times the mouse has been hidden/shown. The AES keeps its own internal count of how many times the mouse has been hidden or shown so that it can clean up after applications that go astray with the mouse. This AES count will get out of sync with the actual mouse state if you interleave VDI/line-A show/hide mouse calls with AES graf_mouse calls. So the answer to the question how to kill a mouse cursor isn't all that easy. If your program uses the AES a lot, you should probably use the AES graf_mouse() calls to hide and show the mouse. If not, use VDI or even line-A. You could even disable mouse event reporting at the IKBD level if you wanted to go so far. | Mark Powell -- Ken Badertscher | #include <disclaimer> Atari R&D | No pith, just a path: Software Engine | {portal,ames,imagen}!atari!kbad