Page 1 of 1

VP7.4 to VP9 Application

Posted: 16 May 2020 21:32
by Mike Wernicki
I'm converting a VP7.4 app to VP9. I've notices that the *.pro files once loaded into the VP9 editor show very few characters. I'm looking into whether there is some kind of 8 bit character versus 7 bit character difference.

Using notepad to read the pro file, all the information is shown. Just to be clear. no conversion has been attempted yet. I'm not reading the project file. I'm just trying to load a single *.pro file into the editor.

Re: VP7.4 to VP9 Application

Posted: 16 May 2020 22:25
by Harrison Pratt
Mike,
You are almost there ... your VP7.4 file is ANSI encoded and VP9 needs UTF-8. If you open the file in Notepad you will see Notepad has is a File | Save As... option. At the bottom of the Save As dialog there is an option for you to select Encoding: . Save the file as UTF-8 and it will be read into VP9 with no problem. I believe you will need to do this for all the text files in the project.

I am sure there are some batch converter utilities available on the web, but I haven't searched.

There are quite a few syntactic modifications that you will need to make to effect the conversion. If you are converting more than a few files I suggest that you consider from the start using regular expression replacement and possibly an editor like Notepad++ that can record and playback text macros. These will be most useful in converting the predicate definitions and database fact definitions.

I have done a few similar conversions, working patiently to correct the numerous syntax errors which arise from VP9 trying to parse VP7 code. This is not a bad way to learn VP9 if you are coming from VP7, but I found that once I had the concept of the new syntax it was more efficient to recode the application almost from scratch using copy/paste of key algorithms. The VP9 syntax and language features are far superior that of VP7! :-)

Re: VP7.4 to VP9 Application

Posted: 17 May 2020 21:00
by Mike Wernicki
Strangely enough notepad indicated most of the files were UTF-16 LE. There were only about 40 files. That only required about 20 minutes of repetitive work converting. Mostly ctl, i, and pro files. There were a few pack files which had the license information.

There is little code depth to the program. Image a window with about 12 tabs and a form attached to each tab. There are about 500 fields spread across the 12 forms. Most of the code is attached to the event for the field. I ended up with a project with just the forms ctl files before building the program. It looks like I'll have to add the code again to the controls. It might be possible to salvage some of the old code. In looking at the forum information in converting VIP7 to VIP8, the ico graphics are different and libraries have differences. pfc\redBlackTree, pfc\regexp, vpiEditor , vpiChainDB.lib are not in VP9. I actually found the editor to be useful. A multi-line field allowed macros to be entered and edited. There was code to format the code after the lines were saved. Texted seems to be handled differently in the buttons etc. There seem to be a lot more of static texted called out in the form.

I would like to confirm that the Editor and ChainDb were removed from VP9. I've read in the forum it was depreciated at the very least. What is the recommended database? That is one of the items I had intended to change but not so early. I had hoped to get the code working again before making such a major change.

Re: VP7.4 to VP9 Application

Posted: 18 May 2020 12:26
by Harrison Pratt
the Editor and ChainDb were removed from VP9.
Yes, that is my understanding. I do recall that SQL databases were recommended for heavy-duty applications. You might post a separate question about that question.

Re: VP7.4 to VP9 Application

Posted: 18 May 2020 15:40
by Thomas Linder Puls
The editor has been superseded by the sciLexer. The editor example shows how to use it.

The chainDB is still available in the Commercial Edition. But we don't really recommend using it as a "real" database, mainly due to the lack of backup facilities. But also because such a database is a bit fragile, if the file gets corrupted everything is typically lost. It is fine to use it as a work-database during a program session, but not for long term persistence. We have a few historical usages of it in our own programs, but we normally use SQL databases for the "real" database and the collection library for session-data.