>>>Now it was a number of years, so if I'm wrong I'd like to hear about it.
>>
>>
>>Maybe it was a very old version of WinDev? I started with version 15 which is about 7 years ago. BUT I didn't use it beyond tinkering. We started really converting our VFP apps to WinDev in earnest using version 18, so call it 5 years of working with it now. We converted our main app from VFP9 to WinDev in about 6 months. Anyway, happy to give you a Skype + AnyDesk session so you can see what I am talking about.
>
>Quite possible, and I can't even guess how many years ago this was. I just remember I couldn't find a migration path, i.e. couldn't see how I could write code programmatically, using either VFP to write WinDev code, or WinDev to read VFP code and write its own. All the instructions at the time were ending in the same "click here and start typing", which makes it unfeasible.
>
>If there's such a path, then the migration becomes a possibility and learning how it works then makes sense, and I'd gladly invest time in that. Now when you say you converted your main app - how did you do it? In broad outlines, of course - if it ever comes to details you'd surely be hearing more from me. Keep in mind that we also looked at Servoy and decided that even with the number of customers involved, with automated deployment etc it still doesn't justify the cost. Also, all of these have yet another strong competitor: VFP itself, which still operates smoothly, so many years after we started looking at alternatives.

Dragan,

Because the way you build a project in VFP is almost identical to the way you do it in WInDev we did what I think of as a one-to-one conversion. So it would have been along these lines:

1) Create a new project, name it, define some properties. Basic stuff.

2) Define the WinDev "analysis" (what we would call the database, data files schema). This feature is worth every penny learning and we have only used it to a basic level. But basically if you define all your tables in the analysis then it all becomes part of the intellisense of your project and referencing fields etc becomes so much easier. So this is very important I think.

3) We use the internal database engine of WinDev so we are not connecting to MS SQL or other 3rd party databases but obviously many developers do exactly that for all the good reasons you already know so I cannot help with suggestions here. We just dont need SQL and the WinDev HyperFile system mimics the VFP database system perfectly. It has an added advantage, amongst others, that the WinDev HyperFile database can run in client/server mode as well as flat file mode. And its free.

4) Define the first window (form) of the app. In VFP this was normally the starting program but in a WinDev desktop application this is a Window (form). This is a convention and the windows does not even need to be visible. It just provide the first, starting point of the app. In our case, the first window is actually a usable window so it is visible and has some controls.

5) Write any code in the init, setup routine, whatever.

6) Add any controls to this first window, if any. It may not have any controls and might just be the parent window of other windows such as in an MDI interface (which we like and which we use to great effect imo).

7) If the window has controls you then write to do whatever the controls as supposed to do.

8) Code can be in the control or the control can call routine in procedure files. To create a proceedure file just right click the "procedure" tree node, create new, name it, done. Right click the new procedure file, add routine, name it, done. Add code to the new routine.

9) Now we create new windows for the various reports and outputs we want to present to the user. Windows can contain tables or charts or whatever.

10) Repeat for all the reports and windows and outputs and reports one wants. We did this literally on a report-by-report, chart-by-chart basis. Often I would copy paste the VFP code from my VFP project into the WinDev project and just edit the lines literally one-for-one to use the WinDev equivalent functions etc.

11) We took the time to re-factor a lot of things, combining routine into logical locations, breaking long routines up into smaller function, etc. Basically if we were going to re-write we might as well clean up a decades worth of cobbling code together :) as best as we could.

12) Many things are much easier, for example. We want to present selection of records in a grid to the user.

=> In VFP we would:

1) Create a cursor,
2) Write a routine to extract the records required and populate the cursor
3) Create a window
4) Add a grid control
5) Write code to attach the cursor to the grid control
6) Write code to allow sorting the columns, asc/desc
7) Write code to allow user to resize columns and save column arrangements
7) Write an export routine to convert the grid cursor to XLS or whatever
8) Write code to copy the grid to clipboard
9) Write code to create a report from the cursor

=> In WinDev we would:

1) Create a window
2) Add a table control to the window
3) Tell the table control that it will be populated by code (or by query or by direct access to a database). We choose by code
4) Write the code to extract the records required and add directly to the table
5) The table control comes ready made with ability to sort any column. No coding.
6) The table control comes ready to export to XLS including formatting, column fonts, colours, widths, etc. No coding.
7) The table control comes ready to save column width and locations automatically. No coding.
8) The table control comes ready to copy rows, columns, all to clipboard. No coding.
9) The table control is searchable
10) The table control has many other properties like read/write, styles, etc. These are all easy to set.

My complaint about the above? ... I felt overwhelmed with so many options that I could set for a control that one hardly knows where to begin. So many formatting options, choices, skins, etc. It was a but too much but eventually, like most things, we settle on what we like and just dont bother with exploring more than what we need to in order to get the job done. Much like using the same 5% or 10% of Excel and not exploring the rest.

There are many features we dont use; we dont use skins, we dont use queries (which we probably should), we dont use MS SQL/Oracle, we dont use the reporting engine (there are business reasons for that), we dont use the ability to build in database rules and triggers which we could and probably should. So there are many more things that probably would save us more time and become more productive but sometimes we just want to get something done and out the door. It might not be perfect but its "good enough" and the client is happy.

So the basic process is literally copy routine for routine, program for program, form for window, table for database, report for report....

.