ZSR@PSUVMB.BITNET (01/05/87)
My rodent and I have *not* been getting along very well lately. It seems that the GEM routine that moves the mouse (and stores the area underneath the sprite image, as it should) saves an old version of what is under the mouse, my application draws to the screen (changing what is under the mouse) and then, when the mouse is moved from its present spot, the old background (without the screen updates) is copied back in its place. In other words, when I move the mouse (such as for making a "rubberband line"), the mouse leaves a trail of garbage on the screen. If there was some way that I could find out where GEM stores the area of the screen that is under the mouse so I could modify that as well, the problem would be solved. Another example: I wrote a program that allows the user to make a rubber box (using graf_rubberbox), and then lets him drag it around the screen. It works great, except when the mouse is over the outline of the box while dragging. When this happens, GEM saves the corner of the box (which is under the mouse), the user moves the box elsewhere, then GEM rewrites the screen that was under the mouse, complete with the corner of the box (which is not actually located elsewhere). This has been *sooooo* frustrating. There must be a way around it, because programs such as DEGAS don't have the fragmentation problem. Argh, beaten by small, furry animal! On the lighter side, here is a tidbit of knowledge that I can pass on to all. (I learned it the hard way, of course...) I was using a command shell (from RIS Industries, or something? I think I got it with the Dev. Kit or it was public domain). The command shell works well, but you *cannot* use programs that use any of the forms library or file selector routines with it. You must drop back to the desktop to run these programs. What I end up doing is editing and compiling under the shell, dropping to the desk to run the program, then warmstarting (setting the paths and such...) the command shell again. Trying to use the above routines (and possibly others) resulted in a not-so-spectacular system crash (no time bombs, just nuthin'). I hope my ramblings have helped some poor soul who was about to make the same mistake. On the other hand, is there anyone who could help to get me back on speaking terms with my mousie? Please reply to the net because this account can go POOF at any time. Thanks in advance! ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Christopher Johnson Penn State University ZSR @ PSUVM, PSUVMA, PSUVMB ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ericr@hpvcla.HP.COM (Eric Ross) (01/08/87)
Whenever you update the screen under the cursor, you must turn the mouse curser off. Most screen drawing routines I have seen bracket their drawing primitives with a hide cursor and show cursor(The exact routine names escape me at present). Updating the screen on top of the visible cursor will always exhibit the behavior you describe. Eric Ross ihnp4!hpfcla!hpvcla!ericr
holloway@drivax.UUCP (Bruce Holloway) (01/08/87)
Sounds like you're drawing over the mouse. Turn the mouse off before you draw anything, then turn it back on again afterwards. -- ....!ucbvax!hplabs!amdahl!drivax!holloway "What do you mean, 'almost dead'?" "Well, when you stop breathing, and moving around, and seeing things... that kind of almost dead."
bammi@cwruecmp.UUCP (01/08/87)
In article <9282ZSR@PSUVMB> ZSR@PSUVMB.BITNET writes: >Another example: I wrote a program that allows the user to make a rubber box >(using graf_rubberbox), and then lets him drag it around the screen. It works I think that doing a M_OFF, move (and possible redraw of the rectangle) and then doing a M_ON 'should' do it. >it was public domain). The command shell works well, but you *cannot* >use programs that use any of the forms library or file selector routines with >it. You must drop back to the desktop to run these programs. What I end up Micro C shell from beckemeyer has a feature that lets you run a Gem application from the shell. It is really handly for the above situations. -- usenet: .....!decvax!cwruecmp!bammi jwahar r. bammi csnet: bammi@case arpa: bammi%case@csnet-relay compuServe: 71515,155
apratt@atari.UUcp (Allan Pratt) (01/08/87)
For the guy whose mouse is leaving droppings: check your usage of the wind_update flag. You should set it when you are doing updates, and clear it when you're done. Setting this flag hides the mouse (I think) and clearing it restores the mouse, which gives the AES a chance to update its idea of what's on the screen under the mouse. Why calls like graf_rubberbox don't do this internally, I don't know. Maybe they do and you're doing something out of sequence. I am not an AES programmer, by any means. (You thought my settime utility was .TTP because it went in the AUTO folder? Wrong! It's .TTP because ALL my programs are .TTP! :-) /----------------------------------------------\ | Opinions expressed above do not necessarily | -- Allan Pratt, Atari Corp. | reflect those of Atari Corp. or anyone else. | ...lll-lcc!atari!apratt \----------------------------------------------/