A contact from ActiveState had this to say about issues
when using Win32::GUI from a .dll created with PerlCtrl.
In case you want to take up the details with the
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
* PerlCtrl sets context to embedded Perl interpreter
* PerlCtrl calls Perl method
* Perl method creates Win32::GUI window and calls
* User clicks "Cancel" button and Win32::GUI::Dialog()
* Perl method returns
* PerlCtrl restores old (potentially meaningless)
* PerlCtrl returns to VB
* Windows dispatches another message to the
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
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
Win32::GUI::Dialog() has already returned.
Log in to post a comment.