<P>
To keep Ion's code as simple as possible yet safe, there are restrictions
when the WObj
-<TT>destroy_obj</TT><A NAME="618"></A>
+<TT>destroy_obj</TT><A NAME="617"></A>
function that calls watches, the deinit routine and frees memory may
-be called directly. In all other cases the
-<TT>defer_destroy</TT><A NAME="619"></A>
+be called directly. In all other cases the <TT>mainloop_defer_destroy</TT><A NAME="618"></A>
function should be used to defer the call of <TT>destroy_obj</TT> until
Ioncore returns to its main event loop.
when the function created a frame to manage some other object but for
some reason failed to reparent the object to this frame.
</LI>
-<LI>In a deferred action handler set with
- <TT>defer_action</TT><A NAME="620"></A>.
+<LI>In a deferred action handler set with <TT>mainloop_defer_action</TT><A NAME="619"></A>.
Like deferred destroys, other deferred actions are called when
Ioncore has returned to the main loop.
</LI>
<P>
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 <TT>defer_destroy</TT>.
+immediately, use <TT>mainloop_defer_destroy</TT>.
<P>
<TR><TD ALIGN="LEFT"><TT>char*</TT></TD>
<TD ALIGN="LEFT">The string is the caller's responsibility and it
<SPAN CLASS="textit">must</SPAN> free it when no longer needed.</TD>
-<TD ALIGN="LEFT">The called function may modify the string but the ''owner'' of
+<TD ALIGN="LEFT">The called function may modify the string but the ``owner'' of
the string is case-dependant.</TD>
</TR>
</TABLE>