GEOS SDK TechDocs
|
| 
3.1 Registering for System Notification
| 
3.3 Removal from a System List
MSG_NOTIFY_FILE_CHANGE, MSG_NOTIFY_DRIVE_CHANGE, MSG_NOTIFY_APP_STARTED, MSG_NOTIFY_APP_EXITED, MSG_NOTIFY_USER_DICT_CHANGE, MSG_NOTIFY_EXPRESS_MENU_CHANGE
When an identified change occurs, either the system (or a library) will call the routine
GCNListSend()
, passing it the appropriate notification message. This routine scans the list of all GCN lists and dispatches notification to all appropriate objects that had requested knowledge of the specified change. If any additional information relating to the change cannot be included in the message, the system allows
GCNListSend()
to pass data in a global heap block. For example, additional information about a file change (name of file, etc.) must be passed in a global heap block.
The object or process originally requesting notification of the change should be required to handle the appropriate message. If additional data about the change is passed in a global heap block, the process should access that information with
MemLock()
and
MemUnlock()
. You should always call the process's superclass in your message handler to make sure that the global heap block will be automatically freed by
MetaClass
. Therefore, do not free a global heap block manually in a notification handler.
The system provides several messages which you may want to handle. These messages provide notification of file system changes, application start-up or shut-down, system clock changes, etc. These messages are mentioned with the list they correspond to in Registering for System Notification . Messages which require more detailed explanation are also mentioned below.
The kernel sends
MSG_NOTIFY_FILE_CHANGE
whenever a change to the file system occurs. All objects signed up on the GCN list GCNSLT_FILE_CHANGE will receive this message.
MSG_NOTIFY_FILE_CHANGE
passes a
FileChangeNotificationType
specifying the change that occurred. Some types indicate the presence of a data block (of type
FileChangeNotificationData)
containing, if applicable, the name of the file changed, the disk handle of the file changed, and the ID of the affected file.
The notification type should be one of the following:
id
stores the ID of the containing directory; FCND_
name
contains the name of the new file or directory that was created.
id
stores the ID of the file or directory that was renamed; FCND_
name
contains its new name.
id
stores the ID of the file. FCND_
name
is undefined, and may or may not be present. (You can check the size of the block to see if it is indeed present.) This notification type is generated after a call to
FileEnableOpenCloseNotification()
.
id
stores the ID of the file or directory that was deleted. FCND_
name
is undefined and may or may not be present.
id
stores the ID of the file. FCND_
name
is undefined and may or may not be present. This notification type is generated after a call to
FileCommit()
or
FileClose()
that results in a file modification.
id
stores the ID of the file. FCND_
name
is undefined and may or may not be present. This notification type is generated upon completion of all changes in a
FileSetAttributes()
,
FileSetHandleExtAttributes()
, or
FileSetPathExtAttributes()
call.
id
and FCND_
name
are undefined and may not be present.
_id
stores the identifier of the file. FCND
_name
is undefined and may not be present. This notification type is generated only after a call to
FileEnableOpenCloseNotification()
.
FileChangeBatchNotificationData
block instead. This data block stores a batch of
FileChangeBatchNotificationItem
structures, each referring to an operation (with its own notification type, disk handle, file name, and file ID). Note that in this batched case, you must assume that all file names and file IDs that are optional (i.e. are undefined) are not present.
StandardPath
. FCND_
disk
contains the
StandardPath
that was added. This notification type is generated after a call to
FileAddStandardPathDirectory()
.
StandardPath
. FCND_
disk
contains the
StandardPath
that was deleted. This notification type is generated after a call to
FileDeleteStandardPathDirectory()
.You may access this data (after locking the block) and perform whatever actions you need within your message handler.
The kernel also sends MSG_NOTIFY_DRIVE_CHANGE to GCN lists of type GCNSLT_FILE_CHANGE. This message passes a
GCNDriveChangeNotificationType
specifying whether a drive is being created or destroyed and the ID of the affected drive.
The kernel sends
MSG_NOTIFY_APP_STARTED
whenever any application starts up within the system and
MSG_NOTIFY_APP_EXITED
whenever an application shuts down. All objects signed up on the GCN list GCNSLT_APPLICATION will receive these messages after the change occurs.
MSG_NOTIFY_APP_STARTED
passes the MemHandle of the application starting up, which you may access to perform any required actions. In a similar manner,
MSG_NOTIFY_APP_EXITED
passes the MemHandle of the application shutting down.
The kernel sends
MSG_NOTIFY_USER_DICT_CHANGE
whenever the system changes the current user dictionary in use. All objects signed up for the GCN list GCNSLT_USER_DICT_CHANGE will receive this message after the change occurs.
MSG_NOTIFY_USER_DICT_CHANGED
passes the MemHandle of the Spell Box causing the change and the MemHandle of the user dictionary being changed, both of which you may access in your message handler.
GEOS SDK TechDocs
|
| 3.1 Registering for System Notification
| 3.3 Removal from a System List