Turn off mouse with graf_mouse problem

[exxos]

I simply have graf_mouse 256,0 which seems to turn the mouse off, though it does not seem to work when there is a GEM window open ? As far as I can tell, it turns it off during dialog type boxes, but seems a GEM window overrides it and display the mouse anyway. I tried turning the mouse off after opening the GEM window, but the mouse is still there, anyone any ideas on this ?

[Cyprian]

Try this one:

Code: Select all

v_hide_c         hide the mouse

;do a window content refresh

v_show_c   #0      show the mouse


[exxos]

Try this one:

Code: Select all

v_hide_c         hide the mouse

;do a window content refresh

v_show_c   #0      show the mouse


Nice thanks That seems to work ok when called after a new window opens.

[Cyprian]

should works before and after window open/create.
still other application (or accessory in single TOS) can show the mouse hidden by you

[Mikefulton]

You shouldn't use the VDI to turn the mouse off, in general, unless you're drawing stuff without windows and AES. The graf_mouse call is the right way to do it when you're using AES.

A little more detail and context about the situation would be helpful.

[Cyprian]

Mike my example was taken from Devpac 3.1 sample GEM application "gemtest.s":

Code: Select all

* this draws the picture in the window
* which is an oval on top of a rectangle

* before drawing anywhere you have to hide the mouse
drawwindow
   v_hide_c         hide the mouse
   vsf_interior   #2      pattern

   movem.w   xstart,d0-d3      AES rectangle
   add.w   d0,d2
   subq.w   #1,d2
   add.w   d1,d3
   subq.w   #1,d3         convert to VDI
   vr_recfl   d0,d1,d2,d3   filled rectangle
* the oval has to be drawn in the user defined pattern
   vsf_interior   #4

   movem.w xstart,d0-d3
   asr.w   #1,d2         half width
   asr.w   #1,d3         half height
   add.w   d2,d0         x centre
   add.w   d3,d1         y centre
   v_ellipse   d0,d1,d2,d3

* we have finished drawing so get the mouse back
   v_show_c   #0      show the mouse
   rts


GEMtest.png

But would be cool to know a better way to turn the mouse off/on.

[Mikefulton]

I don't think that example is really a good one. It doesn't really do everything you should do, if I recall correctly.

I wanna know more about how/why graf_mouse didn't seem to be working with you. What were you trying to draw and what else was on screen?

[Mikefulton]

Mike my example was taken from Devpac 3.1 sample GEM application "gemtest.s":
But would be cool to know a better way to turn the mouse off/on.

I wanted to dig up Devpac and look at the full sample source before I commented further, but now that I've done that...

Looking at that source, you'll note that they refer to "method a" and "method b" of redrawing a window? They should have said "right way" and "wrong way", with them selecting the wrong way.

When you redraw a window, you're supposed to walk the list of visible rectangles using wind_get(WF_FIRSTXYWH...) and wind_get(WF_NEXTXYWH...), setting the clipping for each one, and drawing the window contents. If a window is on top, it will only have one rectangle in the list so this is fairly quick. If the window is not on top, however, then this redraw method will respect whatever might be on top, overlaying it.

The Devpac demo makes the assumption that the window being redrawn is always on top and skips walking the rectangle list, which makes it pretty much useless as a real-world example.

Ultimately, a redraw routine should look more or less like this (this is a simplified pseudo-code version of the redraw code from FONTZ):

Code: Select all


graf_mouse( M_OFF, 0L );
wind_update( BEG_UPDATE)
wind_get( WF_CURRXYWH, *windrect );
wind_get( WF_FIRSTXYWH, *redrawrect )

intersectionRect = intersection of redrawrect & windrect

while( intersectionRect ->width > 0 && intersectionRect ->height > 0 )
{
   v_set_clip( intersectionRect );
   draw_window_contents()
   v_set_clip( reset )
   wind_get( WF_NEXTXYWH, *redrawrect)
   intersectionRect = intersection of redrawrect & windrect
}

wind_update(END_UPDATE);
graf_mouse( M_ON, 0L );



[Cyprian]

Thanks to MagiC I learned how to use wind_get and WF_FIRSTXYWH/NEXTXYWH but still with v_hide_c / v_hide_c
And based on Devpac sources I was using graf_mouse only as here:

Code: Select all

* set the mouse to an arrow
   graf_mouse   #0


[Mikefulton]

Using VDI to control the cursor can result in problems like the AES losing track of the mouse visibility. Seriously, if you're having some issue using graf_mouse, it's an issue with your program, not AES, and it's better to fix what's actually wrong.

Generally, the only time you should be turning off the mouse is when redrawing a window. You mentioned that graf_mouse "worked for a dialog box" but why would you be using it then? It's not needed for dialog boxes or anything else that gets drawn via AES.

It's still not clear how any problem is really manifesting itself. Are you getting a little screen glitch because a redraw happens on top of a visible mouse, or is something else happening?

[exxos]

As I said before the graf_mouse didnt seem to work totally. When I used v_hide_c, that turned off the mouse but only after I called it after a GEM window was opened.

