My $0.02

[Rodney Hicks]

You will find opposing views of certain issues within this document as I wrote thoughts to be filtered and/or considered.
I removed some of the things I was considering because they are not applicable to startup.

We do not need to spend a lot of time on building a user editor feature. Any editing of resulting code can be accomplished in the PB IDE or the use of input boxes.(original version)

We should establish a variable naming convention so we are all on the same page(variables may become our biggest headache if we aren't careful)

Is there any way we can be held responsible if someone uses copyrighted source code and converts it without authorization?

We may be smart to construct this as a command line tool in the first instance/version and grow the converter from that point.

An advantage is that we focus on getting the converter working with output from a VB file to a PB file. At this stage, USERS wanting to compare files may do so in the PB IDE.
At most we need a status/message window with a command line tool.
A command line tool could redirect unconvertable(at present time) code to a secondary .bas? file so the USER knows what has still to be converted.
Alternatively, lines successfully converted could be commented out of the original bas file with " 'VBCON " at the left margin, by the converter.
A command line converter output should be one of DDT or SDK style, and should be an option at the earliest.

Most of the work involved in this project is going to be writing the functions that change VB specific features to PB.
Prioritize the features according to complexity.(least complex to most complex)
Prioritize the features according to use by programmers. (most used to least used)
Blend the features to get the most used least complex features done earliest.
We may wish to consider other parameters besides complexity and use.

Visual features: (other than command line version)
A left and right code viewports RTF
Highliting enabled.
No editing in viewports, although copy from the PB viewport may be nice.
A line reference on extreme right, possibly as a comment or a separate column that does not get transfered to the PB IDE with the code.

B a third viewport for showing called procedures(with arguments) of the converter.

C a toggle for generation of DDT style or SDK style(In menu perhaps)
(I think it in the best interest of the project to support both from the start)

D a fourth viewport for generated comment (editable)
This would use the same line referencing as the other viewports.

E a Menu
File
Options-Include Run from PB IDE?
Help

F other features as requested

Method:
A Build a VB source code parser to translate to PB source code.(See code parsing below)

B Build a monitoring module that tracks the messages of the running VB exe.

c Use another product to do the work.

D All above options must include command line ability.


Performance:
The command line converter does not need all these features.
A Monitoring method. This might mean the ability to stop conversion every x lines or at break points so the USER can ascertain what is happening.

B Highlighting A selected line, shown in bgrdcolor A in any window, brings corresponding lines in other window to view highlighted with bgrcolorB.

C Display conversion time.

Code parsing:
Is it concievable and useful to convert all keywords to a dedicated LONG value? (an %ID)
Is it concievable and useful to convert all arguments one standard type? User defined type?

Rod

[Rodney Hicks]

Very well done.

I too have a similar document, not yet complete, addressing different things that I have thought of.

I hope each of us has something similar so we can glean the best from each.

I'll be posting mine soon here in this thread.

Rod

[Brian Chirgwin]

My $0.02

Two types of users

• VB6 developers new to PowerBASIC.
  
  A tool to help a VB6 developer take an existing VB6 application into PowerBASIC. Since developer is new to PB, code more VB like will keep them productive.
  
• Existing PowerBASIC Developers
  
  Experienced PB Developer understands PB code and may not know VB. Code like PB would be more useful to keep this developer more productive.
  

In might be useful to have options on how code is created. It would be great if the actual code output could be modified by modifying some template files.

Two main features

For either user there are two features that would prove useful.

1. First, of course, would be the ability to completely convert VB code to PB code at the click of a button and have a running application.
2. In lieu of the first result, an analysis of the VB code. The converter can indicate what changes are required, advantages, disadvantages, and possibly how long it will take.
   

Development Process

I propose the following development process.

1. Pick the low hanging fruit by converting the simplest of code. Create a VB project with a single isolated "conversion" test. i.e. A command button with a click event when clicked displays a Msgbox with "Hello World!".
2. Manually write PB code of the VB test project. This is what we would like the code to look like when converted.
3. Make the PB conversion produce the expected result (as close as possible, exact if possible).
4. Repeat with next lowest hanging fruit.

I recommend that a directory structure and naming convention be created for keeping tests organized.

VB Project – The VB Project to be converted
PB Best Practice – Can't come up with a better name, but this is the Manually written code to shoot for
PB Expected – This is the PB code that the converter produces. The converter tester will compare the actual code against this directory.
PB Actual – The actual code produced by the converter. Every run of the converter tester will replace this code.

Note: We may want two more more Best Practice/Expected. One for VB Like code and one for PB like code.

This method will create 1,000s of vb projects. For a Command button, each event, method, and property would be a separate test. The Converter can convert all tests in batch comparing the expected result with the actual (making sure as the product moves forward and nothing is broken).

The benefits of these are many including:[List=1][*] The tests give feedback that the application produces the same result for the same input; Even if every line of code changed in the application. [*] The main goal is to make sure the product hasn't been broken. A side effect, but extremely useful is, documentation. A developer can look at the example VB project and the expected PB code. This alone could be useful.

Complex Conversion Areas

Below are areas that I think will be a little more difficult to convert. Not impossible, but difficult. These areas could be discussed, researched and prototyped in parallel while getting the product underway. My thought is a forum thread could be created for each of these (and others as they come up). I'll leave this to Stan to start the threads.

• UDTs with dynamic strings
• VB CallByName function
• ActiveX/OCX controls
• Functions returning arrays
• Functions returning UDT def
• Unicode conversion issues
• Subs/Functions with parameters/variables of "AS CONTROL"
• OOP Conversion

PBWIN IDE

I see the converter as an IDE as follows:

1. User browses for a VB Project or Group File.
2. IDE creates a file for persisting data during conversion process. Same project name, with an extension (.vb2pb is a thought).
3. Converter loads the VB Project files by type Forms, .BAS modules, .CLS modules, and Others.
   
4. A "Code Pre-check" on the VB source code lists warnings/tips/instructions to the VB code that must be or should be made before code is converted. I'm not sure what is in this list. Hopefully the list will be reduced as the product becomes more mature.
5. Converter lists all Sub/Function Calls; Variables, their type and their scope; Controls, their properties and methods referenced; TYPE structures and their use. The developer can rename functions, variables, controls before the conversion occurs. Any object named with a PB reserved word would require changing the name at this stage. Once completed user clicks the Convert Button to continue the process.
   
   By the way, this functionality would be useful on PB code as well.
   
6. Conversion writes the new PB code to a subdirectory. During the process warnings, tips, recommendations for testing, and other information is presented as well. The developer will have the converted code along with a document containing any instructions for additional changes. The user can set priority, marked item completed or ignored. This would be a "To Do" list.
   
7. IDE should save conversion state and allow re-analysis at a later time. In other words, maintain details of what modules have been converted and what hasn't been changed.
   
8. In addition, IDE should be a "Refactoring Browser" www.refactoring.com .
   

Milestone 1
Convert .BAS modules (Standard) VB Basic code to PowerBASIC. This can be compiled as a DLL. Declares module can be created for VB application to call the PBDLL.

The application would start by being selective on what is converted, skipping functions with more complex code. For example:
. Skip subs/functions with parameters or variables with AS Control
. Skip subs/functions with parameters or variables as Variant
. Skip functions that return Arrays or UDTs
. Skip subs/functions that use UDTs containing Dynamic arrays

Milestone 2: CLS modules.
C++ started out as a pre-processor converting C++ code into C code. The resultant C code was somewhat unreadable at least difficult to understand, but did provide the capabilities for the C++ compiler. Similarly, recursive code can be written in a non-recursive manner.

I believe there is a manner to take VB OOP code and convert it into non-OOP PowerBASIC code.

Again these can be compiled as a DLL and used in the VB6 Application.

Milestone 3: Forms Conversion

I've left forms last as I believe forms will be the most difficult part of the conversion. Forms contain OCXes of which there are 100s. These OCX controls will require replacements.

It would be great if the Form .frx file format could be read. This would allow icons/images and properties of third party OCXes be converted.

Summary

In summary, by selecting the low hanging fruit and moving one small step forward, the goal will be reached in time. Having an application convert the simpler stuff would leave the developer more time to convert the harder stuff (at least until added to the product).