cash_pat posted on Monday, July 31, 2006
I am currently in the state of porting my 1.53 code to 2.03. there are are over a 500 places where lookups are used (very similar) with the same code. In 1.53 I used the following technique
SetLookupProperties(lkpSuppliers, STR_LedgerID, STR_LedgerName, mSupplierList)
SetLookupProperties(lkpStockName, STR_StockNameID, STR_StockName, mStockNames)
SetLookupProperties(lkpColour, STR_ColourID, STR_ColourName, mColours)
SetLookupProperties
(lkpVAT, STR_LedgerID, STR_LedgerName, mSaleRates)
This 1st parameter is the lookupcontrol.
The 2nd parameter is the ID Column
The 3rd Parameter is the Display Column
The 4th Parameter is the BO
The SetLookupProprities then created appropriate columns, set some common proprities, and associated it with the datasource. But now with the case of generics I am unable to do so.
Do i have to use the same code to initialize all my lookups around 40 lines at 500 places. Can I do it without losing the power of generics and performance
regards
cash_pat
RockfordLhotka replied on Monday, July 31, 2006
You are stuck in a hard place.
The reason you could do that in 1.53 was because the types of the name/value pairs were constant.
The reason you can't do it in 2.0 is because the types of the name/value pairs are not constant - thanks to generics.
So NameValueListBase is more flexible, but less flexible, all at once...
What you might want to do is create your own non-generic NameValueListBase and then derive your actual NVL objects from your single-typed base. You can do this by inheriting from NVLB:
<Serializable()> _
Public Class MyNewBase
Inherits Csla.NameValueListBase(Of String, String)
End Class
<Serializable()> _
Public Class MyActualList
Inherits MyNewBase
' implement factory and DP_Fetch
End Class
This creates a strongly typed base class where the types are actually known. Of course this means you give up the type flexibility of the generic base, but you gain polymorphic behavior at the MyNewBase level.