Pretty much I could have something like

Code: Select all

SUB  xxxx
Open window .....
close window...
END SUB

Where I then had

Code: Select all

SUB  xxxx
graf_mouse 256,0
Open window .....
close window...
END SUB

Which didn't work.

Code: Select all

SUB  xxxx
Open window .....
graf_mouse 256,0
close window...
END SUB

Then which didnt work.

Code: Select all

SUB  xxxx
v_hide_c
Open window .....
close window...
END SUB

Then this worked.

Code: Select all

SUB  xxxx
Open window .....
v_hide_c
close window...
END SUB

In some code there is literally only open window and close it, cant exactly go wrong.

In relating to other issues, when scrolling text on the screen , the mouse pointed gets copied upwards on the screen causing a bit of a mess on the screen, so it needs to be turned off. I only want the mouse visible on the main option screen for clicking options and menus, but hidden all other times.

Dialog boxes don't seem to make the re-appear, but each time I call a window open , it turns the mouse on again. Maybe its some "feature" in hisoft basic itself, I have no idea.

[rockyone]

I think v_hide_c into account the number of appeal of the inverse function?
This is the case in Omikron, and actually, the VDI can redésiner cursseur the mouse if the number of v_hide_c and lower call has v_show_c
A direct appeal to the VDI function to ignore the number of call

[Mikefulton]

As I said before the graf_mouse didnt seem to work totally. When I used v_hide_c, that turned off the mouse but only after I called it after a GEM window was opened.

In some code there is literally only open window and close it, cant exactly go wrong.

In relating to other issues, when scrolling text on the screen , the mouse pointed gets copied upwards on the screen causing a bit of a mess on the screen, so it needs to be turned off. I only want the mouse visible on the main option screen for clicking options and menus, but hidden all other times.

Dialog boxes don't seem to make the re-appear, but each time I call a window open , it turns the mouse on again. Maybe its some "feature" in hisoft basic itself, I have no idea.

What I still am unsure about is why you're turning off the mouse when you're not doing a window redraw, but I'm starting to get a better idea. You said "when scrolling text on screen" but it's unclear if you're talking about text in a window, or what, but given that you're talking about doing stuff without having opened a window, I'm going to guess that you're printing to the VT52 console using GEMDOS or BIOS calls. Can you confirm that?

If so, that's the root of the problem. You shouldn't be using those text output functions from a GEM-based program. If you use them, you're basically deciding to live with the screen output being potentially glitched. There really is no way to do it that's 100% effective.

If you use the VDI functions to control the cursor, what's going to happen is that sooner or later, the AES is going to want to change the mouse visibility itself for some reason (like drawing a menu, to name but one possibility), but the current state will be different from what AES expects because you've changed it, and you'll get glitches as a result.

By the way, the window-redraw function I outlined earlier applies anytime you want to redraw the contents of a window, even if it's not directly in response to a redraw message. That is, if you need to scroll the window contents, you should still be using that basic method, even if the actual draw function at the core is different depending on what's happening at that particular moment.

[exxos]

Here is a video of one issue , which is why I need to turn the mouse off. All these routines worked fine in Previous versions of Gembench, so its tried and tested stuff. Though I can't work out how the mouse was actually hidden in that code.

I don't really see the problem of turning off the mouse and turning it on again after the test anyway. My problem initially was graf_mouse did not seem to work.

mse.zip

[wongck]

Code: Select all

SUB  xxxx
Open window .....
close window...
END SUB

Where I then had

Code: Select all

SUB  xxxx
graf_mouse 256,0
Open window .....
close window...
END SUB

Which didn't work.

Code: Select all

SUB  xxxx
Open window .....
graf_mouse 256,0
close window...
END SUB

Then which didnt work.

Code: Select all

SUB  xxxx
v_hide_c
Open window .....
close window...
END SUB

Then this worked.

Code: Select all

SUB  xxxx
Open window .....
v_hide_c
close window...
END SUB

In some code there is literally only open window and close it, cant exactly go wrong.

In your code above, where is the graf_mouse() to show the mouse again?
Importantly, graf_mouse() - no_shown and show needs to be done in pairs, that sequence.

Every time you want to draw something on the screen, you need to turn off mouse to draw and then after drawing it, turn it on again.
In your bench mark software, this will slow down the actual run.
So best just turn off when user press began until all the benchmark are done then after it writes the results, turn it back on.
But not sure how it will behave on Mint.

[Mikefulton]

Here is a video of one issue , which is why I need to turn the mouse off. All these routines worked fine in Previous versions of Gembench, so its tried and tested stuff. Though I can't work out how the mouse was actually hidden in that code.

I don't really see the problem of turning off the mouse and turning it on again after the test anyway. My problem initially was graf_mouse did not seem to work.

mse.zip

The video didn't wanna play on my system. Do you know what codec it needs?

[exxos]

The video didn't wanna play on my system. Do you know what codec it needs?

Try this one, its MPEG4/XVID

mse2.zip

