Printing - FoxTalk - dFPUG-Portal

a record in the .SCX. Two fields in the .SCX that are of interest here are the Class and Classloc
fields. By default, all forms created are based on Visual FoxPro's base class definition.
Therefore, the default values of Class and Classloc are Form and an empty string, respectively.
Assume that your class definition, called 'MyForm', is contained in 'MYLIB.VCX'. Further
assume that MYLIB.VCX is contained in the same directory as your .SCX. It's merely a task of
changing the values of Class and Classloc to 'MyForm' and 'MYLIB.VCX', respectively. When
changing the Classloc value, make sure to enter the relative path if the class library isn't in the
current directory. Finally, close the .SCX and open the form. Your form should now be
inheriting from your MyForm class.
For those of you who have the Professional Edition (and therefore the Class Browser), the
procedure is a bit simpler. First, open the Class Browser and instead of opening a class library,
open your form. Next, with the form reference highlighted in the outline control of the browser,
press the Redefine button. You'll now be presented with a dialog box to enter a class definition
and the visual class library in which the definition resides. In this example, it will be Redefine
As 'MyForm' Of 'MYLIB.VCX'. Finally, press the Redefine button to save your
changes. The form will now inherit from the 'MyForm' class.
In both cases, I encourage you to make a backup of your form so that you can recover from any
mistakes.
I have a form that uses a series of tables and views. All of the cursor objects in the Data
Environment are set to optimistic table buffering. Additionally, all of the views have the
Send SQL Updates check box checked. Whenever I make changes to a view and issue a
TABLEUPDATE() and subsequently close the form, I get an uncommitted change error
referencing the table that is associated with a view even though a TABLEUPDATE() was
issued. What could possibly be the problem?
The behavior you're encountering actually makes sense when you break the steps down. Views
will respect the buffers of the tables upon which they are based. Since the tables that your view
is based on are already open and are in optimistic buffer mode, when you update a view it
updates the underlying table's buffer, not the disk. Therefore, you must make a final pass through
your tables to commit any changes that have been made. Code similar to the following will do
the trick: (Assume the name of the view is called 'myview' and the table upon which it is based is
called 'mytable'):
BEGIN TRANSACTION
IF tableupdate(.t.,.t.,'myview') AND ;
tableupdate(.t.,.t.,'mytable')
END TRANSACTION
ELSE
** tell the user there is a problem
ROLLBACK
ENDIF