Tk_CreateGenericHandler(3)

💖 Tk_CreateGenericHandler(3) 💖

Tk_CreateGenericHandler, Tk_DeleteGenericHandler — associate a procedure callback with all X events. Like, every single one. 💅

Welcome to the Tk Library Procedures manual, bestie. We’re doing the Tk_CreateGenericHandler(3) page today, and it’s giving “I want to know about every event” energy. ✨

✨ SYNOPSIS ✨

#include <tk.h>

Tk_CreateGenericHandler(proc, clientData)

Tk_DeleteGenericHandler(proc, clientData)

🎀 ARGUMENTS 🎀

• Tk_GenericProc *proc (in) — the procedure to invoke whenever any X event occurs on any display. That’s the whole job. 🫶
• void *clientData (in) — an arbitrary one-word value to pass to proc. One word. No cap. 💬

🦋 DESCRIPTION 🦋

So Tk_CreateGenericHandler arranges for proc to be invoked in the future whenever any X event occurs. It’s giving “I’m watching everything,” and honestly? Iconic. ✨

⚠️ But listen: this mechanism is not intended for dispatching X events on windows managed by Tk. For that, you should use Tk_CreateEventHandler instead. Periodt. 💅

Tk_CreateGenericHandler is intended for other purposes, such as tracing X events, monitoring events on windows not owned by Tk, accessing X-related libraries that were not originally designed for use with Tk, and so on. Very “I’m just observing, bestie” energy. 👀

The callback to proc will be made by Tk_HandleEvent. That means this mechanism only works in programs that dispatch events through Tk_HandleEvent — or through other Tk procedures that call Tk_HandleEvent, such as Tcl_DoOneEvent or Tk_MainLoop. No event dispatch through those paths, no callback. Simple as that. 🌀

proc should have arguments and result that match the type Tk_GenericProc:

typedef int Tk_GenericProc(
        void *clientData,
        XEvent *eventPtr);

The clientData parameter to proc is a copy of the clientData argument given to Tk_CreateGenericHandler when the callback was created. Typically, clientData points to a data structure containing application-specific information about how to handle events. eventPtr is a pointer to the X event. 🎯

Whenever an X event is processed by Tk_HandleEvent, proc is called. The return value from proc is normally 0. A non-zero return value indicates that the event is not to be handled further — that is, proc has done all processing that is to be allowed for the event. So 0 is the usual return; non-zero is the stop sign for further handling. 💀

If there are multiple generic event handlers, each one is called for each event, in the order in which they were established. First come, first called. Line up, besties. 🎟️

Tk_DeleteGenericHandler may be called to delete a previously-created generic event handler: it deletes each handler it finds that matches the proc and clientData arguments. If no such handler exists, then Tk_DeleteGenericHandler returns without doing anything. It’s not dramatic about it. 🙈

Although Tk supports it, it’s probably a bad idea to have more than one callback with the same proc and clientData arguments. Like, technically allowed? Yes. Recommended? Absolutely not, bestie. 🚩

Establishing a generic event handler does nothing to ensure that the process will actually receive the X events that the handler wants to process. For example, it is the caller’s responsibility to invoke XSelectInput to select the desired events, if that is necessary. So don’t just set up the callback and assume the events will show up — you gotta do your part. 💪

🌈 KEYWORDS 🌈

bind, callback, event, handler

---

Okay bestie, that’s the whole page. Footer sign-off: source/version is Tk, page is Tk_CreateGenericHandler(3), and this footer doesn’t show a date. Byeee 💜🦋