Q: Loading (and deleting) the control seems a bit slow?

Adding Items

SftTree/OCX can easily handle tens of thousands of items.  The initial overhead of loading the data into the tree control may appear a bit slow.  This is easily resolved by correct use of the control's BulkUpdate property.  By setting BulkUpdate to True, then adding all items, followed by setting BulkUpdate back to False, the control can save considerable processing time, resulting in a much faster load time.  By using BulkUpdate, the control can skip internal processing for each item and postpone it until after all items have been loaded and process them "in bulk".  Performance improvements are significant and the load time becomes much faster (10 times or more). 

Of course, BulkUpdate cannot improve the performance of the data source.  If you retrieve the data from a database for example, the overhead of retrieving the data cannot be reduced.

Example:

    With SftTree1
        .BulkUpdate = True
        For i = 1 To 100000
            .Items.Add "Hello" & i
        Next
        .BulkUpdate = False
    End With

It is important to note that BulkUpdate should be set and reset only once for all items.  If BulkUpdate is set and reset for each record, no performance improvement can be obtained.

Removing Items

Deleting items is always very fast if the Clear method is used. 

    With SftTree1
        .BulkUpdate = True
        .Clear
        .BulkUpdate = False
    End With

If items are deleted one by one using the Remove method, a somewhat slower performance is to be expected (but again, make sure to use BulkUpdate).

An application may accidentally slow things down by using the ItemDeleted event.  When using the Clear or Remove methods, the ItemDeleted event is called for each item being deleted.  Depending on the amount of processing performed in the application's ItemDeleted event, performance may be negatively affected.  Placing Debug statements to trace processing also may slow things down quite a bit.

Using a Debugger

Performance can be negatively affected when running with a debugger active. Particularly, under Visual Studio .NET, an application with ActiveX controls can be significantly slower than when the application is running stand-alone (even if it is a DEBUG build). To gauge an application's true performance, always test Release builds without a debugger active.