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.