Hi everybody. I'm afraid I am not only woefully unfamiliar with
Win32::GUI, but also with Microsoft Windows in general. This has not
stopped me from trying to use Win32::GUI to add a simple progress
indication to a time and compute intensive perl script I wrote that's
been embedded within an application of ours.
My question/problem may be more windows API related than Win32::GUI
related, but I'll try here first.
My use of Win32::GUI is very close to the ProgressBar sample; a new
Win32::Gui::Window call, some AddLabels, an AddProgressBar, and some
calls to the progressbar's SetPos() method. I'm using "Perl v5.8.0
built for MSWin32-x86-multi-thread" (built locally) and Win32::GUI 0.670.
I find that if I run the script using a perl interpreter I invoke from
within a "command prompt" window, everything works wonderfully.
Unfortunately, within our application, my perl script is executed by a
"ShellExecute" call in a Visual Basic Module that is executing within
the VBA interpreter inside Excel (Please don't ask why :-) and I find
that when things are executed this way, although all the Win32::GUI
calls succeed, nothing gets displayed on the screen. I imagine that this
may have something to do with the fact that the NShowCmd argument to
ShellExecute is set to SW_HIDE to keep the perl executable from
displaying its console window. I assumed that explicitly calling the
Show() method of the Windows I create using Win32::GUI would cause them
to be displayed even though the console window is not, but I'm beginning
to think that there's an inheritance relationship here that is keeping
the Win32::GUI windows from being displayed.
Does that sound reasonable to you experts? And does anyone have some
helpful advice about how I can arrange for these windows to be
displayed? I'm wildly guessing that it may require explicitly making
them children of the window that Excel owns, but I'm not exactly sure if
that's reasonable, or how I would do it.
Thanks a whole bunch for any helpful advice!
--df
