I totally am confused with this comment. you say

>But vfp let us develop a fully workable product despite
>its limited scope of data structures (yet very powerful!).

What is limitted in VFP Data structure if like your saying your using Sybase you are not using VFP Data !!

>In fact the reason why we do not care the IDE
>improvements is the fact that we have developped
>a fully generic package (one exe fits many clients)
>where we should have used Delphi or vc++ right
>from the start.

Why would you develop an UI with VC Or Delphi. VFP is very good for building UI and to my opinion there is nothing you can do with VC++ or Delphi you can't do with VFP. And in fact a UI developped With VFP will be much faster to create and maintain. Name one thing you cant do with VFP ??

>My customers (sizable organisations but too few of them)
>like the product (of course fox did a lot with its gorgeous
>display of c/s data in resizable data-grids)

We just finished developing a very large system ( About 600 forms ) and it is now used by very large organizations over LAN/WAN. Our UI Is 100% VFP. Things we could not do with VFP we used ActiveX controls within VFP. Our application tier runs as a Com+ Package and is 99% VFP. Our Data Tier is MS SQL2000. We use ADO for data transfert between the client and the application (Com+) and SPT Between the Application and the data tier. The UI is extremly fast and the application highly scalable and realable. I would noy go any other way.

The only thing we were missing in this project was the abillity to Implement events, using early binding to access Com+ API objects, Strong typing and the ability to return Void (For MSMQ). But hey, VFP7 can do all that.

>
>But We have in a sense overgrown vfp and now plan
>to move the code base to plain old delphi 4 in order to

You've got to be kidding !!

>generate highly optimized executable code
>(shunting odbc and bde for full speed by the way).

I think your problem may not be the language you are using. If you application is 2 tier it is probably moving too much data over the wires. Instead of thinking about rewriting you should review your application.

>
>I recently found that, whilst vfp were still way faster
>than the vb6+ado combo, delphi grids are now really faster than
>vfp in our c/s configurations (sybase ASA thru native drivers in
>C++ or delphi).

Again you say C/S i say 3 tier is probably your answer. We do not use ODBC Between The client and the Application we use OLEDB and we are very carefull about the size of the result set we send back to the client and it works great.

>
>For a long time, i have thought, possibly wrongly, that vfp
>would compete in the same arena. Clearly the current
>marketing of the product is really suited for
>"ad hoc" development (competition clarion, windev...),
>which is possibly the best martet position for vfp.

You are thinking about desktop application. But VFP is more then just a tool for building desktop application. With VFP you can build very fast and powerfull Data-Driven Com+ components which can then be used in web application, i have programs written with VFP that dont even have UI (Runs as NT Service or Com+ Components) Try do do that with Clarion, windev..

>
>In this respect i accept that a powerful IDE may be
>key to most developper here. As far as i am concerned
>i'd develop with notepad or emacs if that fitted...

I still use good old vi on Unix to edit my prg's sometimes, it doen't mean i don't like a good IDE to visually desing forms.

>
>François
>
>Any feedback on porting complex vfp apps to delphi
>is welcome :)

The best feedback i can give you is after you ported your app to Delphi and realize that VFP Was not your problem but the app itself, you may come back to VFP.

Stephane Hamel.