With the exception of "the inevitable", I agree on all points. Viability into the future is a big issue. We'll see what they do about that. I think there are ways of addressing that. And if they don't address that issue, then we won't be discussing VFP.Net much longer. If they are able to address is successfully, I think there's a fair chance of there being a very decent alternative, with VFP's strengths, to the statically typed languages in .Net, that will gives seamless access to .Net resources, and produce assemblies that are good .Net citizens.

>Really?
>
>I think all this does push the inevitable just a little more into the future.
>
>I think you'd have one hell of a hard time selling VFP.NET into any even medium sized organization when you're dealing with a very complicated black box implementation provided by a tiny company. While tiny doesn't need to mean bad, it's big problem when you have a closed source solution of this kind that serves as an entire architecture. Compiler design is very difficult and very difficult to support once out and there are problems. From what I've seen of the company so far I'm not sure they are up to deal with the issues that are likely to arise of supporting a full platform of this scale...
>
>I wish them luck, but I don't see this lasting long unless they do it for the love it and not for a profit because this market is on life support and not likely to yield a payback on investment.
>
>+++ Rick ---
>
>
>>I agree about the VFP developers not having a general interest. There are ISV's with applications for which they can save a huge amount of effort by using the product, and those will be a natural. There are probably a few hundred of those in the world. And you are right, the viral campaign is aimed at non-VFP developers, at all levels.
>>
>>And, of course, you don't give up .Net when using the product; you just have a easier, more flexible way of using the .Net resources.
>>
>>>>I've actually heard from the lead developer in mid-December, but his prediction of a release the next week did not come true. I'm not sure what the hangup is: the major pieces to be implemented are down to the grid and rushmore (the latter being the key to making SQL Select work effectively against DBF's, including their new 64-bit dbf's). The other functionality is pretty much all there, including cursoradapters (at least the class is there, and supposedly they work for some scenarios). It would be a real shame if they were to fail this close to the finish line. That's the main point that gives me hope: they are this close. In addition, they have a dynamite marketing plan that will ensure they become known to all sorts of non-VFP developers, and it's something they have a capacity right now to carry out, without additional resources.
>>>>
>>>>Hank
>>>
>>>A dynamite marketing plan?
>>>
>>>They'll have to ensure they are known by all sorts of non-VFP developers since they've missed that opportunity (to market to VFP developers) pretty much completely by now. Then they'll have to convince non-VFP developers that there is some reason to use their VFP syntax rather than the incredibly broad and powerful .NET framework that has been building for almost a decade.
>>>
>>>I assume the VFP compiler isn't their day job since they have no communications or marketing to speak of, and since their progress seems to be extremely slow. I think they'll be able to count paying users on their fingertips if it is released.
>>>
>>>BTW I was excited about it a couple of years ago. I really was.
>>>
>>>
>>>>
>>>>>>So far as I know, the VFP Compiler for .Net runs on Mono now; or at least it did as of last Spring (at which time I believe it was actually being developed on Mono).
>>>>>>
>>>>>>As for whether it will be completed: who knows? Do you have information on this issue?
>>>>>
>>>>>No information is coming from the people behind the VFP Compiler for .Net for a long time. That's one of the reasons I think it's not going to be complete anywhere soon