use Win32::GUI;

$Win = new Win32::GUI::Window(
      -left   => 341,
      -top    => 218,
      -width  => 300,
      -height => 191,
      -name   => "Win",
      -text   => "Window Title"
      );
$Win->Show();

$Win->AddLabel(
       -text    => "Test",
       -name    => "Test",
       -left    => 121,
       -top     => 72,
       -width   => 49,
       -height  => 16,
       -foreground    => 0,
      );

$Win->AddButton(
       -text    => "Do it",
       -name    => "doit",
       -left    => 100,
       -top     => 90,
       -width   => 65,
       -height  => 24,
      );

Win32::GUI::Dialog();

sub doit_Click {
$t1 = $Win->AddTimer('T1', 10);
}

sub T1_Timer { # This gets called over and over again
    $i++;
    $Win->Test->Change(-text => "$i");

# You can put code here to read
# from a line from a socket or file
# and the GUI won't freeze up.

}
[download]

Hmm, it looks promising... but I really can't tie up the users internet connection like that (constant polling)...


-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GIT d- s:++ a--- C++++ UL P+++>++++ L+ E- W++>+++ N !o K- W+ O---- M-- V--
PS PE Y- PGP t++(+++) 5(+++)++++ X R+@ tv+ b+++ DI+ D- G e->+++ h! r-- y-
------END GEEK CODE BLOCK------
Translate

"Weird things happen, get used to it."

Flame ~ Lead Programmer: GMS

Although I'm not sure what you're trying to do, you don't have to constantly poll. Maybe something like this pseudo-code:

On button click->add timer to do subroutine A.

sub A() {
    if(socket != EOF)
      { open socket, read line. }
    else
      { kill timer. }
}
[download]

Hope this helps.

C:\windows>perl -V
Summary of my perl5 (revision 5 version 6 subversion 0) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef use5005threads=undef useithreads=define usemultip
+licity=def
ine
    useperlio=undef d_sfio=undef uselargefiles=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=u
+ndef
  Compiler:
    cc='cl', optimize='-O1 -MD -DNDEBUG', gccversion=
    cppflags='-DWIN32'
    ccflags ='-O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_D
+ES_FCRYPT
 -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DPERL_MSVCRT_READFIX'
    stdchar='char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
+ lseeksize
=4
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -release  -libpath:"E:\
+Perl\lib\C
ORE"  -machine:x86'
    libpth="E:\Perl\lib\CORE"
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
+  comdlg32
.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib uui
+d.lib wsoc
k32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib msvcrt.
+lib
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl56.lib
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release  -l
+ibpath:"E:
\Perl\lib\CORE"  -machine:x86'


Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY USE_ITHREADS PERL_IMPLICIT_CONTEX
+T PERL_IMP
LICIT_SYS
  Locally applied patches:
        ActivePerl Build 623
  Built under MSWin32
  Compiled at Dec 15 2000 16:27:07
  @INC:
    E:/Perl/lib
    E:/Perl/site/lib
    .
[download]

It's compiled to support "ithreads" (interperator threads), which are currently under development. The "Thread" module is for 5.005-style threads, which are not ithreads. 5.005-style threads are being abondoned, apparently because they create race conditions that cannot be resolved efficiently. I would advise against their use. If you are interested, there is an experimental "threads" module for ithreads access from perl code.

The primary reason that it has threading support is to support forking emulation, because Windows does not have a OS-level fork call. (See perlfork.) You should be able to access threads this way, but beware that Win32::GUI might have some problems if you spawn threads while it's objects are in scope because it's (XS-based) destructors could be called prematurely, or twice. update: (These problems may occur if you merely have such objects in exsitence at time of forking, even.)

Well, since you don't recomend threads, can you suggest a method to allow the program to send/rescieve the data necessary without locking up? Is it possible to do it with fork? If you have any potential solution, please explain it in detail... I'd like to learn, instead of just have the answer handed to me.

Thanks


-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GIT d- s:++ a--- C++++ UL P+++>++++ L+ E- W++>+++ N !o K- w+ O---- M-- V--
PS PE Y- PGP t++(+++) 5(+++)++++ X R+@ tv+ b+++ DI+ D- G e->+++ h! r-- y-
------END GEEK CODE BLOCK------
Translate

"Weird things happen, get used to it."

Flame ~ Lead Programmer: GMS