Groetjes Walter,

>>Well. The UI often is limited by the programmer itself. Programmers are not UI designers but often they try to. I'm not sure what kind of GUI you want but ActiveX plugins can provide what you need. I've seen many poor UIs but seldom they were the result of limitation of the language but rather the lack of creativity of the programmer/Designer. In itself I've got no problems with the VFP GUI.

>I want "native" UI features ... like in .NET.

I agree you have more native UI components in .NET but you can´t solve all GUI issues with that.

>I want simple product distribution ... like "XCOPY" in .NET.

I don´t think this will work. You still need to install numerous DLLs if you want to make use of third party tools like CR, ODBC drivers etc. .NET does not solve the dll hell.

>I don't want any part of "DLL Hell" (ActiveX). I refuse to use ActiveX; I hand-craft all my UI components in VFP .... but it takes too long ... unlike Delphi, .NET, etc.

I´ve developed quite a few VFP based applications with external DLL components and as far as I can see you can limit the DLL hell by just using standard Windows components and using add ons from well established vendors like seagate (Crystal Reports). I´ve only ones has a DLL problem where a client had part of CR 8.0 installed while my application install version 7.0 as a result part of the DLLs were version 8 and part were version 7. I´m certainly NOT convinced you can avoid this by using .NET.

BTW the DLL is greatly reduced by using OSs like W2K and XP. Also the installers like installshield Express that comes with VFP helps a great deal in avoiding DLL version conflict issues. The DLL hell was really a problem in the pre W2K days when distributing you applications with the standard VFP installer. There was no versionchecking and you could not replace DLLs that were in use. There has been changed a lot since those days.

>I can do it in VFP; I have a Grid based TreeView that works dandy.

I can´t see the benefit of that. The windows Treeview is a stable control and I see very little reason to rebuild it in VFP.

>I've built FLLs that integrate a Virtual Reality engine into my app ... but if I had been using C or VB or Delphi I wouldn't have had to spend x hours to write the FLL.

>I'm now writing a Crystal Reports FLL for their printing engine because I don't want to use their Automation Server or ActiveX (more DLL Hell).

I don´t agree. You just must know the appropriate DLLS to redistribute or use a prepackaged
merge module for CR available for example with installshield. Using an installer BTW is you most effictive weapon against the DLL hell and other installation issues. Whether it is a VB, .NET or VFP application, an installer is an invaluable tool.

>I'm tired of adding running boards, air foils, pinstriping, whitewalls, blah, blah to VFP.

>I want it "out of the box" ! The fact that I can "do it all" in VFP proves nothing; only that I'm spending too much time doing "it", and not enough time solving business problems.

I might agree that it would be benificial to have more native controls in there, I don´t agree with your argument. ActiveX controls in general are a very fast and convenient way of including complex GUIs into your application. Rebuilding those controls in VFP IMO is just a waste of time (As you do mention also). I don´t think that moving to .NET would gain you much as there still is something like different versions and different OSs to take care off. IOW you won´t solve the installing issues and would actually gain little on the GUI side (compare with using ActiveX controls within VFP).

Groetjes Walter,