I just discovered two issues with the collision form:



1. If the field were the collision occurs is a large text field, there is no way to resize the form or the height of the rows (that I could figure out) to see all the data, thus allowing the user to be able to resolve the collision.



2. If the field is a string, but actually formatted source for something like RTF or HTML, it isn't readable. I.e. if the data is bound to the RTF property of the SF Richtextbox, the RTF is shown (I haven't tested this, I'm using TxTextControl and my data is HTML). Again the user can't (easily) resolve the collision.



I'd suggest the following:



1. Make the form sizable and the rows sizable.



2. This one's hard, as all the collision form knows is that it is a string (or a binary) and has no way to know from the datatype that is needs some specific treatment. Maybe an attribute could be added to the fields in the BO (ideally by checking a box in the BO Mapper) to indicate that the collision form needs handle it differently? If the attribute is set, the collision form would just display buttons or links that would raise an event that the application could handle? The eventargs would provide the name of the field and the data, maybe the name of the BO too, so the user could handle it appropriately.



Since the purpose of the collision form is to handle collisions, both of these are significant, though #2 might be very hard to fix.



Of course, maybe SF already handles both of these and I just don't know about it...that would be cool