Automating BASIC to revTalk Conversion

Automating BASIC to revTalk Conversion
FMPro Migrator Platinum Edition offers new features and possibilities for conversion

In my previous article about PHP to revTalk code conversion I explained how I automated the conversion of PHP code to revTalk. In this article I am covering an additional new feature in FmPro Migrator Platinum Edition which converts BASIC code to revTalk. Once I had written the PHP conversion feature, I thought that it would also be a helpful to add a BASIC conversion feature as well. I spoke to a Rev developer at the Rev 4.0 Launch Event who was converting an old BASIC program into a new Rev application. This conversion process was taking some time to perform, because it was all being done manually. So I decided that I could help Rev developers who might be in a similar situation by automating the most tedious and boring parts of the conversion process.

There are a number of advantages to converting older BASIC programs into Rev. The advantages of converting to Rev are dramatic if your BASIC code is more than 10 - 15 years old and running on older PC hardware. The Rev development platform enables you to create desktop executable apps which run on MacOS X, Windows and Linux. And Rev 4.0 adds a really cool new feature which enables you to build a desktop app into a revLet running within a web page, as I have done with the BASIC to revTalk demo revLet on this web page. The revTalk code can also be executed server-side with an On-Rev hosting account.

If your BASIC code is more than 20 years old, then you will appreciate the event-driven architecture, instantaneous compile/execute cycle, integrated debugger and automated screen refreshing features which are provided by Rev. I will cover some of these enhancements in more detail later in this article when I show some ZBASIC code I originally wrote in 1985.

This feature is also intended for new Rev developers who may be evaluating the Rev development platform. I have spoken to a number of developers who have told me that they have embarked on conversion projects just because FmPro Migrator was available to automate difficult and time consuming tasks. That doesn't mean that they didn't still have some additional manual work to do to complete a conversion, but they were willing to start on a difficult project due to the automation which I was able to provide. I think that the same situation will be true for this new feature as well. This automated code conversion feature may provide the motivation to actually start working on a project which was previously considered to be too difficult or time consuming.

Some of the additional challenges associated with BASIC to revTalk conversions include:

Converting Variable Names - Within PHP code, it is a straightforward task to know that you have encountered a variable within the code because each variable always starts with a $ character. PHP functions never start with the $ character so if you find one within the code outside of a set of quotes, then you have found a variable. The process is not as simple when processing BASIC code. Variables might end with %, $ or # characters which signify the variable's data type. Furthermore, names of functions and subroutines will look very similar to variable names.

Old Command Line Driven Code - Older BASIC code written more than 15 - 20 years ago will probably be written as command line driven code. However modern development environments like Rev are completely event driven. This means that a piece of code which simply prints info to the screen using the PRINT command, will instead send its output to the Rev IDE message box. I considered converting:

put "Hello World!" & return after field "console_field"

Generating revTalk output code in this manner would have enabled the code to print directly into a newly created field on a stack card, and even scroll up the screen as more info was added. But then I ran into another problem, which was how to handle the situation of the BASIC code prompting for command line input using either the INPUT or INKEY$ commands. I could have added an enterKey handler to the newly created field, but how would I know which code to execute when the handler was running? Within the original BASIC code there could be many INPUT statements followed by specific code which has to run only at that point in the program. And what about situations in which the code needs to run within .irev web pages where there isn't even a field available for trapping field level events? So for these situations, my advice is that the BASIC code will require manual refactoring in order to operate within a new event driven application architecture. But perhaps you have already figured that out anyhow, and that is why you have come to the runrev website to begin with. If this is your situation, then you have come to the right place because Rev is an excellent replacement for your old BASIC command line development environment. Newer code written in Visual Basic or RealBasic will generally be easier to convert because they utilize ObjectName_Click() Subroutines which can be placed into card objects and executed by mouseUp handlers in revTalk.

Multiple Versions of BASIC Syntax - There is really only one version of the PHP syntax which needs to be parsed, there aren't multiple versions from different vendors - and this presents an advantage for conversion purposes. But for the BASIC programming language, there are many different versions of syntax which need to be considered when performing an automated conversion project. I have reviewed the syntax for 5 different versions of BASIC in order to write this code conversion feature. These versions are intended to be representative of the syntax which would be seen with other versions as well.

Screen Painting & Refreshing of Objects - Some of the BASIC source code I have used for testing consists of almost 8000 lines of data analysis software I wrote in ZBASIC starting in 1985. This code has many sections which are designed to draw and redraw objects on the screen when the screen gets hidden by another window. I was very excited about Apple's introduction of HyperCard in 1987 because I quickly realized that I no longer had to manage the drawing of controls onto the application windows. Within modern development environments like Rev, you draw the controls once when you create each screen and then you can hide/show or set various attributes of the controls while your application is running. But you don't have to worry about redrawing the contents of any of your screens as a result of the screen getting covered up by another window. So to handle converting this type of old fashioned screen painting code, you would want to manually create a card for each screen and add the controls once.

Due to the challenges listed here, it took twice as much revTalk code to perform the BASIC to revTalk conversion (about 1200 lines) compared to the PHP to revTalk conversion code. But as far as code conversion tools are concerned, this amount of code represents a very reasonable investment considering the many hours of "busy work" which can be eliminated by using automated code conversion.

