Posts Tagged ‘drag-and-drop’

Using new functionality drag and drop with 4D list boxes?

Watch out for this: only the entire listbox object can be made draggable/droppable from the actions pane of the object properties.

Even though a listbox is made of headers and column rows, a drag from cells to the header will show as invalid at the UI level. If the user tries to drop it on a header 4D will still go into the list box object method On drop form event.

Moving the on drop code to the columns object method inside the list box has no effect. Dropping a cell onto a header still throws the On drop event.

OK is of no help either, it is 1 regardless of drop target. If Drop position returns -1 seems to be the only indicator a header row was dropped on. A 0 indicates dropping the cell beyond the populated values.

Either way it is frustrating to program around. How about a Get current target method, or change drag and drop properties function call. To state that the current object method executing is the drop target is clearly not granular enough to differentiate from data rows and header rows.

I should also note that returning -1 from On Drag Over event prevents any code from executing On Drop and displays the invalid drop target icon.

` old way
DRAG AND DROP PROPERTIES ( srcObject ; srcElement ; srcProcess )
` new way
DRAG AND DROP PROPERTIES ( srcObject ; srcElement ; srcProcess ; tarObject ; tarElement ; tarProcess )

Read Full Post »


I put this at the top because I wanted to change the content of the below post. Having worked on this code for a few days now, I became aware of several short-falls in my assumptions.

1) You cannot extend skins. Which makes sense, a host component can have many skins which have many states. Extending a skin would add confusion as to where the states are defined for that “look and feel”.

2) Enabling drag and drop (while a UI interface function) on custom components through their skins is asking to violate the DRY principle. Even though the skin is now the top most layer of the <code>DragEvent</code> having different skins breaks this model.

Unfortunately the drag and drop examples from adobe for flex 4 still show mx components, but the differences page seems to lean towards putting drag and drop functionality in the spark component, not the skin class for the spark component.


Another upgrade bit of confusion that has since been squared away.

In the original application, mx:Panels were dragged around on a mx:Canvas; something similar to the Adobe Documentation examples

Both of these files were getting quite large as they handled look and feel, interaction of the components, and all data. Now with flex 4.0, one priority was to convert these two custom components to s:SkinnableContainer with respective s:Skin classes.

This has cut our file sizes 20-50 percent as we try to follow a more MVC architecture. However our drag-and-drop functionality ceased to work for these custom components.

Long story short, drag events were now showing the s:Skin class as the dragInitiator for a DragEvent instead of the (in my mind) expected host component of the skin.

This make sense from the point that the added skin is now the ‘top-most’ layer of the component, but the question of where to put the custom drag management code naturally presented itself.

Does it belong in the base “data” class (Component), or does it belong in the “skin” class (ComponentSkin). Adding to the confusion is that both classes accept dragEnter and dragDrop events (in addition to all other DragEvents.

Knowing that the outmost layer of the component is the skin, and attempting to adhere to the MVC architecture, the decision is made to include all drag (ie visual) effects in the s:Skin class.

Three links that helped me with this endeavor:
saturnboy drag-and-drop
evtimmy drag-and-drop skinning
From above:
Adobe drag and drop examples

Read Full Post »

%d bloggers like this: