---

os_priv::DirKeeper Class Reference

Inheritance diagram for os_priv::DirKeeper::

List of all members.

Public Types
enum	{   M_CHANGE_DIR = 1,   M_COPY_FILES,   M_MOVE_FILES,   M_DELETE_FILES,   M_RENAME_FILES,   M_ENTRIES_ADDED,   M_ENTRIES_REMOVED,   M_ENTRIES_UPDATED }
Public Methods
	DirKeeper (const Messenger &cTarget, const std::string &cPath)
virtual void	HandleMessage (Message *pcMessage)
	Handle a message targeted at this handler. More...
virtual bool	Idle ()
	Hook called each time the message queue is drained. More...

---

Member Enumeration Documentation

anonymous enum

Enumeration values: M_CHANGE_DIR   M_COPY_FILES   M_MOVE_FILES   M_DELETE_FILES   M_RENAME_FILES   M_ENTRIES_ADDED   M_ENTRIES_REMOVED   M_ENTRIES_UPDATED

---

Constructor & Destructor Documentation

DirKeeper::DirKeeper (  const Messenger & cTarget, const std::string & cPath )

---

Member Function Documentation

void DirKeeper::HandleMessage (  Message * pcMessage )  [virtual]

Description: Overload this member to dispatch messages sendt to this handler. When a looper receives a message for one of it's handlers it will call the taget handlers HandleMessage() to allow the handler to dispatch the message. The message passed in pcMessage is also available through os::Looper::GetCurrentMessage() and os::Looper::DetachCurrentMessage() until this member returns. This is normally not very usefull for HandleMessage() itself but it can be convinient for other members called from HandleMessage() in case they need data from the message that was not passed on from HandleMessage(). The looper will be locked when this member is called. The default implementation of this member will pass the message on to the next handler if one was set with SetNextHandler(). Note: Never do any lenthy operations in any hook members that are called from the looper thread if the looper is involved with the GUI (for example if the looper is a os::Window). The looper will not be able to dispatch messages until the hook returns so spending a long time in this members will make the GUI feel unresponsive. Parameters: pcMessage   The message that should be handled. This message will be deleted by the looper when HandleMessage() returns unless you detach it with os::Looper::DetachCurrentMessage(), See also: os::Looper::DispatchMessage(), os::Looper::DetachCurrentMessage() Author: Kurt Skauen ([email protected]) Reimplemented from os::Handler.

bool DirKeeper::Idle (  )  [virtual]

Description: Normally the looper thread is blocked on the internal message queue waiting for messages. When one or more messages arrive it will wake up and process the messages. When all messages is processed it will first call Idle() and then go back looking for more messages. If Idle() returned false the thread will block until the next message arrive and if Idle() returned true it will just look for new messages without blocking and call Idle() again (after processing new messages if any). Note: The looper will not be able to process new messages until Idle() returns so it is very important to not do anything lengthy if the looper is part of for example an os::Window since that will make the application feel "unresponcive" to the user. Returns: The Idle() function should return true if it want to be called again imediatly after the looper has polled for new messages, or false if it don't want to be called until at least one more message has been processed. See also: HandleMessage(), DispatchMessage() Author: Kurt Skauen ([email protected]) Reimplemented from os::Looper.

---