There are a few things you must to know before you will be able to succesfully adapt a VFX application or even a single form to your needs. Here you find the summary which helps you to recognize features as such before they become a problem during your development cycle.
This property defines in which state the form currently is. If the user selects Edit from the Edit menu (CTRL+E) the form switches to edit mode. You will note this also in the form caption. Since VFX 5.0 you can decide how it's possible for the user to switch to the edit mode. If you set the form property lAutoEdit to .T. or force the auto edit feature through the application class property nAutoEdit to 1, the user can enter into edit mode by simply writing into any textbox of your form or making a change with a combobox or accessing the picklist withing a pickfield control or touching any other control you may have on your form.
This property defines whether a control will be synchronized automatically with the form status or not. Note that you have to set this property to .F. whenever you use a control where you want to control the enable status or where the control has to be always accessible.
This new property defines whether the control will automatically be synchronozed with the windows system colors or not. Be sure to set this property to .F. whenever you want to control the colors independantly from the current windows user settings!
VFX makes extensive use of the inheritance feature offered within the OOP design of VFP. This feature gives the ability to inherit code from one parent class to the subsequent subclasses. Be sure to call the parent class code for following core events of your controls whenever you touch them:
GotFocus Event, Init Event, Interactive Change Event, LostFocus Event, Refresh Event
If you put code in one of these VFP events make sure to call the parent class code with either dodefault() (use in VFP 5.0 or above only and only if not in a container class hirarchy!) or i.e. cTextbox::GotFocus for the textbox, CSpinner::GotFocus for the SPinner, ...
If you brake the inheritance by overwriting these methods in your controls, the VFX framework will no more work as expected!
Make sure to understand that calling the parent class code with dodefault() calls always the parent class code of the control which is usually not what you want if you are in a container! Let's look at a simple example here within the pickfield class. Note however that this discussion applies also to your own class library constructions and is VFP independent and therefore applies to all languages where inheritance is offered (probably that's the reason why VB does not have this sort of inheritance even not in Version 6.0...):
The pickfield class is a container class which consists of the following components directly placed in a main container:
txtField , the textbox where you can enter the code
cmdPick , the commandbutton to click on to get the picklist appear and the
txtDesc , the description textbox
Assume you want to modify the RightClick Event which is in the txtDesc Textbox but you dont want to loose the functionality which VFX provides when you RightClick on the description of the txtDesc Textbox. If you would place the following code in the RightClick Event of the txtDesc Textbox, the VFX inheritance would fail:
** custom code goes here
**
dodefault()
This would fail since the above dodefault() statement would call the RightClick Event of the cTextbox Class which is definitively not what we want here! The right code would be:
** custom code goes here
**
CPickField::txtDesc.RightClick()
This very simple example shows one important aspect of the Inheritance feature in OOP when dealing with a container ship hierarchy. Be carefull when calling the parent class code in a container class construction!
If you did not fully understand this discussion you can still work with VFX. Just make sure not to touch methods and events which are members of container classes as the PickField.
Good practice is to have a look at the VFX code before you put any code into Methods or Events to fully understand what VFX would do if you would not put any code in the corresponding Method or Event.
A. Make sure to fully understand the VFP (NOT VFX!) implications of IDX files: IDX files cannot be part of transactions. Whenever you issue a BEGIN TRANSACTION, you must make sure that all IDX files are closed first, otherwise a runtime error occurs. Thats's why we call the ClearAllIDX() method anytime we issue an edit or insert operation because database triggers like to start with the statement BEGIN TRANSACTION!!!
B. Also if you have in whatever form (also when private datasessions are used!) a table buffering mode (5) of a specific table, your program will crash whenever you try to create an IDX file on this table even in another form! When you are unable to make sure that your table is never used in table buffering mode, make sure that you have enough CDX tags in order to prevent VFX from creating temporary index files, or select no incremental search in the Grid Builder for the columns where no CDX exists!
Some properties and methods are just mentioned and not yet explained in the
final way. Please verify these by looking into the VFX source code before using
them. Especially before calling support regardless
whether it is free or not, it is mandatory that you look in the source code!
Additional sources are also the update an release notes as well as the
changesX.rtf document on our download site at
http://www.visualextend.com. Thank you for your cooperation.