Flex API bug

I just ran into an issue that looks like a bug in the Flex API. The DragManager is used for dragging and dropping between flex components, and it can also be used to implement drag and drop quite easily in your own projects. It’s (mostly) well implemented and the syntax is straightforward. To start a drag, use DragManager.doDrag(dragInitiator, dragSource, mouseEvent). The details are explained in the documentation.

The bug I encountered is in the dragSource part of the call above – it’s an instance of  DragSource class, used to store data being dragged. You add data with myDragSourceInstance.addData(myData, “identifyingString”). Nice and sensible. The problem occurs when data is retrieved through myDragSourceInstance.dataForFormat(“identifyingString”). It returns Object as data can be of any type. Here’s the method from DragSource:

public function dataForFormat(format:String):Object
 var data:Object = dataHolder[format];
 if (data)
   return data;

 if (formatHandlers[format])
   return formatHandlers[format]();

 return null;

But if the data you added is numeric zero – 0 – the test if(data) will return false and the method will return null instead of numeric zero. Bummer! I suspect that if (data || data === 0) would be better.

The workaround I used was to set data as a string instead. As data return is untyped, we need to cast it anyhow.

What do you think? Has Adobe implemented the method correctly or is this a bona fide bug?


5 Responses to “Flex API bug”

  1. July 28, 2009 at 8:38 pm

    Sounds like you are passing single values. wouldn’t it be better to make use of valueobjects?

    And, can’t you just cast the returning value to an int?

    • July 29, 2009 at 5:28 am

      Value objects are good in some cases, but it seems unnecessary to create an object to store a single value.
      Yes – casting into int would be a good workaround, as long as it’s int. In this case the number could have decimals. The point is not so much how to work around it, but whether Adobes implementation needs to behave like this or whether it’s a bug.

  2. July 28, 2009 at 9:01 pm

    I’d call it a bug. I think they should simply check to see if the format exists:

    if( dataHolder.hasOwnProperty( format ) )
    return dataHolder[ format ];

    This should allow null values too, I think, but not undefined. Like with zero, I could see some potential use-cases for null, though not as common.

  3. July 29, 2009 at 5:45 am

    After posting, I found a situation where this really messes things up. If you compile an Air app, the NativeDragManager will handle all drags. It transfers the dragSource data into a Clipboard instance. Seems reasonable? But Clipboards setData method doesn’t allow parameters to be null at all. So if a value in dragSource was numeric zero, it will be ‘translated’ into null which causes an Error from Clipboard. To be fair – the documentation of Clipboard states that if you use a custom format string (which we are now), the values should be an object reference or clone. But dragSource does not say anything about that.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: