http://qs1969.pair.com?node_id=18591


in reply to Win32::GUI Chatterbox client

I've done some thinking about how you can avoid the locking up of the gui while the new messages are retrieved. That is, if you don't want to attempt some fork()ing and force everyone to upgrade to perl 5.6.

My solution is to separate the gui from the calls to retrieve the messages and have the messages stored in a file. Then make it so the program can be started with an argument, to tell it which mode it should start up in.

So, you would launch the program in gui mode first, then it would use the Win32::Process module to launch a second copy of itself in retrieval (non-gui) mode. So then you have 2 processes running independantly of each other, communicating via disk files.

It's a kludge, but it totally gets rid of the problem with the frozen gui. Unfortunately it requires nearly a complete rewrite of the code.

Replies are listed 'Best First'.
(jcwren) RE: RE: Win32::GUI Chatterbox client
by jcwren (Prior) on Jun 17, 2000 at 06:52 UTC
    Sure, but why not use pipes or sockets? The select statement works fine in Windows, so blocking won't be an issue.

    --Chris
[reply]
      No good reason. I could always say its so you could maintain a logfile of past chat sessions, but the truth is I'm a lot more comfortable working with files than sockets and pipes. Laziness. Go figure.
[reply]

      I'm not 100% sure about Perl 5.8, but in 5.6.1 select() only worked on socket()s, not on pipe()s.

      Jenda

[reply]
RE: RE: Win32::GUI Chatterbox client
by Shendal (Hermit) on Jun 19, 2000 at 19:01 UTC
    Interesting concept. Win32::GUI locks up during any event that Win32::Dialog() processes. I'm not sure if this will eliminate this issue, but it may reduce the amount of time that it's locked up. Let me give it a try.

    BTW, I think that Win32::Process with IPC communication is the way to go.

    Cheers,
    Shen
[reply]

In Section Code Catacombs