D5.1: Workarounds for two strange TreeView quirks

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

D5.1: Workarounds for two strange TreeView quirks

Maxim Fridental
1. When you are using TreeView, sometimes the Dictionary handleObjectMap
gets out of sync with the Windows tree view control. Thus, there may be
times where aTreeView hasSelection is true but aTreeView selection is nil.
The next time you send #selection you get a non-nil object. We weren't able
to find the root of the problem and a proper solution. We use the following
workaround:
TreeView>>selectedCount

"Answer the total number of items selected in the receiver."

| selectionHandle |

^((selectionHandle := self selectionByIndex) isNull

or: [(handleObjectMap includesKey: selectionHandle) not]) ifTrue: [0]
ifFalse: [1]



2. The method IconicListAbstract>>requestDragObjects: uses "self selection"
as a reasonable suggestion for the dragee. But normally you want to drag the
item you picked rather than the item you selected. While there seems to be
no difference between the two in a ListView, in a TreeView you can select
one item, then pick another item, drag and drop it, and get the selected
item from DragDropSession>>dragObjects, but not the picked item! We suggest
the following solution, that as we think fits all cases:



requestDragObjects: session

"This is where the receiver specifies which object(s) the <DragDropSession>,
session,

is to drag.The objects are added to the session using
DragDropSession>>addDragObject:

or DragDropSession>>dragObjects:

Implementation Note: Override to make a reasonable suggestion (the current
selection)."

self hasSelection ifTrue: [session addDragee: session suggestedSource ].

"But let any observers override with their own suggestion"

super requestDragObjects: session