Database development and training for Birmingham and the midlands
Specialists in Microsoft Access and Visual Foxpro database training and development
I am happy to hear from existing clients but I am taking no new calls.
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.