Hi Jos,

I appreciate the time you spend feeding back on your VFP-developper journey within Windev!

I have an application here that started as a data handling one... And is now certainly not dbf-centric anymore or even sql-engine based. The application is getting into a decision-support one exclusively with a look-n'-feel à la paintnet.

This strange "vfp-originated drawing application" essentially consumes csv or Excel resources with some http xml-tapping at times. I am sure that Windev would cope with that part that quite well! - but can you expect it decently in the drawing arena? In other words, can one use the current Windev as a generic programmatic environment à la old-school VB? I should possibly say "vieille école" by the way.

In this VFP9 application, these drawing operations are currently handled as a foxpro hack with via clunky mousemove, mousedown, mouseup event code. I do not like the responsiveness here nor the hack code style on the UI - and I have started to prototype a python-based alternative with a view to implement the UI part on pyqt or wx.

Since this application also employs a lot of cursor operations - and massive rushmore optimization of course - I wonder whether it could make sense to run a test on Windev as well since I could possibly reuse part of the application logic instead of rewriting a significant number of algos for more academic python data structures. Rewriting an application based on massive use of cursors with more traditional data structure is certainly time-consuming!

In your experience with Windev, are its local engine sql operations as speedy as the vfp9 ones? Including on non-trivial SQL calls ? Can one expect to reuse a significant part of vfp cursor-based logic in Windev?

Trying Windev instead of python on QT... Well my career as developer and my reputation would take a blow from such a choice :) But it has already suffered a lot anyway:)

François