Tracy,

I have paid thousands and thousands for software tools through the years and I know there are expensive ones and cheap ones. It's a matter of how much time will it save you verses how long does it take you to write it yourself $ and will it do what you want.

I haven't offered the tool to MS. I hadn't even written the ActiveX component this spring when I showed Ken Levy what I was working on at Essential Fox. I was coding all of the Device Context painting methods in Pure VFP code. Yes the part of painting rotated text etc that the ActiveX control is doing, started out in VFP to see if it could be done. It can be done but knowing when to repaint the screen is impossible, since there is no WM_PAINT message offered in VFP. Writing it in VFP is FUTILE! However, I offered to go out to MS as a contractor and help them rewrite the VFP Report Engine. I had seen a post on HotJobs.COM or something similar and asked Ken about it at Essential Fox. Ken said they were only looking for Hard Core C++ guys and that position had been filled. I'd like to think I'm language independent. I'm more proficient in some languages more than others. But after more than 20 years of hard core PC programming from Fortran, Applesoft BASIC and 6502 Assembler in 1982 to C, 8086/80286 Assembler, 68000 Assembler, dBase and FoxBase+ in 1986 and ADA in 1989 to C++, Visual FoxPro and Delphi in the 1990s to present, I wouldn't think it would matter. <bg> Since, it's the logic in the code of whatever language that produces the desired result. It's just that some languages are better at low-level stuff than others. And others take a lot more typing than others. You just pick whatever does it best and you know best.

I certainly don't use Delphi for quick database applications and I don't use VFP to write ActiveX controls.


> Well I have to agree with you. While I know some managers will balk at the price, those will probably be the same
> managers not purchasing productive tools for other tasks also (and so it will take their developers longer to do the same
>tasks and hence cost them more labor $ anyway). I think you are correct in pricing it relative to its productive value and
>that value is very high. IT is a GREAT development tool and well worth whatever price you decide upon. Keep in mind
>though: by including all of the features from the 'get go' you leave no room for future features! :o) It would behoove
>MSFT to invest in the tool (purchase the rights to use it from you) and include it in the next version of VFP, but we well
>know that won't happen! Have you offered it to them for a price? It amazes me that they would not grab it!

>Tracy