The BASIC to revTalk conversion feature traverses all subdirectories of a selected top-level source directory and converts all of the .bas, .vba, .vbs or .txt files which it finds. For each BASIC script the new revTalk code is either saved as an .irev file in the destination directory, or as a card script assigned to a card within a new Rev stack file. Some of the automated conversions to the code include:

Instead of creating a bunch of code samples within this HTML page, I decided to create a spiffy new revLet to let you see the conversion process within your browser. You should see the revLet loaded below if you have the revWeb plug-in installed. Click the Convert button to convert the pre-loaded sample BASIC code or click the clipboard icon to paste in your own sample code from the clipboard.

With relatively little additional development effort, I have been able to create a feature rich Web 2.0 web application, based upon my desktop application code. I can't think of any way in which a BASIC development environment would let you take desktop application code and turn it into a feature rich Web 2.0 web app as easily as I have done with this revLet. This is a terrific advantage of the Rev development platform. And you don't need to buy expensive tools like Adobe Flash Professional (at a cost of $700) nor do you have to learn a whole new development language to create your web app. With Rev, you can use the same IDE and the same revTalk code for all desktop platforms as well as the web based revLet. And with very few exceptions, almost all of the 1600 revTalk keywords which work within desktop apps will also work within the revLet.

As with most automated conversion software there are some limitations to the conversion process, and this is true of the BASIC to revTalk conversion process as well. In general, each BASIC instruction needs to be on a line by itself. The exception to this guideline is that comments will be parsed and converted either on a line by themselves or at the end of a line containing another BASIC instruction.

Each line of BASIC code should be "well formed" code containing at least one space between keywords, variables and operators.

OOP (object oriented programming) code will often be found in programs written with many of the newer BASIC development environments, and these features won't be converted. Older BASIC code simply won't have these features.

The screenshot displayed below shows the performance results of converting almost 8000 lines of code for a data analysis application I wrote in 1985.

A sample of some of the screen painting code which would no longer be needed in a Rev developed application is listed below. The MOVETO commands moved the pen to the specified location prior to drawing text or lines on the screen. The PRINT commands were converted to revTalk put commands, but the remaining code was either unprocessed or commented during the conversion. These BUTTON commands were used to draw radio buttons on the screen with a label. As part of the manual conversion tasks, a card should be created in a Rev stack and buttons, lines and labels should be placed onto the card. Then all of this code would simply be removed from the app. It wouldn't even be necessary to write code to highlight the clicked radio button in Rev, because adding the radio buttons to a group and checking the radioBehavior property in the Inspector will take care of this task automatically.

put "Fairchild Sentry 7 Data Reduction" into D[1] -- DrawText \
       D(1)
MOVETO 1,147 
LINETO 510,147 
MOVETO 25,171 
put "Processing:" : DrawText D(1) into D[1] 
MOVETO 284,215 
put "To:" : DrawText D(1) into D[1] 
-- fill up buttons with previous selections
-- GOSUB Refresh.2A
-- BUTTON 1,1," Yes",(130,4)-(195,19),3
-- BUTTON 2,1," None -- Special Processing",(205,4)-(413,19),3
-- BUTTON 3,1," None",(130,24)-(195,39),3
-- BUTTON 4,1," Remove AC Data",(205,24)-(335,39),3
-- BUTTON 5,1," Remove DC Data",(345,24)-(475,39),3
-- BUTTON 6,1," None",(130,44)-(195,59),3
-- BUTTON 7,1," Merge",(205,44)-(287,59),3

Embedded Assembler Code - There is no place where you could use assembler code or memory location specific code like BASIC PEEK & POKE instructions in a modern cross-platform software development environments like Rev. These instructions won't be processed during the conversion process. But you can write Rev externals if you need to access operating system specific APIs.

Visual Basic Code Requiring Microsoft Windows or Microsoft Office Specific APIs - Rev is a cross platform development environment which doesn't tie its functionality to a specific operating system or set of application-specific APIs. But as with the note listed above concerning assembler code, it is possible to write a Rev external with the ability to access any available API.

For more info on tasks which need to be performed manually, please see the BASIC to revTalk conversion PDF manual on the FmPro Migrator support web page.

If you aren't sure how a particular piece of code will be converted, feel free to come back to this web page and test it within the BASIC to revTalk revLet. If you want to performa a more detailed examination of the code, download the demo version of FmPro Migrator and test your code. FmPro Migrator will process 5 BASIC scripts of unlimited length in demo mode.

The BASIC to revTalk Conversion feature built into FmPro Migrator Platinum Edition enables Rev developers to quickly convert an entire directory of BASIC code into a Rev stack or .irev files. Depending upon the age of the code and the development style used in the original BASIC code, a significant amount of work may still be required. Converting obsolete command line code into event driven code will require more work than converting newer event driven BASIC code. However, reducing the amount of manual labor required to convert each line of code can make a large project conversion far more practical and a less intimidating task.

FmPro Migrator Platinum Edition is available for $599 from the runrev online store, or $399 as an FmPro Migrator Developer Edition upgrade or annual renewal. As a limited time introductory offer until the 28th February, .com Solutions Inc. is offering FmPro Migrator Platinum Edition for a 50% discount (new purchase for $299 or upgrade for $199). Use Coupon Code FMPROBASIC for this special offer. FmPro Migrator Platinum Edition includes license keys for the following features: