Do you already generate your character based application using a screen generator? If you do, then here is how to generate a Visual Interface for it at the same time!
How Windows Resource Editors Work
Visual Basic 4 and generating .FRM files
Generating Forms for Things That Are Not VB4
One of the major requirements for producers of character user interface (CUI) applications is to produce a GUI version of their applications. This article provides business and technical reasons for using jBASE as a means to achieve this. This introduction contains no technical content and can be read by anyone or 'stolen' by technicians who wish to present a business case to management who are about to spend a billion dollars to fail at something else.
To date, producing a GUI version of a character based application has been a choice of the lesser of two evils:
The first choice is only practical if you have enough of the following factors in your favor:
The second choice is only practical if:
Pretty savage attack on the two choices available you think? Well, OK, to make my point I go in hard here. However if you don't yet agree with most of the points above at least half-heartedly, you are either lucky enough to have low tech users or you haven't tried to do this stuff yet.
This web page shows you another alternative if you use jBASE as the way to ship your application on Windows. although it is written from the point of view of a VAR, it will also be useful for end-user sites who are interested in adding a GUI to their application. Given that jBASE is probably cheaper than what you have now, is certainly faster, certainly closer to Windows and the only thing that works on Windows '95, are you willing to explore a bit further?
If you are reading this paragraph then I guess you are :-). OK let's lay down a few ground rules for what we are trying to achieve:
Now let's take each of the above, examine it and see in outline what jBASE will allow you to do:
Use the existing specifications to generate the GUI. Unfortunately, it is at this point that some of you will have to bow out of the exact approaches we will describe here. Step down those of you who do not use any kind of screen generator at all in your programs or do not drive the application from some sort of screen specification. Unfortunately if all your keyboard input and screen output is all over the application code rather then controlled from just a few central points, then your work is going to be increased substantially. If you fall into this category, this information is still applicable, but you will need to use manual edits to achieve the same thing. If you have some sort of automated way of producing your application's screens, then read on McDuff, read on;
Don't give me a screen scraper, I want a 'real' GUI. What we mean here is that we want a GUI that is running on its own in Windows and does not require something to interpret signals from the application as to what to do next. The GUI should drive the application not the other way around. The suers (Freudian slip or typo?) will soon smell a rat if your GUI does not behave like their other ones and is not up to date with the latest look and feel. With jBASE you can use Microsoft tools to generate the GUI.
No runtime fee please. After you have charged the user for the application runtime and the jBASE runtime (in one price of course), it is difficult in some cases to then charge an additional fee for the GUI interface. Especially when you are trying for new business where a GUI is merely an implicit requirement of your application. Using the methodology described here you can use standard GUI tools that require no runtime fees.
"Real" client/server only. If you use a terminal emulator and embed lots of icky control sequences in your print statements you are only getting a veneer finish to your application and you are paying through the nose for additional terminal emulation licenses. Using jBASE your application becomes a true client server system: The application can run directly on the users PC and share files on the network. In addition you get this ability without changing the application or doing any complicated setup!
GUI and CUI interfaces must be supported. Using this methodology you will generate a GUI starting point for your application and be able to keep your existing CUI starting point too. Users of dumb terminals will start the application as normal, users of Windows will have an icon that starts the GUI interface. This is a trivial thing to setup.
This needs to be a minimum amount of work. Well using this approach you should only be changing your screen generator and adding maybe adding some new supporting code to check that all the correct fields are filled in before processing a screen of information. The chances are that your application already checks the input pre-requisites anyway. Your existing SUBROUTINEs should be unchanged by this work and you should be bale to generate the GUI automatically.
Low financial and technical risk. A very small amount of effort is required to convince yourself that this approach is a valid one. All you need do is construct one VB (or other) form and call one jBC subroutine with a mixture of parameters. Once you see the subroutine calls happening, inspect the source for the GUI frame and see the type conversions working for you, you should be convinced. This should show you that the approach is eminently feasible. The financial risk is small because you do not need to invest heavily in tools to do this: you need a Windows version of jBASE to do your development at $149 for Windows 95 PC's or $299 for NT PCs. then you need to buy the GUI tool which unless you hate it, will probably be Visual BASIC 4 - Professional Edition at about the same price. Then it is just your development time; but you have to invest in the development anyway.
OK, let's start looking at how this stuff goes together...
In Windows, a 'resource' is something that can be used to display or capture information. You are already familiar with many of these such as dialog boxes, buttons and list boxes. The bitmaps that go with these things are already provided in DLL libraries with Windows and the GUI tool you utilize to build interfaces.
The Resource Editor such as the form painter in Visual BASIC or the Resource Editor in Visual C++ are merely GUI tools to produce a resource file that describes all the components of the interface. The resource file is (in the case of most Windows tools) just an ASCII text file that is compiled by a resource compiler to produce the working interface.
As you already have a screen generator, you can quite easily produce resource files directly and skip the GUI builder part of the operation. In addition you can look at the character version of your screens and use the VB. form designer to generate a standard look and feel for your GUI versions. You are effectively producing a template for your screen generator to use or more precisely producing a set of custom resources for it to use. Here we will assume you are using Visual BASIC 4.
A .FRM file is effectively divided into two sections. The first section describes all the resources on the form, their parameter settings and where they should be drawn (like an @(X,Y) position). The second part of the .FRM file contains Visual BASIC source code in functions such as OK_Click() or Input_LostFocus. here is how you produce the definitions of your resources for your existing screen generator.
Firstly produce a dummy screen for each different form type you expect to require. Go ahead and make this bang up to date with the latest Windows 96 look and feel, and bitmaps if want them and everything else that you want to see. Design this to look like a real Windows 95 application but don't add any code to the form unless you expect this code to be in every form based upon this template. Now save the form.
In the source directory of your project you will see a file called FormName.FRM. You can edit his with a standard editor to get a feel for how the .FRM is laid out. You should find it pretty easy to work out. You will use this as a template for your screen generator to fill in.
Now go back to VB4 and paint a form that includes all the dialog boxes and menu layouts that your application will require. Again we are producing a template of resource definitions that your screen generator will use. You can now edit and inspect the .FRM file for this new form and either spec out the code that the screen generator will produce or you can cut and paste the definitions to produce templates for it to fill in.
You now, amazingly enough, have all the components you need to build your GUI. Now you have to add code to your current screen generator to produce .FRM files for your screens. However, there are a couple of other things to address such as dealing with required field inputs etc.
Your screen generator also needs to generate code for any events on the form that you want to respond to. This can be as simple as adding code to respond to the OK button being clicked on:
Private Sub OKButton_Click()
Dim Result As Integer Dim Message As String
Err = jBaseCall("SUBROUTINENAME", Field1.Text, Field2.Text, Result, Message)
If Err = 0 Then
If Result # 0 Then
MsgBox Message
End If
Else
MsgBox "Could not find subroutine SUBROUTINENAME"
End If
End Sub
You can of course add VB. code and/or jBC subroutine calls to respond to any event on the form. The calling interface does a number of useful things for you such as translating a SELECT list to a VB. array of all the record IDs. This makes updating/filling in a list box very easy.
You could also generate the VB. project definition for the Application if you were adventurous, however, it is easy enough to manually import the .FRM files to a new VB. project.
For those that want to look at the source for a "complicated" .FRM file, here is one. Feel free to load this into VB4 and see the kind of flashy looking form you can generate using this method. The form has a suffix of .txt here so as not to confuse your browser, you will need to save it with a .FRM extension before importing it to VB4. Note that this frame is part of a bigger project and references global variables that you don't have. Just ignore VB4 when it complains about this, it will load anyway.
Although this article deals mainly with VB4, there is nothing to stop you generating the equivalent of VB. .FRM files for whatever environment you or your developers favor. This is of course one of the benefits of using jBASE here, we don't force you into using some proprietary tool that completely ties you to one particularly way of doing things. In addition this means that you are not reliant on ourselves to keep up to date with Microsoft's latest GUI look and feel.
Visual C++ uses a file suffixed with .rc to hold the definitions of its resources. The .rc files and VC4++ are of course somewhat more sophisticated. You will also need to generate some C++ code to call the BASIC subroutines. We would suggest that you do not use VC++ for this exercise unless you are very familiar with C++ and .rc files. However, you don't have to listen to us of course!!
At the time of writing we are unaware of the mechanisms that Borland's Delphi uses simply because everyone is too busy programming to get down to Egghead and buy a copy. It is likely to be a very similar method though. We need to confirm that the current version of Delphi is 32bit and supports OLE Automation Variable types before making any bold statements about this. We welcome any input from you ardent Delphi fans out there until we go buy it!
We suspect that interfacing to Power Builder in this manner is possible however we have not tried to do it.
There is only one final piece to the puzzle and we have touched upon it earlier. This is the basic difference between a GUI interface and a serial/CUI interface. A GUI interface allows the user to click around on a form and fill in the data in whatever order they want. However, this is not really a problem for your new GUI interface to be honest. All you need to do is generate a jBC subroutine call for anything that needs checking. The following possibilities arise:
As far as we can determine, all other possibilities are variants on one of the above themes. For instance if you have to check a certain input format then create a jBC subroutine that takes three parameters: Value, MatchPattern, Result (it could also return a suitable message for the MsgBox statement if you want). Then generate a call to this subroutine in the lost focus event.
© 1996 jBASE Software, Inc. All rights reserved. All trademarks on this page are recognized.
Last update: June 1996.