The way I look at it, if Hank Fay, looking at it closely and following what is going on there says "Hey, this will fly and is worth the money on spec" that carries a lot of weight. If everyone who bemoaned MS treatment of VFP would support those who are actually doing something about it, this thing would succeed both technically and from a business point of view (and like you, if they need to make more money doing this for the project to come to fruition I'd help working on that part of it)

Thanks for your contributions in making this more accessible and acting as a volunteer interface for developers who seem better at solving technical challenges than promoting what they are doing. (a welcome imbalance in the software world <s>)

>Hi John,
>
>I have no idea what their "nut" is that they need to make. But the stuff keeps getting produced, which is what counts. That's really their problem: if they tell me it's a problem, I'll work at finding a way to help them have more money. Until then, I'm very content to test the software, produce the occasional explanatory piece, and so forth. And if people support them with a measly $120 (and $120 is measly: the CLR Extender alone has already saved me more than that in time on one project).
>
>I am impressed by the maturity of vision as much as anything else. They are making it a growing language, even as they move to compatibility.
>
>My first reaction, to be sure, was "it's too good to be true." Then I saw it start taking shape. The proof is in the pudding, and the pudding keeps on arriving.
>
>Hank
>
>>>As for John's point that .Net is a moving target: I think that misses the point of the eTechnologia effort. What is built is CLS-compatibile, which means it can interoperate with any or all of .Net, without any special effort. Need to access Azure classes: no problem -- they can be accessed directly within your VFP code. So, as .Net moves, your VFP program compiled to .Net moves with it. Your access to it will be simplified, and you will be able to write VFP classes that encapsulate (wrap) this .Net functionality, so you can simplify your access to .Net functionality to what you need: that's the VFP way of things.
>>
>>It depends against which runtime they are producing their code. The 3.0 runtime is different than the 3.5 runtime. Much of the new functionality is built on the 3.5 runtime. If they are compiling their code against 3.0 or 2.0 then they will lose functionality.
>>
>>>
>>>Support from the VFP community is key. It's coming: there have been nearly 2,000 views of the little YouTube video I made of the first release of the VFP Developer Studio for .Net. The length (and energy) of this discussion is another good sign: VFP developers are taking the effort seriously, whatever they think or know about the product.
>>
>>
>>That's true, but I was one of the ones that viewed your demo. I have no intention of buying the product, I watched it merely out of curiosity. I'll bet there are a bunch of us that did that. But 2,000 developers paying 120.00 for the code will not put a dent in the "over-all cost bucket".