Printing - FoxTalk - dFPUG-Portal

The first key to making everything work is the set of buttons on the left (Page1, Page 2, and Page
3). These are graphical radio buttons. The image in each button is, optimally, 15 pixels high and
a bit wider than it needs to be for the longest label. Radio buttons are used, rather than push
buttons, so that the "pushed in" quality will be retained (if push-buttons were used, they would
only be pushed in for as long as the mouse button was pushed in).
The radio buttons use the variable m.lnScreen, and they call NewScreen as an expression with no
parameters to validate the button. The code in NewScreen then guarantees that the variable will
be correct and that it will be selected automatically. When a different radio button is pushed in,
m.lnScreen will be changed to that value, and the corresponding screen will be displayed.
The second key is changing the information that gets displayed in the screen, so that the old
information is removed and the new information is displayed. This is where the large rectangle
to the lower right comes in. This rectangle is defined as opaque and white with a black hairline
border. It's the same size and position in all of the sub-screens. Objects specific to the sub-screen
are then drawn on top of the rectangle. When a new sub-screen is drawn, the white rectangle will
be drawn first (covering up the old information), and then the new information will be drawn on
top. For this reason, it's often easier to have a "dummy" screen that only has the rectangle
defined and no objects on it. I'll explain how to use this "dummy" screen next.
Define the sub-screens
Once the main screen information has been defined, it's simple to copy the main screen to the
dummy screen and then remove all of the information except for the rectangle. Then you can use
this dummy screen as a basis for the sub-screens.
Copy the dummy sub-screen to each of the sub-screens your application will actually use and fill
in the appropriate field information. Don't forget that the only information in the subscreens that
you fill in is within the white rectangle.
Drawbacks
There are drawbacks with everything, and this style is no exception. Fortunately, you can
overcome most of them with a bit of imagination.
One major drawback is that the radio buttons require that images be created for them. This is to
ensure that they are graphical buttons and look like regular push buttons and not like standard
textual radio buttons. You can create an image using the Paintbrush program that comes with
Windows (in the Accessories Group) or the Paint program that comes with Windows 95. One
difference between this style and the tabbed dialog style is that this style requires more planning
because these bitmaps can't be changed at runtime (while it is possible to use FoxPro to turn text
into a properly formatted bitmap, I haven't written the procedure for this yet). However, this does
turn into an advantage because you can incorporate the graphical and textual elements in a single
place, and you'll immediately see how they look.
Another major drawback is that you can't display any @ .. SAY objects on the screen and expect
them to be refreshed. This is because the READ is outside the screen program (.SPR), and there's