I'm developing a Flex 2 application, and I noticed that part of the library which is responsible for moving GUI windows (TitleWindows) around when you drag them with the mouse gets confused if there is a clickable (buttonMode = true) sprite beneath them. When I say confused, I mean that the window is moved around normally for a while, but then at some point "jumps" into the upper left corner of the flash app, and makes very minor movement there. Then at some other point it jumps back. It is more difficult to explain than to experience, so please go and see for yourself. Here's how to reproduce the problem:
Go to http://www.panocast.com
In the left sidebar, choose "Real Estate"
Just below the bottom right corner of the flash window, choose "high res" by clicking on the rightmost icon.
When (part of) the video loads, click on the staircase. A TitleWindow will pop up.
Try dragging it around the screen. When the mouse cursor is moved above one of the clickable areas (like the staircase), the window is misplaced.
(Sorry, but can't give you a direct link, part of the page is generated dynamically.)
(What's makes the problem even more interesting is that for me, in "low res" mode, the problem does not occur! There is very little difference between the various modes.) I would really appreciate if someone told me what was going on here and how it can be fixed.
I'm not sure if it matters, but the underlying sprite is actually not just plain sprite, rather it is a Papervision3D renderer object with some 3D elements in it. I'm telling this because it is possible that the incorrect mouse coordinates somehow come from the texture UV mapped on the clickable objects.
I've managed to replicate this on the low res mode as well, so I don't think it's related to the resolution.
This looks to be because the MouseEvent is being handled by the TitleWindow AND the Papervision3D window. Perhaps you need to force stopImmediatePropagation() on one or the other? Or maybe switch off the MouseEvent handling for the Pv3D window when the TitleWindow pops up?
That's a tough one to debug without some source; something's apparently calling either move() or setting x and y properties on that TitleWindow and scheduling it be moved.
When I first read the post, it "smelled" like maybe a rotation miscalculation somewhere (using Math.atan vs. Math.atan2 can sometimes have that kind of effect), so you're right, it could have something to do with PaperVision, assuming you're not using Math.atan or setting rotation properties yourself anywhere. Just thought I'd mention it, though it's probably not happening in your case. You never know, though. ;)
More likely the LayoutManager is moving the component in response to a property change on the component. The Flex docs explain that in addition to setting its x and y properties, and explicit calls to move(), a UIComponent's move event can also be triggered when any of the following other properties change:
minWidth
minHeight
maxWidth
maxHeight
explicitWidth
explicitHeight
PaperVision or no, maybe that info might help you isolate the source of the move. Good luck.
I got this figured out. Apparently, this is a Papervision3D problem. There is a class deep inside Papervision3D called VirtualMouse, which is supposed to generate MouseEvents programmatically. This happens, for example, when the user interacts with any of the interactive objects on stage, e.g., a Plane with an interactive material on it (as in my case).
The problem is that the x and y coordinates of the generated event represent texture UV coordinates (just as I suspected) and not real world screen coordinates. When a TitleWindow (or any Panel object) is dragged, a "mouseMove" handler (among others) is added to the SystemManager, which then uses the stageX and stageY properties of the event object to determine the new position of the window. Unfortunately for VirtualMouse's mouse events, these are invalid, since the original x,y coordinates, which are probably used to determine the global stage coordinates are, as I said, not screen coordinates.
Honestly, I'm still unsure whether the events dispatched by VirtualMouse are used anywhere within Papervision3D itself, or they are just offered for convenience, but they sure make it difficult to integrate a viewport into a Flex program. Assuming that such events aren't necessary for PV3D itself, there is a one-liner fix for my problem, which must be added right after the creation of the viewport:
viewport.interactiveSceneManager.virtualMouse.
disableEvent(MouseEvent.MOUSE_MOVE);
BTW., there was a very similar (or rather, as it turns out, the same) bug with dragging sliders, also fixed by this line.
Related
Given the following hypothetical function:
bowlingBall : Form -> Signal Element
bowlingBall shape =
makeMovable shape
How would one retrieve the absolute position of
bowlingBall greenFilledCircle?
I've noticed that when I debug a compiled page containing a drag-able element, chrome keeps track of the position under the property transform: matrix(...) - is this something we can tap into using elm functions, or does some interop need to be employed?
The short answer is that you can't do directly what you're asking for Elements. There's a pull request which would allow you to do this, but it hasn't been merged in yet.
There likewise isn't a good way of directly inspecting the position of a Form either.
I've run into a similar issue in the past and the way I've tackled it is to hold the position of my various items in my model and do all my position manipulations with regard to that position.
This isn't perfect; in particular the cumbersome conversion between the coordinate systems used by Mouse and the coordinate system used by Forms becomes much more annoying without this capability, especially if your Forms don't happen to inhabit a canvas at the upper-left corner of your window.
[qt 4.8]
To get correct window dimensions including its frame, I do the following (as described e.g. here, see comment from Daniel Hedberg).
mainWindow.move(-50000, -50000);
mainWindow.show();
// do something with the window dimensions
mainWindow.move(0, 0);
mainWindow.show()
This works fine, however, I have a problem with the move(0,0) call: It makes the window always appear at position (0,0), while I would like to have the default behaviour, this is, the application only suggests to the window manager that (0,0) is a good place to position the window, and the WM might decide to shift it if necessary to avoid overlapping. In other words, I would like to switch back to Qt's default behaviour as if there weren't a call to move at all.
How can I do that?
One solution is to store Windows original position and use that. For extra safety (in case screen resolution changes), check that entire window still fits on screen and move and even resize if it does not.
A hacky alternative would be to create and open empty, possibly transparent dummy window of the same size and see where it gets positioned. Then move the original there and close the dummy one. Reading your question carefully, I think this would do what you are after.
I don't know of a Qt way to ask Window Manager to reposition the window, so if you really need that, specify the OS etc details.
Looking into the source code of Qt, I can now partially answer my own question: To convert a call to move into a suggestion for positioning instead of a request, do this:
mainWindow.move(100, 100);
mainWindow.setAttribute(Qt::WA_Moved, false);
mainWindow.show();
I've tested the code under X11 using Qt 4.8.4, and hopefully it works with on other platforms too.
Unfortunately, this doesn't solve the very problem I have, namely to use show to get the (decorated) dimensions of an off-screen window which then gets moved to the screen, calling show again. It seems that the first call to show directly sets platform-specific window manager flags which aren't completely reset and reevaluated in the second call. Actually, I'm going to think that this is a bug in Qt, so I'll report it accordingly.
I have a problem with redrawing in flex 4. I have a spark titleWindow, and if i drag it faster, it looks like it's mask is one frame late after the component.
it's easily visible with 1pixel thin border, because it becomes invisible even with slower movement.
You can try it here (what is not my page, but it's easier to show you here than uploading example):
http://flexponential.com/2010/01/10/resizable-titlewindow-in-flex-4/
If you move in direction up, you see disappearing top border. in another directions it's not that sensitive as it has wide shadow, and it's not very visible on shadow.
On my computer i see it on every spark TitleWindow i have found on google, although it's much less visible with less contrast skins, without borders or with shadows.
Do you see it there? i had never this problem with halo components. It's doing the same thing with different skins. I tried to delete masks from skin, cache component, skin even an application as bitmap with no success.
I also turned on redraw regions in flash player, and it looks like it's one frame late after titlewindow too.
Does anyone know why is it doing this or how can i prevent it?
Thank you
UPDATE:
no answers? really?
I have been facing the same problem and I was really pissed that I couldn't find any answer.
The problem with me was, that I tried to center the component "component.x = (parent.width - component.width) / 2" and then draw that component programatically. The problem was, that component.x is a Number which can lead to floating values like 10.5 or similar. And it looks like that bitmapFill function rounds floats DIFFERENTLY than drawRect function, which makes exactly the 1px line around the objects (but ONLY when parent.width is an odd number). Strange thing for me was, that I only called the Draw function once, but still this line keep recurring ...
Doing Math.floor(component.x) solved the issue.
P.S.: I think that you can also help your issue by setting cacheAsbitmap=true on the dragged object ...
Cheers,
Jan Prazma
Sort of a complicated scenario - just curious if anyone else could come up with something:
I have a Text control and when I scroll it and stop the scroll with the cursor over some text that has a url, the cursor doesn't revert to a hand, and also flash player starts acting as if a selection is being made from the last cursor position. So IOW a bonafide bug in flash as far as I can determine.
The above probably wasn't completely clear so let me elaborate. If you grab a scrollbar thumb and start moving it up and down, you don't actually have to keep the mouse pointer on the thumb while doing so. When you stop the scroll, the mouse pointer could be outside the browser window, inside your flash application, but not currently on the scroll bar thumb, or wherever. The previously mentioned bug occurs when you stop the scroll with the mouse pointer positioned over text with an html anchor (a hyperlink). At that point the cursor enters into some state of limbo, and doesn't show the url hand pointer, and furthermore acts as if some text selection is taking place from the last cursor position prior to the scroll.
So the question would be, what sort of event could I simulate in code to jolt flash out of this erroneous state it is in. And furthermore in what event could I perform this simulated event (given that for example there is no AS3 event to signal the end of a scroll.)
To be clear, the Text control in question is on a canvas, and that canvas (call it A) is on another canvas which actually owns the scrollbar, and scrolling takes place by changing the scrollRect of canvas A.
I have run into this exact same problem with the TextArea in Flex 4: Scroll (textarea content is large than it's container) and release the mouse when over a link, and the cursor doesn't act right.
I think it's a bug, try submitting it to the Adobe Bug and Issue Management System. I will vote for it :).
Are you using Flex 3 or 4? If you're in Flex 4, I can make some suggestions. As a base, I would examine the TextArea and related source code in the Flex 3 SDK and figure out what events are being dispatched from links and whatnot. If you can eliminate the possibility that it's a Flash TextField (which TextArea uses), then it's a Flex bug. Try dispatching events that they're dispatching within the TextArea, from the things that are dispatching it (Event.CHANGE is all I can see taking a quick glance).
Good luck!
This is really in response to viatropos.
I was just able to duplicate the bug using the code example from the end of the Text documentation page in Flex 3.5 reference.
Just replace their htmlText in that example with a huge block of htmlText containing anchors tags (<a>...</a>). Then make the browser window small. Then click some arbitrary area of the htmlText with the mouse (That step is important.) Then scroll using the thumb. Stop the scroll with the cursor directly over one of the hyperlinks you created and release the mouse. The entire block of htmlText is selected and highlighted and the mouse pointer will not revert to a hand. (Well it will after you click somewhere else.)
As far as reporting this to adobe through their bug tracking system, I guess if I want to wait several months for it to be fixed. I reported another genuine bug over a year ago that was never fixed.
But examining their source code as you suggested - probably my best bet.
is it possible to use the startMove Method in AS3 and limit the movement only to the y-axis?
I want my window only to be dragable vertically.
Thank you for your tips.
I don't think that is possible, given that the actual movement of the window is done by the operating system alone (and I can't think of any application right now that restricts such a movement).
But maybe you can emulate such behaviour by encapsulating your actual application into a different window. You could then change the actual application size to the full screen and make it transparent and use startDrag to emulate the dragging of the inner window. Because with that function you can specify boundaries in which the movement is allowed.
I don't know if that will work as you would like it to, however.