On Fri, 13 Dec 2002 16:57:40 -0500, "Dave Crawford"
>Is there a known issue with using Win32::GUI inside a DLL created with>PerlCtrl ?
I've been looking into this and it looks like Win32::GUI is not safe to be
used from an embedded Perl interpreter (like from a PerlCtrl). It should
only be used from Perl directly (or from a PerlApp). Even there I can see
potential problems during application shutdown time, but they are probably
unlikely to occur in practice.
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
* 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
At the very least, it should *not* dispatch messages anymore after
Win32::GUI::Dialog() has already returned.