Tips on Going Graphical

Okay -- you've got a great text-based application and looking to go graphical -- so now where do your start?

Perhaps the following will help.

One of the things that make graphical applications desirable is the richness of the graphical environment and the ability it has to create a more functional application for the user. Merely changing your existing text mode code to look graphical is not going to give you that.

Most text-based applications are designed to lead the user through a screen with the underlying application controlling what the user can do and when they can do it. Graphical applications present the user with the entry screen. This allows the user to control the data entry process by giving them freedom to change the entry order sequence, to launch queries, and to enter data in a variety of ways.

Just changing your existing text based application is not going to give the end-users a true GUI application – to do that you need to change the way you design and develop your application.

We have been involved with a number of clients that have made this transition so let me share with you what seems to work best for most applications.

First off, let us warn you up front that what the successful dealers have found is that most of their application ultimately needs to be redesigned. This does not mean that the existing code gets tossed out, on the contrary, the existing code often gets incorporated into the new system -- the amount of code that is reused all depends on how structured and modular it was to begin with.

Stage 1 - Convert Text Application

First and foremost, clients switching to ProvideX make sure their existing text based application works. There is no sense in trying to salvage code if the code is not worth salvaging. Generally, all existing BB style applications can be ported to ProvideX with very little effort.

Stage 2 - Begin the Transition

Now that you are up and running you probably wants to impress your boss and your clients. Most dealers do this start by redesigning their menu system. This gives you something to show and something that you can use to get familiar with the Nomads toolkit.

Most dealers will start with a menu system that allows them to run both Text mode and graphical applications. This eases the transition for the end-users allowing them time to get comfortable with the GUI application. In addition, it allows you (the dealer/developer) to move to GUI a bit at a time.

Stage 3 – Make sure you have a Data Dictionary

If you do not have a data dictionary, now is a good time to create one. This will be very useful since, ProvideX has excellent built-in support for the Data Dictionary both in its related toolkits and at the language level.

There are a number of tools available to help you load the data dictionary for your application assuming you have some documentation or layouts for your files. These include:

• Data Dictionary Maintenance
• Dictionary object library with functions to load the dictionary
• Visual Dictionary (included with PxPlus)

Stage 4 - Initial GUI Applications

Okay now, rather than trying to start from nothing have the system generate portions of your application for you. Another quick way to start building your graphical application is by generating your simple file maintenance screens.

Every application always has a number of simple file maintenance functions to add/edit a variety of tables such as state codes, payment terms, salespeople, divisions, etc. Most of these maintenance program have little validation requirements other than data formatting. Use the File Maintenance generation system to create GUI applications for these files.

You may be surprised to find out exactly how much of your system can actually be replaced using the standard File Maintenance generator. It is fast and easy to use. Basically, you select the file from data dictionary and tell it to generate the screen. For files with a large number of fields, you might want to consider the folder option to place related data elements together within the folders.

At this stage, you will also want to create a number of file queries. These queries can be used within the generated screens to help in looking up values from your files. Queries can be tied to any input field and if recorded in the data dictionary the File Maintenance generator will insert them automatically.

Often this stage is somewhat an iterative process with you generating maintenance screens, adding queries, editing the dictionary, then going back to regenerate the screen again.

Now, you may find some of the screens are too plain terms of appearance. The screens may be enhanced by using the standard NOMADS panel designer. This will also give you some practice in learning how to design screens (something that will come in handy once you start tackling the larger portions of your application.)

Finally, you might want to consider using CLASSes to help define some of your data elements. This reduces the workload long-term and maintains consistency throughout your application. CLASS definitions allow you to take common data elements and define how they are to be presented and what their queries/help will be. For example, you could define a class for the Client number, which states that the field is always a set size and that when presented on the screen it is to have a specific format and associated query.

Stage 5 – Reports

Reporting in a GUI system can be done a number of ways – again a lot here depends on the nature of your original application. Here are a couple of suggestions on how to address the reporting aspect of your application:

• Use Existing Logic

Develop GUI screens to get user parameters for reports and interface these to existing report programs.

Most report programs ask the user up front to define the nature of the report (date range, client range, etc…) It is an easy process to design screens that will prompt for these parameters and then load them into variables. To minimize the impact on existing code I often suggest a simple GUI panel that passes a string back with the parameters to the calling program, which is generally a modified version of the original text based report program. Now, instead of prompting for the parameters it calls the GUI panel.

If you want to make you reports look better, ProvideX does support the ability to print using a proportional spaced font. If the print logic in your programs is a simple PRINT @(n),field$,@(n),amt:fmt$, … the system will handle all left/right alignment automatically. Many reports can be printed using proportional fonts without any modification other than issuing the font mnemonic.

• Use the ProvideX Report Writer

For many simple reports, the basic Report Writer can be used. If all you want is a list of the file contents, then the Report Writer, on its own, is a quick and easy solution. For more complex reports, look into learning a bit about Views which will allow you to link multiple files together in order to feed the Report Writer.

One of greatest advantages of using the Report Writer is that reports can be easily modified either by you or by the user.

Stage 6 – Core Application

By now, you should have a large portion of your application converted to GUI and have had the opportunity to learn the tools that are at your disposal. You are now ready to tackle your core application functionality.

The best way to approach converting an application to GUI is to use NOMADS to prototype out the screen. You do not have to write any code to get a very functional prototype up and running. Take advantage of the Dependency to help control when controls are enabled, disabled, hidden, etc.. You can also put queries on the screen for the various fields -- and these to will be fully functional without any coding. If you are using the Professional product, you can use Smart list boxes to preload data onto your screen and/or lookup data as it is entered, again all without actually having to create any application code.

Once you have the core screen up and running as a prototype, you can start tying your code to it. This generally involves stripping pieces of logic out of your existing programs and converting them into small subroutines that can be invoked by the GUI screen.

If you are like many of the dealers that have made this transition before you will find a lot of existing core logic can be preserved.

Now, the above is a basic approach to going Graphical. It has been shown to be reasonably effective in most cases. In addition, it has the added advantage that, being a piece meal approach, your clients will continually see progress thus your sales will usually continue during the transition.

It is also important to remember that you are not going to get this perfect the first time and indeed as you get more familiar and comfortable with the tools available you are going to want to go back and change some of what you have already done. Graphical brings with it a world of new and interesting tools – a world you can quickly get lost in and you can burn up many hours of time trying to turn you dull text mode application into a visual masterpiece. Try to avoid that temptation, at least until you are fully graphical; otherwise, you may never complete the transition.