Oleg;

The following is my opinion based upon a successful career creating software solutions during the last 20 years.

Personally I see no advantage to using Visual Basic to handle data. Yes, it can be done and yes it has been done. By using a commercial application framework for Visual FoxPro you will create a solution in much less time than is possible in Visual Basic given the same resources. In addition you have all the benefits of speed when handling data or strings which Visual FoxPro is famous for.

My reality is this: I have been required to use Visual Basic to handle data and have been successful on many projects. The reason I did this was because of two requirements.
1. The client insisted and it was in the contract.
2. The company I worked for required it.

I always offer suggestions about the best way to solve a problem based upon my experience.

For my own consulting I use what I defined in the first paragraph which is Visual FoxPro and a commercial application framework. I do this to be able to submit a bid that has a great chance to be accepted. The reason is it takes less time with the tools I use then if I were to use a Visual Basic solution. Additional requirements after delivery are a simple task too. I always get repeat business!

Microsoft recommends using Visual FoxPro 6.0 (along with other Visual Studio 6.0 products) as a COM object such as in a multi tier application, to handle data. I have done this and it works great! If you want to use Visual Basic for the interface that is fine, but you will write a lot more code. It will also take more time to use Visual Basic to create an application.

Looking from the developer side I would not use Visual Basic to handle data. It takes too long to create a successful project. I use the term successful because of the number of visual Basic application failures I am aware of. These were large teams of experienced developers who failed. From the user side Visual Basic will handle data and strings slower than Visual FoxPro. Users may not notice this or care. I care.

So what I think is most important is the bottom line. To develop a successful data based solution economically use Visual FoxPro. It takes less time and fewer developers to do so. But then some people and companies are more interested in other things. This just goes to show you that not everyone does something for the same reasons.

Why isn’t Visual FoxPro used for more data based application solutions? Why are there so many .COM failures? Why are there so many major Visual Basic application failures, some of which were solved using Visual FoxPro? It boils down to the little boy who has the ball. If you own the ball – you make the call as to how to play the game.

So go with the flow if you want to earn a living working for someone else or a demanding client. Otherwise do yourself and your client a favor and use the right tool for the job at hand.

By the way I program in many languages including C. If I submitted a bid to create all my work in C I would be homeless!

Tom




>Hi guys,
>
> I am planning to rewrite my old Fox 2.6 app. I am too much into VB nowerdays. So, I was thinking of some kind of a combined VB/VFP solution.
> The main reasons to stay in Fox are:
>- data processing tools
>- printing
>- speed
>
> So, I thought I'd build as much as I can in VB and leave some heavy data processing and printing in Fox.
>
> Has anybody tried something like this?
>
> I faced one problem streight away. I built a Fox DLL and tried to use a class with a REPORT command. Fox didn't like it...
>
> Is there a way to call Printing/Previewing built in Fox from VB?
>
>Cheers,
>Oleg