[Mikefulton]

I think what's happening here is that the mouse visibility is getting out of sync. That is, you're calling graf_mouse(M_ON) more times than graf_mouse(M_OFF). They need to be in sync. Normally, if you change mouse visibility in just one place, like the block of code I showed you, that's not a problem, since there's no way for the program flow to avoid one of the calls.

If you wanna post the program source code, i'll have a look at it to see if anything else pops out.

[exxos]

I think what's happening here is that the mouse visibility is getting out of sync. That is, you're calling graf_mouse(M_ON) more times than graf_mouse(M_OFF). They need to be in sync. Normally, if you change mouse visibility in just one place, like the block of code I showed you, that's not a problem, since there's no way for the program flow to avoid one of the calls.

If you wanna post the program source code, i'll have a look at it to see if anything else pops out.

I'm only calling it twice, once to turn it off, then after the test is run, turn it on again.

I've wrote a very quick test routine, seems I was right, when GEM window is called, it turns on the mouse again without the window call the mouse turns off and on as expected.

Code: Select all

LIBRARY "gemaes","gemvdi","bios","gemdos","xbios"

'$option k150
'$option g,y+,v-,u+,#,[,]
'$option fE:\GB6\graf.PRG

DEFINT a-z

'crappy pause for now
while inkey$=""
wend

graf_mouse 256,0

'crappy pause for now
while inkey$=""
wend

WINDOW OPEN 5,"A GEM Window",0,0,639,199,&hfef

'crappy pause for now
while inkey$=""
wend

WINDOW CLOSE 5

'crappy pause for now
while inkey$=""
wend

graf_mouse 257,0

'crappy pause for now
while inkey$=""
wend

.

GRAF.zip

[exxos]

I tried a change..

Code: Select all

'WINDOW OPEN 5,"A GEM Window",0,0,639,199,&hfef

id=wind_create(4,0,20,600,180)
junk=wind_open(id,0,20,600,180)
'vr_recfl 0,0,638,199

'crappy pause for now
while inkey$=""
wend

'WINDOW CLOSE mywind_id
junk=wind_close(id)
junk=wind_delete(id)

That also seems to work OK. Though the Hisoft book recommends using its internal window calls rather than using the AES/VDI functions directly That would involve a lot more programming just for the sake of hiding the mouse pointer. Though the original gembench code must hide the mouse somehow, as it uses the hisoft window functions. I will take another look at it.

[Mikefulton]

You're turning the mouse off then doing something that causes AES to draw stuff. Namely, the window you're opening.

Don't do that. Those graf_mouse calls don't belong there. You don't need or want to turn off the mouse to open a window. You only need to do it when drawing the window contents, as in the sample code I posted earlier.

[exxos]

You're turning the mouse off then doing something that causes AES to draw stuff. Namely, the window you're opening.

Don't do that. Those graf_mouse calls don't belong there. You don't need or want to turn off the mouse to open a window. You only need to do it when drawing the window contents, as in the sample code I posted earlier.

I want the mouse to be off while the contents are drawn, thats the whole idea.

What I had originally was to turn off the mouse in the test loop routine, so doing 1 test or all tests would just keep the mouse off until all tests were done then turn it back on again. Though when I posted I did not know that opening the window would cause the mouse to turn back on. I thought graf_mouse wasn't working. Putting graf_mouse AFTER the window open call seems to be working OK. I just have to type it in after each window call which is a bit cluttery, but obviously GEM wants it to work like that so thats what I will do. Problem solved

[exxos]

Something which I just un-forgot. when doing the window tests, its turning on the mouse on with the windows, so in order to keep the mouse off, I would have to call the mouse off after each window call which is tainting the results. I can use graf_mouse when it just opens up a single window and I can turn the mouse off after the window call, draw my stuff, then close the window, turn mouse back on etc but it doesn't solve the problem with windows which open and close very fast. I also now seem to have a odd bug where when the main screen is drawn it draws over the top of the mouse points and it vanishes, when I move it, I get corruption in the screen graphics until I refresh the window. I also now see that "sync" issue where calling the mouse off command seems to make it ignore turning it off.

I will start again with adding the mouse on/off with graf_mouse as my code has become a right mess. If the mouse ends up flashing up during the window loops then it will just have to stay like that as getting a bit tired of buggering around with it now

[exxos]

I've got it all fixed other than the window loop test where I can't turn the mouse off. Even with the function in the loop it doesn't stay hidden.

The only other test which seems to misbehave is the blitting graphics test, the mouse won't stay hidden there either.

I also noticed the mouse can still access the menu even though it hidden, so I need to fix that aswell now.

From what I can tell about v_hide_c it hints in the docs that it turns off the mouse totally, so if using multitasking you would completely lose the mouse.

[jfl]

It's hard to say without more code to verify but judging by your comments I get the feeling you haven't really understood how this is supposed to work. Basically, you turn the mouse off just before drawing on the screen and turn it on again just after you are finished drawing. That's it. At no other moment do you need to fiddle with the mouse pointer.