This section lists some common mistakes to watch for:

• When using ptype-registered patterns for autostart, make sure your executable has registered its ptype name in VkMsgApp::VkMsgApp() and that it has a non-specific action with no pattern (use VkMsgClient::createAction() instead of addAction()) to handle the request. Otherwise, ToolTalk autostarts your executable indefinitely.
• If you don't set the optional deleteMessage argument to TRUE in VkMsgClient::addAction(), you should never call VkMsgDestroy() or VkMsgDestroyRequest() in your message action.
• If you set the optional deleteMessage argument to FALSE in VkMsgClient::addAction(), you're responsible for destroying the message when you're through with it. If the message is a request, be sure to use VkMsgDestroyRequest() instead of VkMsgDestroy(). Otherwise, you may have memory heap corruption caused by double frees, if the requestor and handler are in the same process.
• You must call VkMsgClient::updatePatterns() after you use VkMsgClient::addAction(). Otherwise, your new actions have no effect.
• Anytime you go into an X event loop, messages can be received. Therefore, be careful about registering your message actions before calling VkApp::run(), or using a blocking dialog with a secondary event loop. For instance, a NetLS dialog should be used after your actions are added. Otherwise, autostart messages may not be handled properly.
• With VkMsgClient::composeAdd() routines, ensure that you call VkMsgClient::composeBegin() first to reset the state of your composed arguments. Otherwise, random arguments are added to your message.
• If you return TRUE from a message action where the reason was VK_MSG_ACTION_HANDLE, ensure that you call VkMsgReply(). Otherwise, ToolTalk assumes that your process is handling the message when in fact you never reply. The requestor waits forever for a response.

ttsession

Also, it is useful to turn on ttsession (the ToolTalk server process) debugging output. You can toggle ttsession on/off with:

kill -USR1 ${TTSessionPid}