You understood me exactly. So, let's see if I understand your feelings. If you had a set of functions that did what the toolkit does, but in a possibly different way that you feel is more .NET like (different function names, parameters named differently, maybe in a different order), you'd use it. Do I have that right?

Well - I think that is partially true, but an oversimplification.

First - we will build our own framework and function libraries. We did it with VFP - we will do it with .NET. Commercial frameworks and general purpose toolkits are usually too bloated with functionality we do not need. This may be characteristic of the fact that we are building vertical apps as opposed to being a "custom software shop" with a wide variety of application types.

Secondly - notwithstanding the above, and as we did with VFP, we will borrow, learn from, or use what we can from other sources as part of our framework where it makes sense to our design and goals. This would include the VFP toolkit from which, at the very least, I anticipate being able to learn a lot.

As far as the toolkit itself goes - I see no reason to limit myself to VFP syntax or functionality which often, IMO, has confusing names, goofy parameter orders, inconsistent return values, etc. Sure, I can rename, enhance, strip and add, re-parameterize, etc. - ALL of which I've said I will do, but my point is that when I do that, I no longer have the "VFP Toolkit" - I have something else.

Thanks,