|
DaoServer:Notify() Method |
  
|
|
DaoServer:Notify() Method |
|
Purpose
An event handler that responds to events that have occurred in methods of this server, or in other servers that are linked to this server in some way. The standard implementation notifies all the server's clients of the event.
Important! This method is automatically called by the various action methods of the data server, and should normally not be called by application code.
Parameters
| kNotifyName | Identifies the event, specified as one of the following constants: |
| uDescription | Used only with some notification types, as described below. |
| Constant | Refers To |
| NOTIFYAPPEND | A blank record has been appended; the server is still positioned on this record, and its values have not been finalized. |
| NOTIFYCLEARRELATION | A relation between servers is being cleared |
| NOTIFYCLOSE | The server intends to close itself. |
| NOTIFYCOMPLETION | The server has completed some large operation that did not involve repositioning of the server or change to the data (such as reindexing). This gives the browser a chance to update visual indication to the user that some operation has been completed. In this situation, <uDescription> is the name of the method that was just completed, as a symbol. |
| NOTIFYDELETE | The current record has been deleted, and the server is now positioned according to its rules for how a deletion is handled. The clients should refresh their displays accordingly. |
| NOTIFYFIELDCHANGE | A field has changed. <uDescription> is the field name as a symbol. Note that some clients may not have a field with the indicated name: the server knows only that it has a field of that name and that it changed, and it notifies its clients in case they are interested. |
| NOTIFYFILECHANGE | The server has executed some method that perform many changes to the data; all the clients' knowledge about the server and its data is potentially obsolete, and they should refresh all information from the server and all calculations that depend on the data or its position. |
| NOTIFYGOBOTTOM | The server has moved to its last record. Many clients treat this merely as a record change, but for some types of clients positioning to the end is treated as a special case. |
| NOTIFYGOTOP | The server has moved to its first record. Many clients treat this merely as a record change, but for some types of clients positioning to the top is treated as a special case. |
| NOTIFYINTENTTOMOVE | The server intends to make a move. The clients should make sure that all their data is saved, if necessary, before the movement is done. In the data window and data browser, the standard implementation checks validation status: if the client contains data that is invalid, the user has a choice of correcting the errors or discarding the data. |
| NOTIFYRECORDCHANGE | The record position of the server has changed. <uDescription> might indicate the length of the move (the number of records). The clients can use this information for display optimization, but cannot rely on its availability. |
| NOTIFYRELATIONCHANGE | The server has been made the child in a relation with another server, or the parent in a relationship has repositioned itself. All information about the server is potentially obsolete. |
Returns
NIL except if NOTIFYINTENTTOMOVE is specified for <kNotifyName>.
In this case, the return value is TRUE if successful; otherwise, FALSE.
Description
This method is at the heart of the automatic notification among linked windows and servers. When certain actions are performed on a data server, the methods that perform those actions automatically call their Notify() method upon completion of the action. The data server then sends a broadcast Notify message to all of its clients to notify them of the action.
This ensures that all clients (for example, data windows or data browsers) remain in sync with their underlying servers and reflect the change (for example, update a field value or add a new record).
Any class that is registered as a client of a server must respond intelligently to these Notify messages.
In some cases, the notification may come from another object rather than from a method of the same server object. Relations among servers, for example, cause file change notifications to be sent from the parent to the child server.
As always with defined constants, you should never rely on the actual values of the constants--they will not necessarily stay the same. However, the constants do maintain their order:
| Constant | Value Level |
| NOTIFYFIELDCHANGE | Lowest |
| NOTIFYCLOSE | ... |
| NOTIFYCOMPLETION | ... |
| NOTIFYINTENTTOMOVE | ... |
| NOTIFYRECORDCHANGE | ... |
| NOTIFYGOBOTTOM | ... |
| NOTIFYGOTOP | ... |
| NOTIFYDELETE | ... |
| NOTIFYAPPEND | ... |
| NOTIFYFILECHANGE | ... |
| NOTIFYRELATIONCHANGE | ... |
| NOTIFYCLEARRELATION | Highest |
Thus, you can reliably write:
IF kNotifyName > NOTIFYINTENTTOMOVE;
.AND. kNotifyName < NOTIFYFILECHANGE
... // Only record level moves
ENDIF
Class