[ I've added a note to myself to look for all the places that we use dTHX and to ensure that they are necessary - I think they are used when we get a win32 api callback such that we can't use the NOTXSPROC calling convention ]
I'm still not 100% sure how the context works within Win32-GUI but there might be a problem when Win32-GUI is used in a threaded app, where you want different threads to deal with different windows (see AttachThreadInput method in the docs).
As I understand things, we're storing the context in PERLWIN32GUI_USERDATA via the macro PERLUD_DECLARE and we're fetching the context via the macro PERLUD_FETCH. As we're fetching the context everytime we're doing an event, we are *always* using the perl interpreter that created the window, rather than the context that is associated with the current running thread.
I'm not to sure what the solution could be, as I understand things you can't pass sub refs around perl threads, which means that NEM would be broken (i.e., thread A creates the window and the sub refs for the events, but you need thread B to respond to events for the window created by A). From very bitter experience, Perl 5.6 and most 5.8.x (5.8.7 seems ok) threading at the deep perl level is broken.
Cheers, jez.
