Understood what's happening, and here is an example of how to reproduce that.
Open a new VB project, and add an instance of iGrid 4.7 to the form. Then the v5.0, and add the following code to test whether CustomSort works. It may be something like that:
Private Sub Form_Load()
With iGrid470
.ColCount = 1
.RowCount = 3
.ColSortType(1) = igSortCustom
End With
With iGrid500
.ColCount = 1
.RowCount = 3
.ColSortType(1) = igSortCustom
End With
End Sub
Private Sub iGrid470_CustomSort(...)
Debug.Print "iGrid470_CustomSort", lRow1, lRow2
End Sub
Private Sub iGrid500_CustomSort(...)
Debug.Print "iGrid500_CustomSort", lRow1, lRow2
End Sub
Now the question: do you really set the 1st column to be custom-sorted in both cases? The answer is "no".
The fact is that the contents of the ESortTypes enum were changed in the v5.0, and its igSortCustom item used to specify custom sorting changed its equivalent numeric value. It was 15 in the v4.7, but now it is 98 in the v5.0. In fact, we use an improper value in either case as VB searches the igSortCustom constant in the same type library (in either iGrid OCX). It is either 15 for both cases, or 98 - and thus only one of the grids will use proper sorting.
If we want to avoid any ambiguity, we should use the type lib name prefix in the setup code:
Private Sub Form_Load()
With iGrid470
.ColCount = 1
.RowCount = 3
.ColSortType(1) = iGrid470_10Tec.igSortCustom
End With
With iGrid500
.ColCount = 1
.RowCount = 3
.ColSortType(1) = iGrid500_10Tec.igSortCustom
End With
End Sub