Yeah, I'm not sure they can use the name anyway. "Visual Data Developer Studio for .Net with VFP Compatibility" would be both ungainly and accurate. <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.
>>
>
>What they have accomplished so far is nothing short of amazing, that's for sure. You CAN compile relatively complex VFP apps to .NET and run them as .NET apps right now. Done it myself many times already. Once the web app development gears stop grinding and start moving smoothly, I will have a few commercial web -based applications on the loading dock in no time at all. Can't wait...
>
>The problem that I see with the development process is the "network effect" of new doors that they keep opening. Each new door seems to lead into 5 other new doors, each of which leads to yet another 5 and so forth. Staying focused in the middle of this huge playground is very difficult, I imagine. A capable and methodological project manager would be a welcome addition to this project right about now, because otherwise they may end up spreading their development efforts out way too thin.
>
>As for the naming -- and this comes strongly into play with marketing -- I believe "VFP" should be dropped alltogether. Too much emotional baggage there. "Strong backward compatibility to Microsoft's highly data aware VFP application development platform" could be named as just one of the many, many benefits of this new product. Given .NET's still unnecessarily complex databinding methodologies (at least compared to VFP) and the lack of easy record -oriented data access options, I think that the incredible ease of data aware application development should be highlighted above anything else.
>
>Pertti
>
>>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".