Turn off mouse with graf_mouse problem

[exxos]

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.

Thats what I am doing, but some functions turn the mouse back on again, like opening a window and doing blitting for some odd reason. I turn it off just after opening the window (dont really have a choice there) it works on all tests other than the blitting test and GEM window test.

OK knock yourselves out... I can't figure it out, I give up

Code: Select all

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

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

DEFINT a-z

call test11&

SUB TEST11&

STATIC tmp(),size&,t&,p,x1,y1,w1,h1
STATIC x,y,w,h,i,bar_y2,bar_h,blith,c

mywind_id=freewind
x1=0:y1=10:w1=639:h1=199-12

vsf_color 1
   bar_y2=84
   bar_h=40

WINDOW OPEN mywind_id,"Blitting",0,12,630,190,&hfef
graf_mouse 256,0 ' turn off mouse

for c=1 to 3
vsf_color c

x=10:y=44:w=200:h=bar_h
v_bar 10,y,210,bar_y2

p=4 ' if mono then we should really set colours to 1 and 0
size&=2*(h+1)*((w+1)\16+1)+6

REDIM tmp(size&*p)

FOR i=0 TO 400
   GET (x,y)-(x+w,y+h),tmp
   PUT(x+i,y),tmp,PSET
NEXT i
FOR i=0 TO 98
   GET (x,y)-(x+w,y+h),tmp
   PUT(x,y+i),tmp,PSET
NEXT i
NEXT c

vsf_color 1
WINDOW CLOSE mywind_id
ERASE tmp

graf_mouse 257,0 ' turn on mouse
END SUB

BLTTST.zip

[jfl]

Basically, you turn the mouse off just before drawing on the screen and turn it on again just after you are finished drawing.

Thats what I am doing.

No it's not. You're turning the mouse pointer back on after closing the window, not after you're finished drawing.

[exxos]

Basically, you turn the mouse off just before drawing on the screen and turn it on again just after you are finished drawing.

Thats what I am doing.

No it's not. You're turning the mouse pointer back on after closing the window, not after you're finished drawing.

Well I moved it before closing the window and it still does exactly the same. Its acting like the mouse never gets turned off in the first place which I have been saying over and over since my first post. So I can't see when its turned back on makes any difference anyway as its not turning off in the first place. I obviously can't explain this problem well enough even though posting a compiled example and the code. I will just use v_hide_c as it works, its not like people should be running this program along side any other software anyway.

[Mikefulton]

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.

Yes, exactly. What he said.

[Mikefulton]

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.

The mouse can access the menu because you're not doing the drawing right. You don't have the wind_update calls shown in the sample code block I posted. You're taking shortcuts and it's why you're having problems.

As regards v_hide_c, that's correct. And "multitasking" includes vanilla GEM cooperative style with desk accessories, not just MiNT/MultiTOS.

[wongck]

Sorry I am not a Basic users but....
- Is that PSET a Line-A command?
- Is that mixing Line-A direct screen on a AES windows Ok to do so ?

May be that's why the VDI mouse on/off command works better.
Did you try the Line-A version of mouse on/off command ?

[Mikefulton]

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.

Thats what I am doing, but some functions turn the mouse back on again, like opening a window and doing blitting for some odd reason.

That is NOT what you're doing. You keep posting examples where you're turning off the mouse then opening windows, closing windows, etc.

You only do it at the start and and of the actual drawing code.

Opening or closing windows is not part of the drawing code.

Waiting for user input is not part of the drawing code.

[Mikefulton]

Sorry I am not a Basic users but....
- Is that PSET a Line-A command?
- Is that mixing Line-A direct screen on a AES windows Ok to do so ?

May be that's why the VDI mouse on/off command works better.
Did you try the Line-A version of mouse on/off command ?

None of that is an issue here.

[exxos]

That is NOT what you're doing. You keep posting examples where you're turning off the mouse then opening windows, closing windows, etc.

You only do it at the start and and of the actual drawing code.

Opening or closing windows is not part of the drawing code.

Waiting for user input is not part of the drawing code.

I've tried turning the mouse off all over the place. It makes not difference whatsoever where or what point I turn the mouse off. Before or after the window call, before or after drawing code. Here is some more examples.

Code: Select all

SUB TEST11&
'graf_mouse 256,0 ' turn off mouse

STATIC tmp(),size&,t&,p,x1,y1,w1,h1
STATIC x,y,w,h,i,bar_y2,bar_h,blith,c

mywind_id=freewind
x1=0:y1=10:w1=639:h1=199-12

'graf_mouse 256,0 ' turn off mouse

vsf_color 1
   bar_y2=84
   bar_h=40

p=4 ' if mono then we should really set colours to 1 and 0

'graf_mouse 256,0 ' turn off mouse
WINDOW OPEN mywind_id,"Blitting",0,12,630,190,&hfef
graf_mouse 256,0 ' turn off mouse

for c=1 to 3
'graf_mouse 256,0 ' turn off mouse
vsf_color c
x=10:y=44:w=200:h=bar_h
v_bar 10,y,210,bar_y2
size&=2*(h+1)*((w+1)\16+1)+6
REDIM tmp(size&*p)

FOR i=0 TO 400
   GET (x,y)-(x+w,y+h),tmp
   PUT(x+i,y),tmp,PSET
NEXT i
FOR i=0 TO 98
   GET (x,y)-(x+w,y+h),tmp
   PUT(x,y+i),tmp,PSET
NEXT i
NEXT c
graf_mouse 257,0 ' turn on mouse
vsf_color 1
WINDOW CLOSE mywind_id
ERASE tmp

END SUB

[jfl]

I've tried turning the mouse off all over the place.

That's your problem, right there. You are randomly and repeatedly turning the mouse off for no reason whatsoever and then suddenly turning it on again. This is not how it's supposed to work. You have to make one call to turn it off before updating your window work area and then you have to make one call to turn it back on after. That makes it two graf_mouse() calls. Not three, not four or whatever. Two. One off, one on. In pairs. Always. No exception. Never.

[exxos]

I've tried turning the mouse off all over the place.

That's your problem, right there. You are randomly and repeatedly turning the mouse off for no reason whatsoever and then suddenly turning it on again. This is not how it's supposed to work. You have to make one call to turn it off before updating your window work area and then you have to make one call to turn it back on after. That makes it two graf_mouse() calls. Not three, not four or whatever. Two. One off, one on. In pairs. Always. No exception. Never.

I'm not doing that! each one is REMed out if you look! only one is turning off the mouse at any one time, other than the one where I put it in a loop. Which like you say, wouldn't be a good idea, but I tried it anyway.

[Mikefulton]

Everything you're posting is full of shortcuts.

This subroutine will open a window, then without bothering to wait for a redraw message, it draws a bunch of stuff.

That drawing is done without bothering to do things like wind_update calls or walking the rectangle list.

After the drawing is done, then it closes the window. This will leave a dirty screen and generate redraw messages for whatever was underneath.

It's basically a random code fragment and It's not at all clear what your expectations are or how the code is failing to meet them.

Overall this doesn't seem like the whole thing should take more than a second to execute. Then it quits or leaves behind a dirty screen that something else will have to clean up. Since it's a subroutine, we don't know what happens before or after.

A proper test should open a window, wait for a redraw message, process it, then leave the window on screen so we can see what happened. Process WM_CLOSE messages to close the window.

[exxos]

Have you looked at the PRG I posted and ran it ? The hisoft manual says use its own window functions rather than using VDI/AES stuff, which I can do it that way if needs be but its re-inventing code which is already usable.

I'm am going to assume that yourself and jfl don't use hisoft basic ? as jfl totally missed the REMarks and you are suggesting things outside of hisoft built in functions now. Those test routines were copied over from GEMbench's original code I've hardly done any changes to them.

If I run this code, then I do not see a mouse pointer.

Code: Select all

id=wind_create(1,0,menuy,639,h1)
junk=wind_open(id,0,menuy,639,h1)
vr_recfl 0,wind_y,638,menuy+h1-1
junk=wind_close(id)
junk=wind_delete(id)

