Alex, I think I have figured out what is causing the mouse disruption. I have a background element where I display the symbol and the symbol description. Whenever I rollover that, it makes the mouse event's position freak out. If I set mouseChildren="false" on the background elements, it fixes the problem. If I add mouseChildren="false" to the chart, disables my mouse hover events on the annotation which I can't have.
In my opinion, this is still a bug. I do not see why elements in the "backgroundElements" property would have mouse events on them in the first place. Let me know if you want me to file a bug. I have a sample project put together to illustrate this. Also, could you please tell me why I can't add children directly to the CartesianDataCanvas? It seems like that's where drawing should go. Please let me know about filing a bug for the background elements issue I described above. I attached my flex project file to this email in case you are interested in seeing what I'm seeing. The app loads with a chart and one line and a background element. Click anywhere to start drawing, click again to complete the line. Grab one end of the line and mouse down and move it around. When you run over the background element, it goes crazy. Thanks! -Jake On Fri, Jun 29, 2012 at 12:49 PM, Jake Churchill <reyna...@gmail.com> wrote: > 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 <aha...@adobe.com> 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" <reyna...@gmail.com> 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 <aha...@adobe.com> 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" <reyna...@gmail.com < >> http://reyna...@gmail.com> > 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" <aha...@adobe.com < >> http://aha...@adobe.com> > 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" <reyna...@gmail.com < >> http://reyna...@gmail.com> <http://reyna...@gmail.com> > 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 <aha...@adobe.com < >> http://aha...@adobe.com> <http://aha...@adobe.com> > 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" <reyna...@gmail.com < >> http://reyna...@gmail.com> <http://reyna...@gmail.com> < >> http://reyna...@gmail.com> > 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 >> >> >> > >
