Technically, any widget is capable of drag and drop, although some types of widgets are better suited than others. Drag and drop works best on container style extended widgets such as EwIconArea, EwIconList, EwFlowedIconList, EwIconTree, EwTableList, and EwTableTree. On these widgets, the sourceItems, targetItem, and itemUnderCursor fields in the various callData always contain actual items from the source and target container. Furthermore, these container widgets assume that if dragging starts on one of the selected items, then all of the selected items are dragged. They also assume that if dragging starts on a non-selected item, then only that item is dragged.

Drag and drop for the other list-oriented widgets such as CwList and CwComboBox carries some limitations. First, the sourceItems, targetItem, and itemUnderCursor fields in the various callData only ever contain strings when the callbacks are triggered. However, the application can override these values in the callback handlers. Also, because these widgets do not provide any way to determine which items are under the cursor, they always assume that, regardless of where a drag actually starts, all selected items are dragged. Drag and drop on these widgets is further limited by the fact that they cannot show insertion or target emphasis. This implies that it is not possible to inform users where items will be inserted if they are dropped on one of these widgets.

Drag and drop to and from non-list-oriented widgets is more severely limited. Because there are no commonly accepted semantics for drag and drop on labels, buttons, forms, or other non-list-oriented widgets, the application must define what is meant, for example, by dragging from a CwLabel to a CwToggleButton. Also, the sourceItems, targetItem, and itemUnderCursor fields in the various callData are always left nil.