So again, when using the window open function it turns on the mouse and keeps it on regardless of if its actually turned off or not. Though while that code was in the GB4 source, it was rem'ed out in favour for the hisoft window calls. Though odd thing is, the mouse does not appear in GB4's code, but it does in mine.

I will have to check if hisoft has its own mouse off function somewhere, as its own window function seems to hard-wire the mouse on, GB4 still manages to turn it off somehow, so there much be some other mouse off method somewhere which I have not found yet.

[jfl]

I've tried turning the mouse off all over the place.

That's your problem, right there. You are randomly and repeatedly turning the mouse off for no reason whatsoever and then suddenly turning it on again. This is not how it's supposed to work. You have to make one call to turn it off before updating your window work area and then you have to make one call to turn it back on after. That makes it two graf_mouse() calls. Not three, not four or whatever. Two. One off, one on. In pairs. Always. No exception. Never.

I'm not doing that! each one is REMed out if you look! only one is turning off the mouse at any one time, other than the one where I put it in a loop. Which like you say, wouldn't be a good idea, but I tried it anyway.

OK, I had missed the " ' " in front of the graf_mouse calls. Sorry about that.

[exxos]

ahhh, there is actually a mouse function in hisoft that one works fine and its also how GB original code works.

mouse.jpg

What seems to have thrown me out was this while I was searching the code.

11.jpg

I had looked up "graf_mouse" and found I can turn it off with that function and I never considered that is actually the wrong way of doing it. The correct method is to use hisoft's mouse functions as I am using hisoft's window routines. What I was doing before was mixing the 2 "methods" which obviously doesn't work.

I don't know if "hidden from screen" means totally or just the program window. I don't have any multitasking stuff installed as I never use it. Though as the original GB source seems to have been coded with MINT in mind, then I assume it was never a issue and it only hides the mouse in its own window.

[Mikefulton]

Have you looked at the PRG I posted and ran it ? The hisoft manual says use its own window functions rather than using VDI/AES stuff, which I can do it that way if needs be but its re-inventing code which is already usable.

I'm am going to assume that yourself and jfl don't use hisoft basic ? as jfl totally missed the REMarks and you are suggesting things outside of hisoft built in functions now. Those test routines were copied over from GEMbench's original code I've hardly done any changes to them.

Looking at a compiled PRG isn't especially useful when you don't have the source code. Without the source code, there's no way to say if the program is doing what you'd expect or not.

I saw that the graf_mouse calls in question were commented out. That's why I didn't mention them. jfl and I aren't coordinating our responses, if that's what you thought.

I did use HISOFT BASIC back in the day. I had to be able to answer developer's questions about it. I had most of the more popular programming language/environments.

I didn't use it a lot, but certainly enough to be familiar with it. And I do have it on my STEEM setup. It allows you to call any VDI or AES function, so there's no reason to limit your code to the built-in functions. Creating a properly structured GEM program requires you to do things a certain way, and it really doesn't matter what language is being used.

If I run this code, then I do not see a mouse pointer.

Code: Select all

id=wind_create(1,0,menuy,639,h1)
junk=wind_open(id,0,menuy,639,h1)
vr_recfl 0,wind_y,638,menuy+h1-1
junk=wind_close(id)
junk=wind_delete(id)

As I said before, this is a code fragment that really makes no sense without a larger context. This is going to open a window, draw, close the window, and leave behind a dirty screen and/or some redraw messages. Furthermore, it's going to run in the blink of an eye. As to the mouse, there's no way to determine what's been done before or after this code, so therefore no way to tell if we should be seeing a mouse or not.

[Mikefulton]

ahhh, there is actually a mouse function in hisoft that one works fine and its also how GB original code works.

I had looked up "graf_mouse" and found I can turn it off with that function and I never considered that is actually the wrong way of doing it. The correct method is to use hisoft's mouse functions as I am using hisoft's window routines. What I was doing before was mixing the 2 "methods" which obviously doesn't work.

The MOUSE function in HSB is just a wrapper for graf_mouse(). It doesn't really matter which you use, or if you use both, so long as you do it right.

Also, graf_mouse() isn't tied to the current window or anything else. It keeps track of state, but otherwise is a wrapper for the VDI functions, using the screen workstation that belongs to AES.