Form Designer
Alan Schwartz
Micromega Systems, Inc.
Introduction: Putting the Visual in Visual FoxPro
Visual FoxPro represents the biggest technology leap forward since FoxPro became a product. Considering both the breadth and depth of fundamental new technologies implemented in it, it dwarfs the scale of the leap forward from FoxBASE to FoxPro.
Unlike the conversion from dot-based FoxBASE to FoxPro, which was mostly skin deep, the changes in Visual FoxPro are rooted in the deepest levels of the core engines:
To even a very experienced FoxPro programmer, this much new content built into a programming language would represent a daunting body of knowledge and detail to learn. Mastering all the new techniques and skills via a programming language alone would be akin to the task of learning a complex new language like Russian or Japanese.
Fortunately for those who build database applications in the real world, this ambitious development strategy is wrapped inside a sparkling visual toolset. The Form Designer provides a set of logical as well as visual organizing principles which render the new functionalities immediately accessible. To digest and master this new technology is a sizable climb—the visual toolset provides the ramp.
The visual toolset brings together the new technologies in Visual FoxPro in an environment rich with levers and handles. Tasks that formerly required huge amounts of complex code to achieve are reduced to a few simple mouse clicks. Previously complex tasks become simple, and formerly unattainable tasks become achievable.
The key, of course, is knowing where and when to click.
This session surveys the Form Designer from top to bottom, giving you an in-depth look at the future of application development. You’ll be better able to anticipate the impact Visual FoxPro is going to have on how you build applications. Since the Form Designer is a hub for development techniques and activities, this session serves as a survey of several interrelated topics and technologies. Numerous other sessions will cover many of the individual topics under the general umbrella of the Form Builder in more depth.
Overview
Orientation
For any developer who has used the Screen Builder in FoxPro 2.6, Visual FoxPro’s Form Designer needs no definition. However, it contains capabilities orders of magnitude beyond what’s available in FP 2.6. We’ll start with a visual survey of all the new tools in it. We’ll look at how code is attached to controls, and how the typical iteration cycle—code, run, debug/trace, code some more—works.
Controls: Something Old, Something New
Then we’ll survey all the visual controls available for placement on forms. Many of these are familiar to you from before—but now, for consistency across all the Microsoft products, they have new formal names: optionbuttons (radio buttons), commandbuttons (push buttons), comboboxes (popups), etc. There are several controls with vastly enhanced capabilities, and several entirely new controls. Some require their own sessions to explore in depth.
Other New P/E/M's (Properties, Events, and Methods)
There are several properties and methods of note that span all the new objects. If the form is associated with data, you can set up the data environment visually. We’ll tour how. You can add your own properties and methods to forms—we’ll see how.
Rapid Prototyping Support
The new Form Designer vastly improves our ability to prototype applications interactively. We’ll survey some of the most relevant features. There are a whole set of new Wizards for quick screens. But of more significance is the new Builder architecture, which opens a doorway to an entirely new level of rapid prototyping.
Programming with Objects contrasted to Object-Oriented Programming
As you may know, Visual FoxPro contains object-oriented extensions allowing you to build fully object-oriented programs. Unless you are fully versed in O-O implementation, you will be very grateful for the emphasis above on “extension.” O-O programming is definitely a big change from the way we’ve been used to developing procedural code in FoxPro, and if you choose to develop that way, there will be a substantial transition involved in getting there fully. During that transition (if you choose to make it), you’ll really appreciate that FoxPro runs all your old code, and you can develop in familiar procedures and functions whenever you choose. However, within the Form Designer, you’ll encounter O-O concepts throughout, and your visual implementations will need to adapt to certain basic principles of programming in a world of objects.
The main difference between traditional procedural coding and O-O is a spatial one. Programmers generally visualize themselves “inside” a working program, mentally executing each programmatic step from an imagined “central headquarters” dispatched from the program’s mainline logic. In an O-O world, you launch separate, discrete objects, each containing both properties (much like memvars) which contain attributes of the object, and methods, (which are like User Defined Functions) applicable to, and isolated within, the object to which they are attached.
You may launch dozens or hundreds of objects into the environment to complete certain tasks. Objects can contain other objects, even groups of objects held in arrays, so the model may become quite complex—presumably suitable to modeling a real-world problem of corresponding complexity.
You do not have to be an Object-Oriented programmer to use the Form Designer, but an understanding of certain basic O-O techniques and conventions will greatly boost your confidence and your productivity when using the tool to implement features that are more than skin deep.
Building Visual Classes
If you are making the transition to Object-Oriented programming, you’ll be thrilled to find that the Form Designer is essentially the same tool as the Class Designer. In fact, the differences between a Form and a Class are really wafer thin. You can turn a form into a class at any time, so easily that debates may rage for some time about just when to use a form and when to use a class.
We’ll look at the basic mechanics, and cover the basic differences. We’ll explore how a starting strategy for an object hierarchy looks, and show how things are connected.
Orientation
Type CREATE FORM or pull down FILE NEW and set the type to Form. So far it’s just like FP 2.6, except that the keyword Form has replaced Screen. That’s where the similarity ends.
High-level overview of the Form Designer toolset
Getting around in the cockpit
There’s a lot of stuff in here, and it would be darn near impossible to do anything productive with it if hadn’t been so nicely engineered to work together so well.
Tips:
Controls
There are a lot of controls to play with! You may feel crowded or overwhelmed by their sheer numbers until you’ve used each one at least once. Only then do you begin to feel like you’ve got an incredible arsenal of tools at your disposal.
Modes:
Controls:
Visual Object Translation Table
| Object | Familiar name for 2.6’ers | Comments |
| Label | Text | You won’t believe how much benefit derives from the fact that in this visual tool, everything is an object. Including some ordinary text.It means that everything on the screen can be summoned to action via a message. Help context ID, click and mouse events, for starters. |
| Textbox | GET field | It may take you a while to get used to the concept that a GET field is a “control” in the Windows vernacular. Work on it. |
| Editbox | Edit region | |
| Commandbutton | Push button | |
| Commandbutton group | Bunch of push buttons (defined as one object) | The “group-ness” is achieved by wrapping the objects inside a container object. |
| Optionbutton group | Radio buttons | Ditto |
| Checkbox | Check Box | |
| Combobox | Popup/Popdrop | Two styles: One you can type into, and one that only offers choices |
| List | List | On steroids. Multiple columns, easy implementation of mover and multi-select, and more. |
| Spinner | Spinner | |
| Grid | Mythical “BROWSE within a READ” | A whole book in itself. Go to the session. |
| Picture (BMP) | Picture | |
| Timer | (didn’t exist) | Animation, time-outs, and more. |
| Form Pages | (didn’t exist—not even close!) | Finally, a comprehensive screen metaphor when there’s too much complexity for a simple dialog |
| OLE object | Programmatic control of the Windows desktop— go to the session | |
| Line | Line | See comment for Label |
| Shape | Shape | See comment for Label |
| Separator | (for toolbars)Yes you can design toolbars in the Class Designer |
Properties and Events
The incredible world of objects means that a lot of features that used to require reams of code in FoxPro can now be implemented cleanly and reliably just by setting the properties of these objects. Some of these properties provide simple correlates to things we did in FP 2.6, but literally dozens of them are new. It is definitely both easier to understand and maintain code when you achieve your purpose by assigning a property rather than writing procedure code whenever possible.
Amazing facts about Properties of Visual Objects in Visual FoxPro (examples—not a complete list)
| Forms | Always on Top (build your own “angelic” help systems like “Cue Cards”) |
| Drag and Drop behaviors | |
| Preview every keystroke | |
| MDI forms | |
| Mouse pointer | |
| Multi-session (multiple instances of data) | |
| Scalemode—screen locations in Foxels or Pixels | |
| Whether tool tips are active or not | |
| Lowly label | Alignment |
| Click event | |
| Drag and drop support | |
| Font support at runtime | |
| Move or resize at runtime | |
| Colors at runtime |
Myths and Realities about Events
| Myth: | There’s a simple mapping from FoxPro 2.6 events to the new event model. |
| Reality: | There’s more to this than meets the eye. Each control is a different case. The new model is generally far superior and offers much finer programmatic control, but the correlations between events in the old and new models shouldn’t be oversimplified. |
| Myth: | Anything with a 2.6 name is only included for backward compatibility. |
| Reality: | Nope. WHEN and VALID are both valid (pun intended) VFP methods in their own right. They’re not even close to GOTFOCUS and LOSTFOCUS. |
Events Vs Methods
These terms contain the potential for unnecessary confusion, because ‘Event’ is carrying two overlapping and somewhat ambiguous meanings. In the general sense, an Event is an occurrence that is registered into a program from outside the sequence of instructions. It could be a keypress, a mouse click, arrival of data at a port, a time-out or other clock event, etc. A method is a sequence of commands attached to an object that is triggered for execution by some event. Within the Form Designer, you may occasionally find yourself wondering if Events are causes or effects. It would probably have been a little clearer if they were called ‘Event Methods’. They are in fact methods that occur in response to an event. For example, the MouseDown event is actually a method that is called when the MouseDown event is detected by the system.
Containers
Modeling real-world activities with objects is very powerful because objects can contain other objects. Within the Form Designer, there are several instances of explicit visual objects. These have P/E/M’s of their own, but exist primarily to contain other objects.
| Container Object | Contains: |
| Formset: | Forms |
| Form: | Visual controls |
| Commandgroup: | Commandbuttons |
| Optiongroup | Optionbuttons |
| Grid: | Grid columns |
| Grid column: | Column header and active row control (textbox or other) |
These appear visually in the Form Designer. Mouse navigation inside them is still being worked out.
Programming with Objects
One of the first real thrills of working in the VFP design environment is watching the visuals come alive with just a few lines of code in event methods. In nearly all cases, the code has a particular form, which is called “sending a message” in O-O speak. Messages look like this:
<object>.<property> = <some value>Most of the rich assortment of properties of the visual objects can be set at runtime. Grid columns can be given different contents, colors, sizes and locations of all objects can be changed, etc. All effects of this type are achieved the same way.
The property part is easy. Objects that share the same attribute use the same property method. Every object with a screen location has a Left, Top, Width, and Height property. This makes for a common language to describe the attributes that apply to this object. (No more WCOLS() for windows, SIZE for GETfields, etc.) In formal terms, this is called Polymorphism.
The key is understanding how objects are addressed. Basically, you have to start with your current frame of reference.
Simple addressing in a one-container form. Use THISFORM.BUTTON2.<property> so the code will work regardless of the form name. (Similar to indirect referencing to retain generic applicability of UDF’s.)
When containers are introduced, object addressing must be adjusted to account for them. In this case, sending a message from “Next” button to the “Bottom” button must be either bounced off the container, or the form. From the point of view of the form, the “Bottom” button can’t be seen. The form only contains the object “CommandGroup1”, which in turn contains Button2.
Wrapping several such forms in a FormSet has the same effect. Addressing from the outside must name both the formset and the form contained within it.
Note “De-snippetizing” is a whole new ball game in VFP. In FoxPro, where you kept screen logic was largely arbitrary—a packaging issue. We all learned that the logic was the same wherever the screen code was located. Moving it out of the form designer had the advantage of quicker access, no code generation, and no random UDF names.The entire paradigm is different in VFP. First of all, there’s no code generation anyway, so the regeneration penalty isn’t an issue. Second, code in a method isn’t the same as code in a program. The keywords THIS, THISFORM, and THISFORMSET are evaluated at compile-time. They won’t work in PRG code because they have no context.
Object- Oriented Programming
This is hardly the place to introduce a topic of such scope. You could spend months or even years studying O-O, but yet, the Form Designer provides an interesting doorway into the world of class creation. In an O-O environment, the programmer creates “classes” which are blueprints for the objects created at runtime. It is beyond the scope of this session to provide enough background on how classes are designed, but there are several sessions at DevCon that will.
If you know what a class is, it is a snap to create one in the Form Designer. In fact, the Class Designer is essentially identical to the form designer, except all object addressing must be relative. Why? Since the class is just a blueprint, and not runtime code, the class will be used to create an object whose name is not known at design time. Therefore all the “Billiard Shot” referencing described above must necessarily be relative-addressed.
Visual Classes and Forms appear nearly identical, but they are slightly different from an O-O perspective. When you DO FORM <myform.scx>, the Form is created as an instance of the class Form (unless you have specifically instructed Visual FoxPro to build the form upon a class you defined.) The objects on the form are all added to it using the ADDOBJECT( ) function. In other words, the executing form is assembled on-the-fly from parts (each an object) defined in the .SCX.
When you build a class, the entire design is instantiated with the command
x=CREATEOBJECT(<myclass>).In this case at runtime the object would have the name ‘X’, and could be addressed as x.caption, x.left, x.height, etc. Objects cannot be removed from a class or objects instantiated from it at runtime, but a form has a RemoveObject method built in. There are other differences as well. For instance, there is only one runtime entity in an .SCX, but a .VCX may contain any number of user-defined classes. There are other differences, but it is a deeper discussion than the scope of this session allows.
A Basic Strategy for a Maintainable Object Class Hierarchy
Visual FoxPro allows you to create custom classes and incorporate them into the design environment easily.
Steps to Incorporate Visual Classes into your Design Environment:
For large, complex systems, you may wish to create subclasses of all the basic Form Controls right off the bat. Then build your application with your own subclassed objects, rather than the base class controls. Why? By using your own subclassed objects, you get a single point of control to insert behaviors and attributes later that need to apply globally. For instance, you may want a company Logo on all forms. By creating a subclass of a form for the organization, you can change the logo at a later date by updating just the visual class. Since each form inherits from the class at runtime, one change propagates to the entire system. You’ll probably want to handle error trapping, font selection, and other system-wide issues the same way.
In the case of the form, what does VFP do when you issue CREATE FORM? To get VFP to use your form class, rather than the base class, return to Tools–Options. Select Form Designer, and point your way to loading your organization’s base form class and / or base formset class.
Be sure to catch sessions on the following topics necessarily given short shrift in this session:
Conclusion
As well as a nice “painter”, the Form Designer is a conceptual framework for object-oriented application development. It mates a standard Xbase data environment to a state-of-the-art object model using a beautifully engineered suite of tools. This tool is going to raise the bar once again on the scope of applications that can be delivered in FoxPro. Applications that were previously very difficult will now be easy. Many of those that were formerly impossible will now be quite achievable.
Developers will be able to mix-and-match reusable parts in FoxPro code interchangeably with OLE controls to produce beautifully integrated applications. Frameworks that provide an overall structure and architecture for application development will provide a terrific basis for application strategies in large organizations.
Downsides? A few. The impact of a deep class hierarchy on performance is still being studied. You’ll definitely need more horsepower to run this engine. Just like FoxPro 2 pushed us all over the then forbidding threshold of 4 MEG 386 machines, Visual FoxPro is going to require horsepower.
You’ll definitely need a 17” or larger monitor to develop applications effectively. (There’s no problem with running applications in 640 x 480 on any size monitor.) There are just too many tools competing for screen real-estate to make it practical to develop on a smaller screen. For those of you who are accustomed to laptop development, this will be a loss. You’re going to need a monitor to plug into.
Also, team programming is going to be tough until there’s inherent support for multi-programmer project component management. When you build a rich class hierarchy in Visual FoxPro, all the parts are connected to each other, and version management can become quite demanding.