Thomas Adam <> writes:

> 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.

I'm the culprit that added module message masks.
My intent that modules could select the messages they want.

I didn't add the MX part, that must have been someone else.
Since the MX flags are in a different word, perhaps modules should be
clearing both words before they set anything.

I'm not sure why this wasn't done with one large bit mask like the style
flags were done.

Dan Espen

Reply via email to