Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Buffering Architecture
Message
From
16/01/2008 08:56:02
Jay Johengen
Altamahaw-Ossipee, North Carolina, United States
 
 
To
16/01/2008 08:46:15
Hilmar Zonneveld
Independent Consultant
Cochabamba, Bolivia
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Environment versions
Visual FoxPro:
VFP 8 SP1
Miscellaneous
Thread ID:
01282147
Message ID:
01282167
Views:
9
>All your forms should be based on the same form class. Data buffering, saving and un-doing changes, should be part of this class.

How difficult is it to convert a form to use another base form?

>Your class hierarchy might look like this (parent on left, children on the right):
>
>
>Form
>|
>|--- cForm
>     |
>     |--- cDataForm
>     |--- other forms, including dialogs, reporting forms, ...
>
>
>I.e., all your forms ultimately derive from a class cForm; forms that need to manipulate data derive from cDataForm.

I think I need a bit more explanation on this part. Forms that don't use data, and those that do, are based from the one cForm? And if there are forms that use data, then those would be based from the cDataForm?

>This data form typically has methods to:
>
  • Check if there are changes to the current record (using GetFldState()
    >
  • Save changes
    >
  • Undo changes
    >
  • Go to: next record, previous record, first record, last record
    >
  • Ask for permission to go to another record or close form. This method - which might be called .CanChange() or something - will be invoked by .NextRecord(), .PreviousRecord(), etc. It will also be invoked in .QueryUnload(), if the user tries to close the form.

    Would you build navigation and add/edit/save/cancel buttons into this form, or just have methods available and design another class to do the visual stuff?
  • Previous
    Next
    Reply
    Map
    View

    Click here to load this message in the networking platform