when the \type{WObj}
\code{destroy_obj}\index{destroy-obj@\code{destroy_obj}}
function that calls watches, the deinit routine and frees memory may
-be called directly. In all other cases the
-\code{defer_destroy}\index{defer-destroy@\code{defer_destroy}}
+be called directly. In all other cases the \code{mainloop_defer_destroy}%
+\index{mainloop-defer-destroy@\code{mainloop_defer_destroy}}
function should be used to defer the call of \code{destroy_obj} until
Ioncore returns to its main event loop.
that wants to get rid of the object. This is the case, for example,
when the function created a frame to manage some other object but for
some reason failed to reparent the object to this frame.
- \item In a deferred action handler set with
- \code{defer_action}\index{defer-action@\code{defer_action}}.
+ \item In a deferred action handler set with \code{mainloop_defer_action}%
+ \index{mainloop-defer-action@\code{mainloop_defer_action}}.
Like deferred destroys, other deferred actions are called when
Ioncore has returned to the main loop.
\item You are absolute sure that C code outside your code has no
If there are no serious side effects from deferring destroying the
object or you're unsure whether it is safe to destroy the object
-immediately, use \code{defer_destroy}.
+immediately, use \code{mainloop_defer_destroy}.
\subsection{The types \code{char*} and \code{const char*} as function
parameters and return values}
For further reference a copy must be made. \\
\code{char*} & The string is the caller's responsibility and it
\emph{must} free it when no longer needed. &
- The called function may modify the string but the ''owner'' of
+ The called function may modify the string but the ``owner'' of
the string is case-dependant. \\
\end{tabularx}