Mailing-List: contact dev-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flex.apache.org
MIME-Version: 1.0
From: jude <flexcapacitor@gmail.com>
Date: Tue, 25 Oct 2016 21:36:48 -0500
Message-ID: <CANcBHEAMeeOE4z+2QHP=GdiKcFxaU4kcoN8NkNoE3cXXHmcp9g@mail.gmail.com>
Subject: How to make InlineGraphicElements display a hand cursor
To: dev <dev@flex.apache.org>
Content-Type: multipart/alternative; boundary=001a1144617efec4cc053fbb80b7
archived-at: Wed, 26 Oct 2016 02:37:30 -0000

--001a1144617efec4cc053fbb80b7
Content-Type: text/plain; charset=UTF-8

I've been trying to figure out the TLF way to show a hand cursor on roll
over on InlineGraphicElement and it seems the FlowElementMouseEventManager
is preventing that with the _needsCtrlKey flag. This is set automatically
by ContainerController when in edit mode in line ~3200:

var needsCtrlKey:Boolean = (interactionManager != null &&
interactionManager.editingMode == EditingMode.READ_WRITE);

It looks like it wasn't meant to handle much else except LinkElements. So
I've been trying to come up with alternatives and maybe a long term
solution.

First, I tried to add an event mirror to the IGE to set the Mouse cursor
manually:

inlineGraphicElement = editManager.insertInlineGraphic(source, null, null,
options, operationState);
var eventMirror:IEventDispatcher =
inlineGraphicElement.tlf_internal::getEventMirror();

eventMirror.addEventListener(FlowElementMouseEvent.ROLL_OVER,
flowElementRollOver);

protected function flowElementRollOver(event:Event):void {
    Mouse.cursor = MouseCursor.BUTTON;
}

But the FlowElementMouseEventManager class dispatchFlowElementMouseEvent
method prevents roll over events from being dispatched unless the CTRL key
is down:

        tlf_internal function dispatchFlowElementMouseEvent(type:String,
originalEvent:MouseEvent):Boolean
        {
            // Mimick old behavior, and emit only rollOut events if Ctrl
key is not down
            if (_needsCtrlKey && !originalEvent.ctrlKey && type !=
FlowElementMouseEvent.ROLL_OUT)
                return false;

        }

I'm thinking maybe that a property on FlowElement such as
currentElement.interactiveInEditMode property. This would be false by
default but if true then the CTRL is not necessary. Then we can check that
and continue to dispatch all events. In the event listeners we would set
the Mouse.cursor how we like. This sort of feels hacky though as you'll see
from LinkElement. It places the cursor control outside of a FlowElement's
class.

Is it a bug that it's not dispatching events I've attached listeners too?
Should the CTRL key condition be removed? It seems like it's a work around
for link elements and it shouldn't affect non link elements.

The other approach is to mimic how LinkElement handles it.

        /** @private
         * The ElementMouseEventManager calls this method directly. Note
that the mouse
         * coordinates are unrelated to any coordinate in the container or
this element.
         */
        tlf_internal function
mouseOverHandler(mgr:FlowElementMouseEventManager, evt:MouseEvent):void
        {
            mgr.setHandCursor(true);
            setToState(evt.buttonDown ? LinkState.ACTIVE : LinkState.HOVER);
        }

But the code in FlowElementMouseEventManager is specific to LinkElement. It
checks if the element is of type LinkElement and if not it exits out. It's
not setup to handle generic element types.

I then thought if I can edit or extend FlowElementMouseEventManager to
handle generic types then we can extend InlineGraphicElement with the same
handlers as LinkElement. But IGE are created by ParaEdit class createImage
method that hard codes the instance class to an InlineGraphicElement.

Next I tried to access the FlowElementMouseEventManager instance to see if
I could extend it, assign my own but it's marked private in
ContainerController. So no other element types can set the Mouse cursor.

Should it be accessible in the textFlow like the interaction manager?
Anyway, any ideas appreciated.

--001a1144617efec4cc053fbb80b7--