[XForms] Client Message handler success.

[Jeff]

Jean-Marc,

Ok, I see what you are saying. I thought you may have meant MS-Windows 
compatabilty somehow and just wanted it clarified.

I agree moving it to the end and taking part of the reserve would be the 
best place and I did not think of "backwards binary" compatibility. I 
will make those changes today.

On the question of each form having a client message callback I believe 
that would be the correct way to go. As I understand it, each form is a 
seperate X window. So, since XSendEvent() targets an X window, it would 
make sense for each form/window to have it's own client message callback.

This would also save the application programmer from having to decide 
which form the message is for. Plus, it would be on the developer to 
come up with a data structure member to represent the targeted form as 
XSendEvent()/XNextEvent() only contain values of the targeted display 
and window/form.

Jean-Marc Lasgouttes wrote:

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