|Present a record list|
|Allow edition, selection and other actions. The record list is presented as multi-column. It is refreshed as needed whenever a member change somewhat.|
|void add ()|
|void clickhead (int column, UISTATE &state)|
|void editone (int no, UISTATE &uistate)|
|void guidialog ()|
|void head ()|
|void load (int column, SORT_ORDER order)|
|void message ()|
|void otherbuttons (MENU_STATUS code, int id)|
|void pickone (int no, UISTATE &uistate)|
The addwhat() fhelper controls the presence of the Add button. Whenever Add is selected, this functag is called.
The editrecords works in graphical, text and html mode. In GUI mode more complex dialog may be created. The gui_passthrough(), newf_clist() and the various new_button() fhelpers are used.
The records are presented in tabular form. You generally use the newf_head() fhelper function to setup the heading. You also use various other helpers to setup extra buttons and dialog attributes
The new_menuitem() fhelper function is used to define the content of the table. You generally do the sorting here as well.
The functags generally used the dialog_testmessage() to check which message was received.
You can defined arbitrary buttons in the editrecords dialog.
Unlike the editone() functag, editrecords ends after this call. So pickone is used to select a single item and then goaway. So pickone or editone are never used together.
The function also triggers the presentation of the Add button. Editrecords normally does not put a Add button. You need the add() functag to tell when the add button has been used.
You use the otherbuttons() functag to process the Del button.
Generally called from an editone(), add(), otherbuttons() and message() functag. The dialog will end after that.
The sort is generally controlled internally by editrecords. So if an application wishes to provide navigation button to jump to the next record, it uses this
The sort is generally controlled internally by editrecords. So if an application wishes to provide navigation button to jump to the previous record, it uses this
Used in the guidialog() functag to create more complex dialogs.
You create a new button and assign it some ID. The otherbuttons() functag will be called with this ID whenever the button is depressed.
Like new_button, you assign some ID and process the event with otherbuttons() functag. This is used in the guidialog functag
Use a printf syntax to define one line of the table. The various columns are separated by tabs.
This is used in the guidialog() functag to define a check-box UI element.
This is used in the guidialog functag, to position the list within the other UI components
This is used in the guidialog functag to define a text field UI element
This is used in the guidialog functag
This is generally used in the guilayout() functag, when we take over button placement.
This column will become the key. If it was already the sort, the order is changed. This function is the default behavior when the clickhead functag is not used.
This is generally used during the edit cycle to change the label of a button, ot reflect a different action. The button was defined using the new_button() fhelper.
The button was defined by new_button_icon().
editone and pickone functag are passing a parameter "no" telling you which record was selected. This may not correspond to the array you used in the load functag. For example, you may have done some filtering and only few entries have been "loaded". set_lookup() tells editrecord what is the real index (in your own table) of the last new_menuitem(). editone and pickone will then pass index in "your word"
editone and pickone functag are passing a parameter "no" telling you which record was selected. This may not correspond to the array you used in the load functag. For example, you may have done some filtering and only few entries have been "loaded". set_lookup() tells editrecord what is the real key (in your own table) of the last new_menuitem(). editone and pickone will then use get_lookup(no) to retrieve the key meaningfull in "your world"
Normally a dialog is either swallowed in a multi-document interface if one is defined, or standalone. You control where it may be swallowed. The parameter is generally received from a more complex dialog.
This allows you to select a different font, pen and brush to draw the records. See guiid_setdc(). guiid_setfont(), guiid_setpen(), and guiid_setbrush()
For each column, you specify, using letter l,c or r, if it is left aligned, centered or right aligned.
You use this function to specify that the next record (new_menuitemf()) will be shown in bold (marked)
Generally used to request a popup
A vertical scroll bar is automatically placed when the list grow to a certain size. You can control this size
The user may click on the heading and sort according to the column. The application may also react differently if the user uses different mouse buttons. sortable() is implied by sortpolicy(). So most dialog will only set the sort policy and let editrecords handle the sorting. Now if you need custom sorting, call sortable() and not sortpolicy() and handle the sorting in the load functag.
This is generally used with contextual menu to force a particular column ordering.
This tells editrecords it is responsible for sorting. For each column letter a or n specify if sorting is alphabetic or numeric.
The message() functag will be called whenever this messages is sent.