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.
Related
I am using Fullcalendar timeGridWeek side by side with dayGrid.
I can drag between the two and resize or drag in the timeGridWeek (the one on the left).
However, the problem is functionality is broken after hour 6PM or towards the end of the day, depending on the screen width.
I've also enabled clicking on time slot. I can click until 13:00. Anything after that stops working.
If I set the #container > * element to 1600px (on my ultrawide display) everything works correctly.
I can't figure out why.
I also have this running in a React App with MaterialUI and it behaves in the same way. I presumed it was something to do with the theme, but now can see it does the same thing with minimal styling.
Codepen: https://codepen.io/anon/pen/exabpW?editors=0010
This might come from the businessHours option, at pair with the eventConstraint: 'businessHours' option, which, if both are set together, disallow dragging and moving outside businessHours.
So the way to patch it would be to remove the eventConstraint option if u placed it, or change your businessHours
Apparently it's a confirmed bug: references here
https://github.com/fullcalendar/fullcalendar/issues/4503
and here
https://github.com/fullcalendar/fullcalendar/issues/4505
I have a form inside an Angular Material Dialog component. My problem is that when an input field gets focus, the keyboard opening in mobile devices covers the input field the user wants to write into.
When the keyboard opens the main body of the HTML gets az appropriate margin-bottom, however, this does not apply to the dialog's wrapper (cdk-overlay-container), since it's position is fixed.
My ideas:
1, Changing from fixed to absolute could solve my problem, however since my main container is a huge scroll-container, that would only work if I scroll to the top programmatically, which I don't really like.
2, If I could detect that a keyboard was opened, I could add a class to a parent container, however, I'm not sure how to do this without attaching an event to every input field we have, which feels ugly and unnecessarily heavy (since I'd have to send events to notify other components). I would also need to know the size of the keyboard, which I'm not sure is possible.
The issue occurs on both Android and iOS.
The slider thumbs in my Flex 3 application usually work correctly, but often they seem to become insensitive to mouse downs on what should be thumbPress events.
It turns out that mouseOut events are being fired as the mouse moves away from the edge of the thumb towards the center. The thumb is sensitive to mouseDown events only when it is in the "over" state.
I am seeing the same behavior:
-- Displaying the default thumb rather than my custom class
-- Using a hitArea sprite (I tried a child TextInput sized to cover the thumb with alpha 0).
Can anyone suggest either a fix or a workaround? I can identify the faulty mouse out events, but then don't know how to compensate, for example, by reestablishing the "over" state, or perhaps with programmatic control of the mouse.
Thanks,
Peter
Nevermind, I figured this out myself. The mouse-out events are due to mostly invisible objects in the way -- the result of a workaround from long ago that I forgot about! :-(
I'm building an application in Flex and I have few windows with scroll. When I'm trying to use mouse scrollwheel the window does not scroll up/down. Plus if it is possible to make the window to scroll up/down then is it possible to make to scroll right/left.
in as3 there is a mouseevent.mouse_wheel event. Listening for this will yield property delta. the delta property wil tell you if your mousewheel is scrolling up or down. unfortunately this doesnt work with macs. Fortunately, there are some classes out there [internet land] that address this.
re the second bit, side to side, i imagine you could harness an up/down motion to move a scroller left/right, but i dont think thats what your after.
Correct.
This guy made it possible. Some examples and explaination: http://blog.pixelbreaker.com/flash/as30-mousewheel-on-mac-os-x/
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.