Processing 1.0 - Processing Discourse - Mouse not coordinates updated startup in 116

Ricard

Mouse not coordinates updated startup in 116
Sep 29^th, 2006, 5:14pm

Hi,

Just another small thing. Another issue that came up in the porting is the fact that the mouse coordinates are not correct at skecth startup, if the mouse is not moved.

This is due to the fact that mouse coordinates are only updated with mouseMoveEvents (which is fantastic!!).

But I think it is better to have an initialization update of the mouse coordinates only at startup.

thanks

fry YaBB Moderator Offline Posts: 2623 mass, usa	Re: Mouse not coordinates updated startup in 116 Reply #1 - Sep 29^th, 2006, 5:21pm not sure i follow.. what were you expecting it to do, and what did it do instead?

Ricard

Re: Mouse not coordinates updated startup in 116
Reply #2 - Sep 29^th, 2006, 5:32pm

In one of my sketches, the drawing is parametrized by the mouseX and mouseY values. But when the sketch starts and the mouse hasn't moved yet, these values are 0 and 0 (even if the mouse is somewhere else e.g. the middle of the screen). As soon as the mouse moves the variables take the values that they had to take.

What I want is that if the mouse is on the bottom right of the sketch window when the sketch starts, the mouseX=width and mouseY=height.

is it better?

fry

Re: Mouse not coordinates updated startup in 116
Reply #3 - Sep 29^th, 2006, 6:11pm

if i'm understanding you correctly, that's a java limitation. there is no inherent position of the mouse that's recognized by java, it's only picked up via mouse events. so if no events have fired, there's no way for the component to know what the location is.

with processing, we try to implement an inherent mouseX/mouseY position, however it's still limited by the user actually taking some kind of action within the frame.

however, this part of the mouse handling should not be changed since 0115, so are you talking about something else?

Ricard

Re: Mouse not coordinates updated startup in 116
Reply #4 - Sep 29^th, 2006, 7:18pm

Ok, so I must have been confused about how it worked. I thought before the mouseX and mouseY where polled by the processing core, every N ms, and now only updated when mouseMoved/mouseDragged events occurred.

Anyway the thing is that one of my sketches has changed behaviour of the mouseX/mouseY values.

Here is the example code:
Code:


void setup(){
  size(screen.width, screen.height);
  framerate(25);
  
  System.out.println("In setup() ...");
  System.out.println("mouseX = " + mouseX + "; mouseY = " + mouseY);
  System.out.println("In draw()...");
}

void draw(){
  System.out.println("mouseX = " + mouseX + "; mouseY = " + mouseY);
}

I run it in present mode.
And as soon as I click Present, I don't move the mouse. And after a small moment I press ESC.

the result in 115:
Code:


In setup() ...
mouseX = 0; mouseY = 0
In draw()...
mouseX = 0; mouseY = 0
mouseX = 592; mouseY = 80
mouseX = 592; mouseY = 80
mouseX = 592; mouseY = 80
mouseX = 592; mouseY = 80
mouseX = 592; mouseY = 80
mouseX = 592; mouseY = 80
...

the result in 116:
Code:


In setup() ...
mouseX = 0; mouseY = 0
In draw()...
mouseX = 0; mouseY = 0
mouseX = 0; mouseY = 0
mouseX = 0; mouseY = 0
mouseX = 0; mouseY = 0
mouseX = 0; mouseY = 0
...

In both cases the mouse wasn't moved.

NOTES:
1 - The sketch must have focus for this test to run.
2 - Be sure to change the framerate() to frameRate()

fry

Re: Mouse not coordinates updated startup in 116
Reply #5 - Sep 29^th, 2006, 10:04pm

right, there's no way to poll the mouse. since the polling model is more useful for lots of people, we fake it with processing, but perhaps too well if we've fooled people.

i think it also depends on your jvm. on the osx machine i'm using now, for instance, your test doesn't produce anything different whether in 0115 or 0116.

my guess is that on your machine, when present mode is used, a mouseEntered() event is fired, which updates the mouseX/Y in 115 and not 116. but this isn't the case for all platforms, which i'm guessing means that the spec is prolly vague or the implementation buggy across different machines.

also keep in mind the difference between the mouse coordinates when used in draw() versus in their respective mouseXxxx() handler functions. it may be the case that catching one or some of the mouseXxxx() methods might be what you'd need to do instead.

also, there's a boolean called "firstMouse" inside PApplet that will be set false until the mouse values are valid. this name is subject to change in future releases, but for the time being, you could use that if you don't want to switch to the event handlers.

davbol

Re: Mouse not coordinates updated startup in 116
Reply #6 - Sep 30^th, 2006, 1:40am

fry wrote on Sep 29^th, 2006, 10:04pm:

boolean called "firstMouse" .. this name is subject to change

FWIW: If/when it changes, might I suggest you continue along the "nounVerbed" nomenclature a la keyPressed and mousePressed, perhaps using something like mouseAcquired or mouseFocused or mouseCaptured or something similar. (mouseHasBeenGotted :-D) Such a name would also have the nice side benefit of keeping all mouse-related members together alphabetically in the docs.

fry

Re: Mouse not coordinates updated startup in 116
Reply #7 - Sep 30^th, 2006, 6:57pm

davbol wrote on Sep 30^th, 2006, 1:40am:

FWIW: If/when it changes, might I suggest you continue along the "nounVerbed" nomenclature a la keyPressed and mousePressed, perhaps using something like mouseAcquired or mouseFocused or mouseCaptured or something similar. (mouseHasBeenGotted :-D) Such a name would also have the nice side benefit of keeping all mouse-related members together alphabetically in the docs.

yep, that's why it's subject to change, that it's a variable being used internally that i haven't worked out the proper name for it. maybe we can shorten mouseHasBeenGotted to just mouseGotted Wink