| Two Approaches to Working with dataform1 | ||
|---|---|---|
 | Chapter 23. Using Data-Aware Forms in SIMPOL |  |
Two Approaches to Working with dataform1
The basic approach to working with data-aware forms in systems like SIMPOL or Superbase, is to lock a record prior to modification, allow the user to edit the record, and then save the record (unlocking it in the process) or to unlock the record (as a result of selecting another record). Systems that do not implement record locking (or that can not use it efficiently) such as most SQL database systems, take a different approach. They allow the user to make changes to a record, and then only when the time comes to commit the changes, they lock the record, check to see if it has changed since it was originally read, and if not, they commit the changes and unlock the record. The problems begin to arise if the record has changed in the interim.
In this section, we will stick to the former style of working, but even that has two different approaches. One is to use the auto-locking approach (the default in dataform1), the other is to use the explicit locking approach. Sophisticated systems (and especially multi-user systems) are likely to require the explicit approach. Let's have a look at each one in more detail.
Auto-locking
This is the easiest approach, since it just works. If the user clicks on a control that is not read-only or
disabled, the control receives focus. If the user changes the content, when the focus leaves the control, the
dataform1 system will attempt to lock the record. When the user saves, then everything is automatically
committed. If the user goes elsewhere, the changes to the record will be discarded, it is up to the programmer
to check to see if the record needs saving. This is integrated into the
appframework.sml functionality, see the later section for more
information. It is important to note, because of a curious issue with the wxWidgets library, the SIMPOL
wxform.clearfocus() method has a quirk. Even though it clears focus from
the form, wxWidgets stores the control that previously had focus. If the user then tabs away and tabs back
again, the previous control to have had focus will have it again. We are looking into this with a view to
changing that behavior, but until then it is important to consider what impact that may have on your application.
Auto-locking
An alternative approach, necessary to anyone who intends to provide user-level access control methods, is
explicit locking. To use this, the dataform1 object has auto-locking turned off, and the
prevent focus functionality enabled. This means that when the user attempts to place focus
on the form, it fails, although buttons can still be pushed. The correct approach might look like this, where
the variable f contains a dataform1 object:
// after opening the form using appwindow.openformdirect()
f.autolocking = .false
f.preventfocusmode = .true
f.preventfocus = .true
Once this has been set up, the appframework.sml library and
the dataform1 package will handle the rest. When you wish to allow editing, for example via a menu
or tool bar event, calling the modifyrecord() function will allow the user to change the data on the
form. Once the form is saved, the dataform1 object will once again prevent focus on the form.