I contacted ActiveState about an issue that I'm having while attempting to use Win32::GUI from inside an PerlCtrl created .dll component. Jan Dubois responded that the issue lies within Win32::GUI.
I've included his reply below and was curious if this is something that could be fixed in a future release. -Dave ------------------------ In case you want to take up the details with the Win32::GUI developers: Win32::GUI doesn't properly track the PERL_CONTEXT, which is essentially a pointer to the currently active interpreter structure. When a Window receives a message, Win32::GUI just assumes that it can use the currently "selected" Perl interpreter (and that there even is one). The sequence of events when using Win32::GUI from a PerlCtrl is something like this: * PerlCtrl saves old PERL_CONTEXT (probably not pointing anywhere) * PerlCtrl sets context to embedded Perl interpreter * PerlCtrl calls Perl method * Perl method creates Win32::GUI window and calls Win32::GUI::Dialog() * User clicks "Cancel" button and Win32::GUI::Dialog() returns * Perl method returns * PerlCtrl restores old (potentially meaningless) PERL_CONTEXT * PerlCtrl returns to VB * Windows dispatches another message to the Win32::GUI window GUI_MessageLoops.cpp, WindowMsgLoop() function message was WM_SETCURSOR during my testing * Win32::GUI now prepares to call back into Perl using the ENTER macro which crashes as the current PERL_CONTEXT is not defined It looks like Win32::GUI does some kind of context tracking in the PERL_OBJECT case, but that code is for Perl 5.005 only. It needs to do something similar for 5.6 and 5.8 too if you want to use it from embedded Perl interpreters. At the very least, it should *not* dispatch messages anymore after Win32::GUI::Dialog() has already returned.
