>>
>Yep, this is one possiblity, the other is gaining as much info on VFPs future as you can get and guess there will be a VFP 8.

>VFP 7 is not out yet... VFP 8 is a bit premature... And quite frankly, people need to build stuff today. Folks cant continually wait 2+ years to get features that are already in tools available today...

I'm not arguing that this behaviur is the wrong way, but from my POV there are lots of people who do. I don't think people are just waiting for some extra features (i'm quite happy with VFP 6 SP3), but are really affraid that VFP will be discontinued.

>>I think the word 'take' could easely replaced by 'have'. As we both know there are so much technologies and new products we already must/should learn you could easely make a full job out of learning. I think most of us are really selective about what is worth learning.
>>
>
>No...take. People have the time. They choose not to take it... It is about taking responsibility for your own career... If it is important enough, you not only have the time, you will take it... Anything else is pure laziness...

If I take the time for everything I want to learn there will be no time left to earn money (nor time to sleep). So I'll have to choose how much time there is in my budget, and which technologies I want to study.

>>>3. I don't know why you insist to look at VB 7. Personally I think that the combination of VFP and C++ is a lot more powerfull than VFP and VB. O.K. C++ is more difficult to learn than VB, but thinking outside the MS box might be another choice (Delphi).

>
>Delphi, with its support of Linux is very interesting...
>
>This has never become quite clear to me. What exact things can be done in VB and cannot be done in VFP and is really worth the cost ?
>
>Async processing, ability to spawn threads, better ActiveX control support... shall I go on???

Async processing: You've got one here. OTOH I rarely came in cases where this was absolutely neccesary: I could start another process and communicate trough tables/cursors or whatsoever.

better ActiveX control support...: Yep that's for certain, Personally I'm quite happy with the axtiveX controls that work with VFP. I think that there has improved much since the release of VFP 5.0.

I'm sure you would mention early binding next. You're quite right that these are characteristics where VB wins from VFP hands-down. But to be honest this is not enough for me. In VB I don't have:

- A blazinly fast local data-engine
- A Fully OOP environment where the UI is indeed the most important one.
- A rich data centric language including it's own DDL and DML.

Sure you would say that i'll be able to combine those languages, but I hesitate because i'm afraid I'll not be able to get my applications as stable in a homogenous development environment. I rather choose to be an expert in VFP than medium rare in both VFP and VB.

>I agree, but if you're a hardcore VFP developer looking for more absolute power, C/C++ might be the tool you're looking for.
>>

>I am about has hardcore as it gets with VFP, and I could not imagine taking the leap into VC++. OK, if there is some intensive operation that needs C, fine... I probably could still build it in VC without having to be a master. If it does require expert C skills, I will subcontract those tasks... There is no cost-benefit for me having to learn C++. Yes, I may need to have some general familarity with the product... I can get that from Teach Yourself VC++ in 21 days. Anyting more is non-productive...At least, this stage in my career...

It seems that your POV towards C/C++ is familiar with mine regarding VB. Since I've programmed before in C/C++ (I build a small CP/M, Z80 compiler once) I'm more attracted to C/C++ than to VB.


>>Another thing: What are your thoughts about other development tools like J++ and Delphi ?
>
>Delphi looks cool. J++ is a flavor of Java, and Java has a bright future... As far as the J++ product itself goes, no comment..


Glad, we could leave the flaming out....

Thanks,

Walter,