I'm using a microsoft wireless mouse on my windows machine and the built-in touchpad mouse on the macbook pro.
I'll throw together a quick test app for comparison. If the problem still exists in the test app, I'll package it up as an FXP and AIR file and submit both with a bug report. Thanks! -Jake On Fri, Jun 29, 2012 at 12:47 PM, Alex Harui <[email protected]> wrote: > ** > > > Even if the target changed, the stageY should be continously increasing or > decreasing. > > What kind of mouse are you using? Do you have the same one for both > computers? > > I would try a real simple test app that just reports coordinates and see > if has the same problem. If it does, that would be the test case to file > with a bug report. > > -Alex > > > On 6/29/12 7:47 AM, "Jake Churchill" <[email protected]> wrote: > > > > > > > Alex, > > I ended up commenting out any code that checks against previous mouse > events y coordinates and compiled a new AIR file. I tested on my windows > desktop as well as my macbook pro and I get the same result on both. If I > move too quickly down, the y coordinates flip up top, then back down like > what I showed you in my traces. Of course, with a compiled version, I > can't stop execution to double check to see if the target is still the same > but I assume that wouldn't change between a debug and release compile. > > Any other ideas? Should I file a bug for this? > > Thanks! > > -Jake > > On Fri, Jun 29, 2012 at 1:38 AM, Alex Harui <[email protected]> wrote: > > > > > > > It is up to you. It would be annoying to code up a workaround when it is > just some device or driver on your computer. > > > > > On 6/28/12 4:04 PM, "Jake Churchill" <[email protected] < > http://[email protected]> > wrote: > > > > > > > This is an air app, so it's happening in adl. I can remove some checks > and compile a final release and test if you want. > > - Sent from my Google Nexus - > > On Jun 28, 2012 5:15 PM, "Alex Harui" <[email protected] < > http://[email protected]> > wrote: > > > > > > > Sorry, didn’t notice the StageY was changing as well. Does this happen on > other machines, browsers, etc? > > > On 6/28/12 2:21 PM, "Jake Churchill" <[email protected] < > http://[email protected]> <http://[email protected]> > wrote: > > > > > > > No, it always stays the same. Here's what I have, a custom annotation > called DrawingAnnotation which handles clicking, lines, etc. When a line > is added it's drawn on the chart, but all references are stored in the > annotation. For some reason I can't draw directly on the annotation. > > Anyway, the line has mouse events on it as well which allow it to be moved > and selected and stuff. When the line receives mouse down, I add an event > listener for mouse move to the system manager: > > systemManager.addEventListener( MouseEvent.MOUSE_MOVE, mouseMoveHandler ); > > which is where I am tracking the positions and stuff. I've added the the > listener to the line itselt, the annotation canvas, etc. Always the same > result. It always happens if I move the mouse too fast vertically. > > So, my workaround is to basically check the last mouse event against the > current and if the y changes by more than 100 pixes, I count it an outlier > and don't count that event. I'm sure there's a better workaround, but I'm > not sure since I pretty much have to rely on the position given to me in > the mouseEvent. > > Thanks! > > -Jake > > On Thu, Jun 28, 2012 at 1:34 PM, Alex Harui <[email protected] < > http://[email protected]> <http://[email protected]> > wrote: > > > > > > > Print the target as well. The target is likely changing and thus, the > coordinates local to that target. > > > > > On 6/28/12 10:11 AM, "Jake Churchill" <[email protected] < > http://[email protected]> <http://[email protected]> < > http://[email protected]> > wrote: > > > > > > > Guys and Gals, > > I'm working on a charting app where we draw things over the chart (trend > lines and stuff). The problem I'm running into is the mouse events are not > consistent. For example, I'll be drawing and the mouse events come through > with their Y position jumping up to the top, then back where it should be. > In the example below, local is localX, localY and stage is stageX, stageY. > In this example, I was dragging from somewhere in the middle basically > straight down (a little to the left). Notice the Y values freak out and go > way up to the top, then come back to where you'd expect them. This is > following a mouse move event. Any clue what might be causing this? > > Traced Mouse Positions: > > MouseEvent (local): (350,213) > MouseEvent (stage): (350,293) > > MouseEvent (local): (350,215) > MouseEvent (stage): (350,295) > > MouseEvent (local): (349,4) > MouseEvent (stage): (349,84) > > MouseEvent (local): (346,15) > MouseEvent (stage): (346,95) > > MouseEvent (local): (346,228) > MouseEvent (stage): (346,308) > > MouseEvent (local): (344,18) > MouseEvent (stage): (344,98) > > MouseEvent (local): (344,234) > MouseEvent (stage): (344,314) > > MouseEvent (local): (343,235) > MouseEvent (stage): (343,315) > > MouseEvent (local): (343,236) > MouseEvent (stage): (343,316) > > MouseEvent (local): (342,241) > MouseEvent (stage): (342,321) > > MouseEvent (local): (341,32) > MouseEvent (stage): (341,112) > > MouseEvent (local): (341,248) > MouseEvent (stage): (341,328) > > MouseEvent (local): (339,259) > MouseEvent (stage): (339,339) > > MouseEvent (local): (338,261) > MouseEvent (stage): (338,341) > > Thanks! > > -Jake > > > > > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > > >
