Customising Visual FoxPro base classes

When you drag a control from the toolbar to a form you are creating an object from one of Visual FoxPro's base classes. If you find that you are always having to modify these classes then you should consider setting up your own library of base classes. These classes will let you work more quickly and will also isolate you from changes that Microsoft might make to the FoxPro base classes.

Our class library

The FoxPro Component Gallery already includes a set of base classes named My Base Classes. We prefer to work with our own libraries because it means that we can make subtle differences in the components from one project to the next. As an example, We usually work with Tahoma and Courier New fonts but if a client wants to have their corporate font on the forms then we just have to alter the base classes for that particular project. We can even build a new version of the project with an alternate library to show the effect of changing the font and style of the text.

We make the following changes to the base classes:

CommandButton
.FontName Tahoma It might only be a small matter of style but the standard 'Arial' font does make a form look very old-fashioned.
.FontSize 10 Many users have less-than-perfect eyesight and they find it easier to read a slightly larger font.
.Height 27 The standard height of 17 pixels for a Command Button is just too small.
.Width 57 We design forms on a module of 30 pixels. A width of 57 pixels fits this module and allows a 3 pixel spacing. Larger and smaller buttons are 27 or 87 pixels wide.
Form
.AutoCenter .T. Put the form in the middle of the screen where the user can't miss it.
.FontName Tahoma Our standard font as above.
.FontSize 10 Our standard font size as above.
.Height 491 Most of the time we design for a standard screen size of 800x600 pixels. Not all of this height is available to the form because of the Windows status bar and the possiblility of a Terminal Services bar or an Office toolbar. The value of 491 leaves space for these and fits in with a standard progression of form sizes based on the golden ratio.
.MaxButton .F. The user gains nothing by being able to maximise the form unless we have arranged for the controls to stretch.
.MinButton .F. For most forms, there is no reason for the user to minimise them.
.ShowTips .T. We put tooltips on most controls so we want the form to permit their display.
.Width 794 Most of the time we design for a standard screen size of 800x600 pixels. The value of 794 leaves a few pixels free on each side and fits in with a standard progression of form sizes based on the golden ratio.
Grid
.DeleteMark .F. It is dangerous to leave the DeleteMark visible unless all the users know what it is and what it does.
.FontName Courier New We use a fixed-pitch font for all data entry.
.FontSize 10 Our standard font size as above.
.ReadOnly .T. We usually use grids to display data and to let the user find data. We try not to allow the users to edit data in grids because they can find it confusing.
.RecordMark .F. Removing the RecordMark gives us a bit more space on screen. Highlighting shows the user which is the active row.
.Scrollbars 2-Vertical A grid where the user has to scroll sideways is very difficult to use so we try to avoid it if at all possible.
.SplitBar .F. Like the DeleteMark, this causes more trouble than it is worth unless the users really want it and know what to do with it.
Label
.AutoSize .T. The standard label stays the same width regardless of how much text you type into the caption. It is infuriating to find that the label on screen is too small for the caption you've just typed into it.
.BackStyle 0 - Transparent A label with the standard opaque grey background only works if you you leave the background colour of the form or container at the default grey value. As soon as you change the background, you get a grey rectangle around the text. I cannot think of a situation where you would want this effect.
.FontName Tahoma Our standard font for captions as opposed to data.
.FontSize 10 Many users have less-than-perfect eyesight and they find it easier to read a slightly larger font.
TextBox
.DisabledBackColor 224,224,224 Database applications often need to show a screen full of text, none of which can be editted. The Windows standard shows disabled items as dull grey text on a dull grey background and this is difficult to read. We use a grey that is a little bit paler than standard in order to improve the contrast.
.DisabledForeColor 0,0,128 Together with the DisableBackColor property this shows disabled text in a dark blue against a pale grey background.
.FontName Courier New We use this fixed-pitch font for all data entry.
.FontSize 10 Our standard font size as above.

Adding a custom control to a form

The easiest way to add a control from your class library to a form is to simply drag it from the Classes tab of the Project Manager. Note that this is not the same operation that you use from the Form Controls toolbar. On the toolbar you click on the control that you want and then click on its position on the form. If you want a control based on a class in your class library then you click on the class in the library and drag it to its position on the form.

You can customise the toolbar so that it holds the controls from your class library rather than showing the base classes. This page shows how to add custom controls to the Visual FoxPro toolbar.

Related Items

Using a class module in Access

Using a class module in Access VBA

Read More

Example of an Access class module

Using a VBA class module to handle messagebox dialogs

Read More

FoxPro Form Controls toolbar

Showing custom controls from your VFP class library on the Form Control toolbar.

Read More

Fast lookup with a FoxPro textbox

A fast way to select data from a lookup table in Visual FoxPro.

Read More

Object parameters in VFP

Using objects to pass parameters and return values in FoxPro.

Read More