Hi all,

I thought I understood the nature of registering and receiving MX_* module
packets, but I don't, so I'm hoping someone here will have the answer I'm
looking for.

I'm writing a C module for fvwm, and am amalgamating the different packet
types in a table such as the following:

        struct fvwm_event {
                const char      *event;
                unsigned long    flag;
        } fe[] = {
                {"new_window", M_ADD_WINDOW},
                {"configure_window", M_CONFIGURE_WINDOW},
                {"new_page", M_NEW_PAGE},
                {"new_desk", M_NEW_DESK},
                {"enter_window", MX_ENTER_WINDOW|M_EXTENDED_MSG},
                {"leave_window", MX_LEAVE_WINDOW|M_EXTENDED_MSG},
        };

In matching the events against the table above, I've deliberately added in
M_EXTENDED_MSG for the MX_* events because this allows me to separate out the
two distinct calls to SetMessageMask().  Hence:

        unsigned long non_mx_events;
        unsigned long mx_events;

        non_mx_events |= M_ADD_WINDOW|M_NEW_DESK;
        mx_events |= flag & ~M_EXTENDED_MSG;

        SetMessageMask(fvwm_fd, non_mx_events);
        SetMessageMask(fvwm_fd, mx_events);


I believe I'm right in saying that fvwm expects to receive two distinct calls
as above.

This is working except that when receiving the packet from fvwm, I'm finding
that the MX_* events are also matching non-MX events.

For example, just requesting MX_ENTER_WINDOW means I end up receiving an event
for M_NEW_DESK as well.  This makes some sense, since M_NEW_DESK is defined as
1<<1, and MX_ENTER_WINDOW is also defined as 1<<1 | M_EXTENDED_MSG.  It's
almost as if I've made a mistake with M_EXTENDED_MSG somewhere.  But it's
implied when using MX_*.

I've looked at other examples in fvwm such as FvwmAnimate, FvwmAuto, and none
of them are doing anything different to MX_* packet handling, to what I'm
trying to do.

If anyone has any thoughts, I'd appreciate it.

Kindly,
Thomas

Reply via email to