I'm working with NetAdvantage for Win Client 2009 Vol. 1 - Windows Forms Source Code (Current Service Release Version 9.1.2056).

I have an UltraCalendarInfo object that is bound to a list of items.  The list is sorted, so when the StartDate of one of the items in the list changes, the item will change position in the list automatically.

At a high level, the problem that I'm seeing is that an Appointment doesn't update it's display based on a change to the list item it is bound.  I'm only seeing this problem when an item's index in the bound list changes (i.e. it is moved in the list), and then the item gets changed again in any way.

I've spent a lot of time looking into this and I believe I have found the problem in the Infragistics source code.

The root of the problem is in the handling of the ItemMoved event in DataBindingsBase.OnBindingListChanged.  Let's say there are only two items in the bound list, itemA (at index 0) and itemB (at index 1).  As expected they each start out having an Appointment that is bound to them, called apptA and apptB, respectively.  If changing itemB's start date causes it to move to index 0, then according to the code around line 390 in DataBindings.cs, the BindingListIndex of apptB will updated to 0.  This is good.  What's bad is that the BindingListIndex of apptA is still 0 and is never changed.  I would expect it would be updated to 1 since itemB switched positions with itemA in the list.  Now we're in a bad state where two Appointment objects have the same index.

Once the indices are out of synch and there are multiple Appointments with the same indices, the behavior in the handling of all subsequent ItemChanged events is unpredictable (from the perspective of the user).  For my little example above, if apptA happens to be before apptB in the Appointments list, apptA will be updated with the data from apptB and it will look like there are two apptB's in the UI.

The fix is to just add the code that updates the indices of the rest of the list based on which direction the item was moved.  I've attached my version of the file with the fix.

I have a couple questions on this issue:
1. Am I correct in thinking this is a defect? It seems a bound control should definitely be able to handle ItemMoved events.
2. If it is a defect, is there a workaround that would prevent me from having to rebuild the dll's?
2. If not, what's the easiest way to rebuild UltraWinSchedule and all the dll's it depends on? Does that BAT script that comes with the source code automatically build "signed" dll's? (because I need the dll's to be signed)

Thanks,
Tim Shawver