Re: [perl-win32-gui-users] Fork?

[Glenn L. <Gle...@ne...>]

Tom Allebrandi wrote:

> With regards to fork() and Win32::GUI....
>
> I have been playing with this as well, and while I have not arrived at a
> "best practices" I have arrived at a baseline that works. Basically, I fork
> the gui thread and then send window messages to it, or, call the appropriate
> function on the window object I want to manipulate in a "classless" way.

Now this is a clever idea.  I think that for the particular application I am
working on, that
this technique, or a variation, might suffice.  Even without Timer to do
polling.

> For example, if you had created a progress bar control, you would normally
> call it using
>
>         $progressControl->somefunction();
>
> that is
>
>         $progressControl->SetPos($amount);
>
> As it turns out, and I don't know if Aldo intended for it to work this way,
> if you have a handle to the control, you can also call the routine in the
> "classless" way by doing
>
>         GUI::ProgressBar::SetPos($progressControlHandle,$amount));

Well, I suspect it was intended to work that way, because it is documented (see
the tutorial for how to eliminate the console window) that the methods can be
called on any window, using the classless technique.  Now a window created by
one thread's Win32::GUI is, to another thread, simply one of "any" windows.  But
I hadn't put that information together that way, so I appreciate your helping to
overcome my mental block.

> The latter is the way I talk to the controls from the thread that is not
> running Win32::GUI::Dialog.
>
> Right now, I am locating the window handle for the dialog itself using
> GUI:FindWindow() in the non-gui thread. I'm not happy with this approach,
> and am looking at other solutions as well.

Sure.  I wonder what would happen if a widget (progressbar or whatever) were
created before the fork, if the class handles would be active for both after the
fork?  Of course, only the thread that called Win32::GUI::Dialog would see the
messages and act on them... but that's precisely the desired behavior.  Not sure
what all sorts of timing/data race conditions doing that sort of thing would
produce, but I may experiment with it some.

> Amine Moulay Ramdane's Win32::MemMap package
> (http://www.generation.net/~aminer/Perl/) looks like the right solution for
> this, at least for me, but I had a problem with it when I tried to use it
> and ran out of time to mess with it. I know he recently posted an updated
> version, I need to pull that down and see if it still has the same problem.
>
> My initial need was to not have to use GUI::FindWindow() to locate the
> dialog and controls. My thought was to serialize a hash in the gui thread
> and pass it back to the non gui thread via shared memory - which
> Win32::MemMap provides, and unserialize on the non gui side.
>
> You can probably do something similar with pipes, but for some reason, I
> thought that the shared memory approach looked better.

Shared memory vs. pipes vs. files even -- I'm indifferent to the bulk-data
communication channel.  But the thing that had me stumped was how to get the GUI
process to "wake up and smell the roses" based on some outside event that
doesn't manifest itself as a window message to one of the window processes...
and you've relieved me of that mental block.  So, a general communication
mechanism can likely be created, at worst by creating a special widget in the
GUI to which events can be posted from a thread which has the responsibility of
monitoring the non-GUI world.

Shucks, speaking of shared memory, one could even have a hidden text widget (or
two) into which the data of interest gets sent.  Shared memory may be fastest,
of course.

> I suspect that I've rambled on enough for one day. I've included in this
> message a script for a progress bar that runs in a thread by itself taking
> positioning commands from another thread.
>
> Oh, by the way, in response to another message on the list today, I think
> Win32::MemMap has a timer implementation in it.

But is that timer integrated into Win32::GUI?  Is it clear how well it would
interact with Win32::GUI?  I'll be taking a look at MemMap.

Thanks for your response.

--
Glenn
=====
Even if you're on the right track,
you'll get run over if you just sit there.
                       -- Will Rogers