Analyze, Organize Display Logic
The idea here is to get a good handle on the kinds of screen layouts you use, and how individual layouts break down into categories such as data fields, prompts or labels, headers, background, status messages, etc. You may find that most of your programs have a somewhat consistent 1 or 2 line header display (program title, date, operational mode, etc.). You may also have a status message area, perhaps occupying the bottom 2 lines of every screen. The more you can encapsulate these different display areas into common parameterized routines (ideally, SBX routines), the more flexibility you will have in adapting the design to a GUI environment. (And again, the more separation you will have between your logic and your data.)
As an example, let’s assume you find that you do use a somewhat consistent 2-line screen header, and most programs have a GOSUB HEADER to display it. While you can leave the header alone, or translate it directly into proportional fonts, you will probably find that the kinds of headers that look good in a green-screen layout don’t look so natural in a Window. As a first step in figuring out how to adapt your text screen headers to Windows, it would be very helpful to turn your internal HEADER routine into a HEADER.SBX, which takes parameters such as Program Title, Subtitle, Mode, etc. You will probably also need an Opcode parameter, to distinguish between clearing the entire header area and redrawing it entirely, vs. just updating the Mode or Subtitle field. Some parts of the header, such as the company name, date, time, user, etc., the HEADER.SBX (or BSI) routine can fetch for itself without needing to be passed those parameters.
Once you have a feeling for the GUI environment, you can design a suitable equivalent version of the header. It might be very similar, perhaps just employing a larger font to make it stand out, or you might break it up, putting the title on the Window title bar, eliminating the date and time (already on the Windows task bar), etc.
For the portion of your display devoted to data fields and associated prompts, a fundamental decision to be made is whether to treat the prompts which make up a screen layout as a single entity which must be displayed in its entirety in one operation. Or, you may decide that you can tie each prompt individually to a data field. In the former case, the goal would be to develop a generic "display background screen" routine which you passed a screen identifier to and it fetched the screen form from some external source. In the latter case, the ideal would be to include the prompts as part of your catalog of fields, and develop a generic routine that given a set of fields, is able to draw all the prompts, or all the data. Again, none of this is absolutely required for the GUI conversion, but thinking about it (or better yet doing it) in advance will both simplify the GUI conversion and improve your logic/presentation separation.
