It looks like it should but it doesn't.
If you look at the tlf_internal funct addMouseWheelListener it assigns the
listeners via
_container.addEventListener(MouseEvent.MOUSE_WHEEL,
getInteractionHandler().mouseWheelHandler);
however the getInteractionHandler method is simply
tlf_internal function getInteractionHandler():IInteractionEventHandler
{ return this; }
so its returning itself (any idea why it would have been implemented this
way?) and calling its internal handler and not the interactionHandlers. The
other interaction types do the same (MouseOver/Down/Up etc..) but in their
handler methods they then send the event to the interactionHandlers
matching handler function. The only one that doesn't is the
MouseWheelEvent, which is why I question its behavior as its strayed from
the others.
On Tue, Jan 7, 2014 at 2:04 AM, Alex Harui <aha...@adobe.com> wrote:
> Not sure I understand. I looked at ContainerController.as and it looks
> like it adds the interactionHandler's mouseWheelHandler, not some internal
> handler.
>
> -Alex
>
> On 1/6/14 1:37 AM, "Alessandro Palombaro" <alexpalomb...@gmail.com> wrote:
>
> >Hi,
> >
> >Does anyone know why the mouseWheelHandler function in
> >flashx.textLayout.container.ContainerController strays from all the other
> >event handler methods by not sending the event to interactionManagers
> >handlers?
> >
> >It looks like flashx.textLayout.edit.SelectionManager has the public
> >method
> >ready to go but there is nothing in it and it doesn't seem to ever get
> >called? Seems odd that the other interactions are sent by the controller
> >to
> >the textflows interactionManager instance, but the mouseWheelHandler is
> >handled direct within the controller.
> >
> >Thoughts?
>
>
