Add event name constants to FlowElementMouseEvent?

Question

I realize that the LinkElement will, in most cases, dispatch up to six different events, which use the same event name constants as defined in MouseEvent:

    * MouseEvent.CLICK
    * MouseEvent.MOUSE_DOWN
    * MouseEvent.MOUSE_OUT
    * MouseEvent.MOUSE_UP
    * MouseEvent.ROLL_OVER
    * MouseEvent.ROLL_OUT

In the Flex IDE, the event metadata is being interpreted and causes incorrect Eclipse code-hinting since the event names don't exist as constants in all-caps/underscore form in the FlowElementMouseEvent.

For example, if I have a link element instance, and type 'linkElement.addEventListener(', after I type the left paren, it triggers code completion that presents me with the following list of possible event types to add listeners for these six event types:

    * FlowElementMouseEvent.CLICK
     * FlowElementMouseEvent.MOUSE_DOWN
     * FlowElementMouseEvent.MOUSE_OUT
     * FlowElementMouseEvent.MOUSE_UP
     * FlowElementMouseEvent.ROLL_OVER
     * FlowElementMouseEvent.ROLL_OUT

Obviously, usage of any of those will not compile. I know you're using the same strings from MouseEvent's event name constants,

but it sure would be nice if you could add those event strings as constants to FlowElementMouseEvent as well! It's confusing to some developers when that doesn't work like they expect.

Thanks!

Brent

rdermer · Accepted Answer

I filed a bug on the name constants.Richard

Anonymous · Answer

On another note, it's also really annoying that we get the ever-so-useful arg0, arg1, arg2 code hints for method arguments when working with TLF classes, instead of those that are indicated in the documentation. It's obviously for obfuscation reasons. Would be nice if you could either obfuscate without changing the names of the method args, or update the documentation so that the argument names in the documentation match those in the SWC's provided. All of the extra time required to flip over to the ASDocs and then match up the argN params with the appropriate documented method params really adds up over time if you are doing a lot of TLF development. Also, the most annoying thing about this is when you extend a TLF class and then override a method. In FlexBuilder, it will autocomplete the overridden method signature, including the ever-so-helpful argN param names. Same case for implementing TLF interfaces. In FlexBuilder, when it creates a new class that implements a TLF interface, it autocreates the methods and they all have the argN method args.... Sorry, this is just a major point of frustration for us...

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded