7/9/13

Form Designer

Form Designer
This document is reprinted from the Microsoft DevCon 95 Speaker materials and is provided "as-is." This document and any associated demo files were created using Visual FoxPro 3.0. Some features discussed may have changed in Visual FoxPro 5.0.
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: It provides a truly comprehensive event model that supports fully modeless applications It contains a robust object model for creating truly scaleable, modular, maintainable applications from reusable components It provides a design palette upon which you can seamlessly integrate objects built in FoxPro source code with OLE objects and other OLE-compliant applications on the Windows desktop. It provides a crucial set of data engine changes supporting, for the first time, data integrity constraints at the engine level, NULL support, as well as new multi-instancing and multi-user capabilities It offers greatly enhanced client-server application development facilities 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 climbthe 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. Youll 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
www.dfpug.de/loseblattsammlung/migration/whitepapers/FormDesign.htm 1/9

7/9/13

Form Designer

Orientation
For any developer who has used the Screen Builder in FoxPro 2.6, Visual FoxPros Form Designer needs no definition. However, it contains capabilities orders of magnitude beyond whats available in FP 2.6. Well start with a visual survey of all the new tools in it. Well look at how code is attached to controls, and how the typical iteration cyclecode, run, debug/trace, code some moreworks.

Controls: Something Old, Something New

Then well survey all the visual controls available for placement on forms. Many of these are familiar to you from beforebut 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. Well tour how. You can add your own properties and methods to formswell see how.

Rapid Prototyping Support

The new Form Designer vastly improves our ability to prototype applications interactively. Well 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 weve 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), youll 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, youll 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 programs 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 complexpresumably 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, youll 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. Well look at the basic mechanics, and cover the basic differences. Well explore how a starting strategy for an object hierarchy looks, and show how things are connected.

www.dfpug.de/loseblattsammlung/migration/whitepapers/FormDesign.htm

2/9

7/9/13

Form Designer

Orientation
Type CREATE FORM or pull down FILE NEW and set the type to Form. So far its just like FP 2.6, except that the keyword Form has replaced Screen. Thats where the similarity ends.

High-level overview of the Form Designer toolset

Modes: Design mode Tab Order Set mode Surfaces: Data Environment Window Properties Window Code Editor Tools: Visual Controls Color Palette Alignment Tools Assistance: Form Builder Wizard

Getting around in the cockpit

Theres a lot of stuff in here, and it would be darn near impossible to do anything productive with it if hadnt been so nicely engineered to work together so well. Tips: Use the high-level toolbar to turn on and off the three toolsets as you need them. Dock any/all four toolbars wherever you find them most comfortable (consistency will help you) You can customize the layout of each of the toolbars Use the right-mouse to drill into the design surface you need, or run the form right away Use the property sheet to fullest advantage Visual changes to the form are immediately reflected in Property Sheet and vice versa The PushPin Icon controls whether the Property Sheet is kept on top The tabs organize the properties and methods logically. A description of the highlighted property or method appears on the bottom of the property sheet
www.dfpug.de/loseblattsammlung/migration/whitepapers/FormDesign.htm 3/9

7/9/13

Form Designer

A good candidate for minimizing to clear the view The combobox at the top contains a hierarchical view of all the objects on the form or formset Properties with multiple choice options have a combobox list You can drill down further for even more assistance field picker when a data environment is active file picker expression builder an interactive object builder (you can even build your own) a design tool dialog when you see ellipses... Use the method editor for all its worth. Youll be working there a lot! Left combobox shows all the object in form or formset Arranged hierarchically just like Property Window Great for looking up object names Right combobox shows all the methods attached to this object PgUp, PgDown circles through non-empty methods for all objects Drag and drop works everywhere Within the method editor From one method to another In and out of the Command Window In and out of the Debug Window

Controls
There are a lot of controls to play with! You may feel crowded or overwhelmed by their sheer numbers until youve used each one at least once. Only then do you begin to feel like youve got an incredible arsenal of tools at your disposal.

