[XForms] Client Message handler success.

[Jean-Marc Lasgouttes]

>>>>> "Jeff" == Jeff  <wd4nmq at comcast.net> writes:

Jeff> Jean-Marc, Can you explain what you you mean by "breaking binary
Jeff> compatiblity"?

You add your new pointer in line 703, that is

    /* WM_DELETE_WINDOW message handler */
    FL_FORM_ATCLOSE close_callback;
    void *close_data;
/*========= HERE=============*/
    void *flpixmap;		/* back buffer             */

This is in the FL_FORM struct. This means that any program built
against version 1.0 of xforms, when it tries to access the flpixmap
member of a form, will actually access your pointer, and a crash will
occur in the best case.

This means that a program built against xforms 1.0 will not work if
xforms is upgraded. This is definitely bad, and we do such things only
if it is unavoidable.

Note however that FL_FORM ends with:

    void *attach_data;
    int no_tooltip;
    int reserved[10];		/* future use              */
}
FL_FORM;

This 'reserved' array can be used to add new entries to FL_FORM. I
would do something like

line 649:
typedef void (*FL_CLIENT_CALLBACK)(void *);

line 703:
FL_CLIENT_CALLBACK client_callback;

    void *attach_data;
    int no_tooltip;

    FL_CLIENT_CALLBACK client_callback;

    int reserved[10 - sizeof(FL_CLIENT_CALLBACK)];/* future use              */
}
FL_FORM;

I use an explicit sizeof here because I do not know what the size of a
pointer is (on a 64 bits architecture, it will be 8).

A question though is whether you need to support having a different
callback for each form. If we decide that it is only possible to
register _one_ callback for the whole app (note that the forms pointer
can be passed to the callback, so it is possible to work from that),
then the compatibility problem goes away.

I hope those explanations were useful.

JMarc