Hi Ken,

>While I'm all for nicely wrapped functionality explicitely mimicking VFP to accomplish it pays too much homage to a legacy I'm quite willing to leave behind. I want my developers to learn .NET (and in our case - C#), not just write "VFP code" and compile it differently :-).

Call me thick or something, but I just don't understand this mindset. Regardless of it's origin, isn't an additional set of functions a good thing to add to your toolbox? For example, the StrToFile function in the VFP .Net Toolkit takes a string and writes it to a text file, just like it does in VFP. What's the difference behind calling that function INSTEAD of executing the C#/VB.NET code behind it.

Another example is we've developed a number of functions in VB6 that correspond to a VFP counterpart. ALLTRIM() for example. Instead of

Dim MyString As String
MyString = " JIM ""
MyString = LTrim(RTrim(MyString))

we would rather use this line

MyString = AllTrim(MyString)

utilizing this function:

Function Alltrim(ByVal pcString As String)
Alltrim = LTrim(RTrim(pcString))
End Function

My take on this is that whether it's got roots in VFP or not, if I find a function library that works and provides functionality I need to get a job done or be more productive, I'm going to use it.

Just my two cents...