Modes:
Point (the basic design state) Select Visual Class Library Controls (more later) Builder Lock (brings up corresponding builder when any control is placed) Button Lock (allows multiple objects to be placed. System stays in add-an-object mode.)

Controls:
www.dfpug.de/loseblattsammlung/migration/whitepapers/FormDesign.htm 4/9

7/9/13

Form Designer

Visual Object Translation Table

Object

Familiar name for 2.6ers Text

Comments

Label

You wont 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. 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.

Textbox

GET field

Editbox

Edit region

Commandbutton Push button Commandbutton Bunch of push The group-ness is achieved by wrapping the objects group buttons inside a container object. (defined as one object) Optionbutton group Checkbox Combobox List Spinner Grid Radio buttons Check Box Popup/Popdrop Two styles: One you can type into, and one that only offers choices List Spinner Mythical A whole book in itself. Go to the session. BROWSE within a READ Picture (didnt exist) (didnt exist not even close!) Animation, time-outs, and more. Finally, a comprehensive screen metaphor when theres too much complexity for a simple dialog Programmatic control of the Windows desktop go to the session Line Shape (for toolbars)Yes you can design toolbars in the Class Designer See comment for Label See comment for Label On steroids. Multiple columns, easy implementation of mover and multi-select, and more. Ditto

Picture (BMP) Timer Form Pages

OLE object Line Shape Separator

Properties and Events

www.dfpug.de/loseblattsammlung/migration/whitepapers/FormDesign.htm 5/9

7/9/13

Form Designer

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 (examplesnot 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) Scalemodescreen 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: Theres a simple mapping from FoxPro 2.6 events to the new event model.

Reality: Theres 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 shouldnt 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. Theyre 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/Ms of their own, but exist primarily to contain other objects.

www.dfpug.de/loseblattsammlung/migration/whitepapers/FormDesign.htm

6/9

7/9/13

Form Designer

Container Object Contains: Formset: Form: Commandgroup: Optiongroup Grid: Grid column: Forms Visual controls Commandbuttons Optionbuttons Grid columns 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:

< o b j e c t > . < p r o p e r t y >=< s o m ev a l u e >

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 Polym orphism . 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 UDFs.) 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 cant 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 arbitrarya 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, theres no code generation anyway, so the regeneration penalty isnt an issue. Second, code in a method isnt the same as code in a program. The keywords THIS, THISFORM, and THISFORMSET are evaluated at compile-time. They wont 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
www.dfpug.de/loseblattsammlung/migration/whitepapers/FormDesign.htm 7/9

7/9/13

Form Designer

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 = C R E A T E O B J E C T ( < m y c l a s s > ) .

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: Build your object(s) in the form designer and Save as Class for each one. Place similar designs in the same .VCX file. Pull down Options from the Tools system menu pad. Choose the Controls tab. Add your .VCXs to the controls list. Using the mover commandbuttons, select any .VCXs you wish to design with. Press the Library Books icon in the Form Designer. Select the .VCX you want to design with. Each class in the VCX is now represented by an Icon on the Form Controls toolbar. You may place these items as though they were Visual FoxPro base class objects! 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. Youll probably want to handle error trapping, font selection, and other system-wide issues the same way.

www.dfpug.de/loseblattsammlung/migration/whitepapers/FormDesign.htm

8/9

7/9/13

Form Designer

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 ToolsOptions. Select Form Designer, and point your way to loading your organizations base form class and / or base formset class. Be sure to catch sessions on the following topics necessarily given short shrift in this session: Controls Grid Control OLE controls Reusable code Class design Object-Oriented design and development

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. Youll 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. Youll definitely need a 17 or larger monitor to develop applications effectively. (Theres 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. Youre going to need a monitor to plug into. Also, team programming is going to be tough until theres 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.

www.dfpug.de/loseblattsammlung/migration/whitepapers/FormDesign.htm

9/9