John,

>>
>Doesn't VB need to have its variables all pre-defined or does variant work sufficiently close enough to VFP's ..ehrrr.. 'relaxed' <g> approach to variable management to make it possible? I'm thinking that macro substitution would make VB choke a little. Perhaps not as I'm not that familiar with the product...
>>
>
>Macro substitution would be a no-go in .Net. But, there are other alternatives. As for variable types, variants are represented as object types. With some of the pseudo-strong typing that VFP 7 has, migrating code to VB .Net is probably very "doable"...

Well, if there are viable alternatives then that removes something from the notion of sticking with VFP I'd suppose.

Migrating VFP to .NET doesn't seem worth the trouble IMO as long as we can participate at some point, which I believe is very doable. I think the general consensus is that we'd give up too much to get there and at the end of the day there would really be not much to differentiate VFP from VB.NET or whatever. I suspect that this self-exclusion does indicate either a prescient choice should .NET flop or the eventual sidelining of the whole DBF-based approach. Still, I think there's a good deal of time before this all works out.

>
>
>>
>I think that there are some UI features I'd like to see from VB into VFP and some of the low level stuff as well.
>>
>
>How much low level stuff would you want? VB .Net is capable of free-threading. The whole apartment-model threading stuff is gone. My guess is that VB .Net would probably be sufficient for most business applications.

More than liely. As long as we can instantiate some DLL and invoke its methods to do what we need I'd think you're correct on this.

THanks..