Re: [perl-win32-gui-users] cygwin (was newbie query)

2001-01-09 Thread Aldo Calpini 
Aldo Calpini wrote:
> I am also trying to fool around with cygwin, but I didn't
> even could produce a working Perl build :-(

well, I finally solved the problem, it was really a WKP
(Well Known Problem :-).
if anybody it's interested, the solution is available at:

http://sources.redhat.com/ml/cygwin/2000-08/msg00256.html

you need to download dll_entry.o, then do:

ar cru /usr/lib/libcygwin.a dll_entry.o
ranlib /usr/lib/libcygwin.a

then rebuild perl, and everything goes smooth :-)

I'll try to work on porting Win32::GUI under GCC (if time
permits).


cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

[perl-win32-gui-users] Re: [perl-win32-gui] Event processing

2001-01-09 Thread Eric Bennett 
On Wed, 3 Jan 2001, Robert Sherman wrote:

> sub Loop_Click {
>   while ($i<20) {
>   sleep 1;
>   if ($i==10){
>   &Show_Win2($i);
>   }
>   $i++;
>   }
> }

One way to do this is to use a timer:


# Warning: Untested code

my $loop_counter;
my $LoopTimer = Window->AddTimer("LoopTimer", 0);

sub Loop_Click {
   $loop_counter = 0;
   $LoopTimer->Interval( 1000 );
  # Use a short interval if all you want is event procesing.
  # Here the 1000ms interval substitutes for your sleep 1.
}

sub LoopTimer_Timer {
   &Show_Win2( $loop_counter )  if $loop_counter == 10;
   ++$loop_counter;
   $LoopTimer->Kill() if $loop_counter >= 20;
}


If you have a lot of loop state and you don't want it all at file level
you can also use a closure.  This has a side effect of making the timer
generic.


# Warning: Untested code

my $loop_body;
my $LoopTimer = Window->AddTimer("LoopTimer", 0);

sub Loop_Click {
   my $loop_counter = 0;

   $loop_body = sub {
  &Show_Win2( $loop_counter )  if $loop_counter == 10;
  ++$loop_counter;
  $LoopTimer->Kill() if $loop_counter >= 20;
   }

   $LoopTimer->Interval( 1000 );
}

sub LoopTimer_Timer {
$loop_body->();
}


This could be done very nicely with perl-level threads. (i.e. one at a
time but with multiple call stacks where one could pass control to
another)

   - Eric B.

--
"An intelligent carrot!  It boggles the mind."

[perl-win32-gui-users] Listbox or Combobox style options

2001-01-09 Thread Joel Oliveira 
Hello all,

I need a listbox similar to the HTML one. Read only, only one selection and
with a "drop list with vscroll".
I tried the next code, but a can't get the "drop" style to work...
$WD->AddListbox(-text=>'&Month',-name=>'Month',-left=>106,-top=>88,-width=>6
5,-height=>20,-multisel=>0,-style=>WS_VISIBLE|WS_VSCROLL);


Joel Oliveira

[perl-win32-gui-users] a simple question

2001-01-09 Thread christopher sagayam 
how to set the name of a dialog box dynamically ?

$ModuleWindow = new Win32::GUI::DialogBox(
-title   => "old title",
-left=> 100,
-top => 110,
-width   => 500,
-height  => 400,
-name=> "ModuleWindow",
-style   => WS_BORDER
  | DS_MODALFRAME
  | WS_POPUP
  | WS_CAPTION
  | WS_SYSMENU,
-exstyle => WS_EX_DLGMODALFRAME
  | WS_EX_WINDOWEDGE
  | WS_EX_CONTEXTHELP
  | WS_EX_CONTROLPARENT,

);


I need to do

$ModuleWindow->title("new title");




chris




_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

RE: [perl-win32-gui-users] Listbox or Combobox style options

2001-01-09 Thread Joel Oliveira 
Done... I just RTFM and the FAQs and I found the answer. _:)
Thanks all.

Joel Oliveira



# -Original Message-
# From: [EMAIL PROTECTED]
# [mailto:[EMAIL PROTECTED] Behalf Of
# Joel Oliveira
# Sent: terca-feira, 9 de Janeiro de 2001 12:56
# To: perl-win32-gui-users@lists.sourceforge.net
# Subject: [perl-win32-gui-users] Listbox or Combobox style options
# 
# 
# Hello all,
# 
# I need a listbox similar to the HTML one. Read only, only one 
# selection and
# with a "drop list with vscroll".
# I tried the next code, but a can't get the "drop" style to work...
# $WD->AddListbox(-text=>'&Month',-name=>'Month',-left=>106,-top=>88
# ,-width=>6
# 5,-height=>20,-multisel=>0,-style=>WS_VISIBLE|WS_VSCROLL);
# 
# 
#   Joel Oliveira
# 
# 
# 
# 
# ___
# Perl-Win32-GUI-Users mailing list
# Perl-Win32-GUI-Users@lists.sourceforge.net
# http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
#

Re: [perl-win32-gui-users] Memory leak (not really a leak at all)

2001-01-09 Thread Aldo Calpini 
Sam wrote:
> Hi,
>
> I found many references to the 'memory leak' in the archived 
> messages at http://www.mail-archive.com/perl-win32-
> [EMAIL PROTECTED]/.

> I believe there isn't a memory leak at all, it appears that the 
> memory usage reported by windows task manager includes a 
> portion of a windows cache allocated to the program, and that it's 
> the cache usage that changes, not the amount of memory that the 
> perl interpreter has allocated.

oh well, I'm really confused now :-)

> This is based on these observations:
> 1)  As the memory usage reported by the task manager increases 
> the total memory usage does not increase. If you run a compiler or 
> something that will allocate memory a bit at a time for a long period 
> of time you'll notice that as the compiler's memory usage goes up, 
> and so does the total memory usage.

yes, this is true.

> 2)  If you minimize the perl-win32-gui app's window the reported 
> memory usage goes down to a base value (120K with my perl), and 
> every time you minimize the window it goes down to the same 
> value. This is _not_ indicative of a memory leak.

this is true too.

> 3)  If you play with other applications in a similar way you
> can make them exhibit similar behaviour. The reported memory usage
> on other applications (my test was EditPlus) doesn't increase to 
> the same extent, but it does increase (more on this difference later).

and this is true, but there are other applications (for example,
the NT Task Manager) which does not exhibit this behaviour, even
if they're left running for a large amount of time. and the Task
Manager updates its contect each second, so is doing something.
but its cache memory never grows up. damn :-(

> During the above I looked over the code involved, and attempted
> to isolate a memory leak. So far as I can tell the code is rock
> solid.

way cool ;-)

> I believe that the difference between a perl-win32-gui application, 
> and other pure win32 applications is in the DefWindowProc 
> handling. The perl-win32-gui module does call DefWindowProc 
> when either you don't have a handler installed, or you return 1, 
> however through BoundsChecker I believe that this may not always 
> be the case.

I'm really interested in this: can you elaborate more on this
point? do I call DefWindowProc too much, or it is not called
when it should be?

> I would be interested if someone finds anything else out about
> this problem. Unfortunately I can't spend any more time on this,
> as it appears to me that this isn't a serious bug, at least not
> something that will stop a program from working correctly.

well, a 4k increment for each mouse movement is quite too much,
so something should be corrected (if it's not totally wrong, it's
surely at least poorly coded :-)

cheers,
Aldo

__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;

Re: [perl-win32-gui-users] a simple question

2001-01-09 Thread Jeremy Blonde 
If I'm not mistaken, it should be like this:

$ModuleWindow->{-title} = "New Title";

Jeremy Blonde
[EMAIL PROTECTED]

--- christopher sagayam <[EMAIL PROTECTED]>
wrote:
> 
> how to set the name of a dialog box dynamically ?
> 
> $ModuleWindow = new Win32::GUI::DialogBox(
> -title   => "old title",
> -left=> 100,
> -top => 110,
> -width   => 500,
> -height  => 400,
> -name=> "ModuleWindow",
> -style   => WS_BORDER
>   | DS_MODALFRAME
>   | WS_POPUP
>   | WS_CAPTION
>   | WS_SYSMENU,
> -exstyle => WS_EX_DLGMODALFRAME
>   | WS_EX_WINDOWEDGE
>   | WS_EX_CONTEXTHELP
>   | WS_EX_CONTROLPARENT,
> 
> );
> 
> 
> I need to do
> 
> $ModuleWindow->title("new title");
> 
> 
> 
> 
> chris
> 
> 
> 
> 
>
_
> Do You Yahoo!?
> Get your free @yahoo.com address at
> http://mail.yahoo.com
> 
> 
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
>
http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users


__
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

Re: [perl-win32-gui-users] Memory leak (not really a leak at all)

2001-01-09 Thread Sam 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> Sam wrote:
> > Hi,
> >
> > I found many references to the 'memory leak' in the archived 
> > messages at http://www.mail-archive.com/perl-win32-
> > [EMAIL PROTECTED]/.
> 
> > I believe there isn't a memory leak at all, it appears that the 
> > memory usage reported by windows task manager includes a 
> > portion of a windows cache allocated to the program, and that it's 
> > the cache usage that changes, not the amount of memory that the 
> > perl interpreter has allocated.
> 
> oh well, I'm really confused now :-)
> 
> > This is based on these observations:
> > 1)  As the memory usage reported by the task manager increases 
> > the total memory usage does not increase. If you run a compiler or 
> > something that will allocate memory a bit at a time for a long period 
> > of time you'll notice that as the compiler's memory usage goes up, 
> > and so does the total memory usage.
> 
> yes, this is true.
> 
> > 2)  If you minimize the perl-win32-gui app's window the reported 
> > memory usage goes down to a base value (120K with my perl), and 
> > every time you minimize the window it goes down to the same 
> > value. This is _not_ indicative of a memory leak.
> 
> this is true too.
> 
> > 3)  If you play with other applications in a similar way you
> > can make them exhibit similar behaviour. The reported memory usage
> > on other applications (my test was EditPlus) doesn't increase to 
> > the same extent, but it does increase (more on this difference later).
> 
> and this is true, but there are other applications (for example,
> the NT Task Manager) which does not exhibit this behaviour, even
> if they're left running for a large amount of time. and the Task
> Manager updates its contect each second, so is doing something.
> but its cache memory never grows up. damn :-(
> 
> > During the above I looked over the code involved, and attempted
> > to isolate a memory leak. So far as I can tell the code is rock
> > solid.
> 
> way cool ;-)
> 
> > I believe that the difference between a perl-win32-gui application, 
> > and other pure win32 applications is in the DefWindowProc 
> > handling. The perl-win32-gui module does call DefWindowProc 
> > when either you don't have a handler installed, or you return 1, 
> > however through BoundsChecker I believe that this may not always 
> > be the case.
> 
> I'm really interested in this: can you elaborate more on this
> point? do I call DefWindowProc too much, or it is not called
> when it should be?
I saw a few messages come in that weren't DefWindowProc'd, but I 
think that may have been my fault (ie returned 0 from handler).
Looking at your code it looks like DefWindowProc is called when it 
should be, but there's obviously a problem somewhere. This was a 
bit of a stab in the dark (much like the assumption about the cache 
allocation, but what other answer is there?). My next move will be 
to attempt to recreate this bug in a pure win32 app.

> > I would be interested if someone finds anything else out about
> > this problem. Unfortunately I can't spend any more time on this,
> > as it appears to me that this isn't a serious bug, at least not
> > something that will stop a program from working correctly.
> 
> well, a 4k increment for each mouse movement is quite too much,
> so something should be corrected (if it's not totally wrong, it's
> surely at least poorly coded :-)
I agree, now. There was a posting recently that reported that a perl 
gui app would crash after all available memory was consumed, so I 
will devote some of my time to fixing this problem.

I'll report when I know more.

> cheers,
> Aldo
> 
> __END__
> $_=q,just perl,,s, , another ,,s,$, hacker,,print;
> 
> 
> 
> ___
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> 



-BEGIN PGP SIGNATURE-
Version: N/A

iQA/AwUBOlruq5sRND2Z+TaWEQKsowCg8YtbBZKJN7ZbK2kfuPN1ayTqKKQAoIfp
3dsqAbirf2z5dM0oe0iY+MLv
=cIST
-END PGP SIGNATURE-

Sam Jacobson
R & D Manager / Software Engineer
Selective Communications
Ph +64 9 302 1142
www.selective.co.nz

[perl-win32-gui-users] The memory leak problem (fixed, I hope ;)

2001-01-09 Thread Sam 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I said I'd report when I know more, so here goes...

The problem isn't with DefWindowProc at all (in fact 
DefWindowProc doesn't do anything except default handling - 
duh!). My apologies for being misleading.

The memory usage in the task manager thingee is useful, but 
inherently misleading. It isn't a cache allocation thing or anything 
like that, again sorry for being misleading.

The problem is with the C-perl interface. The WindowMsgLoop 
needs a good perl start, and end block:
dSP;
ENTER;
SAVETMPS;



FREETMPS;
LEAVE;

This is because it calls into the perl interpreter. The Dialog XSUB 
doesn't need those blocks explicitly however because they are 
added by xsubpp. However because the Dialog XSUB pretty much 
never exits (and therefore calls FREETMPS) it accumulates TMPs. 
There are (I believe) two ways to fix this:
1/ make the dialog XSUB return after processing one message, 
and call it from perl like
while( Win32::GUI::Dialog() ) {
}
2/ give the Dialog XSUB an explicit block around the perl interpreter 
calls it makes. I believe that this will work fine, but I haven't tested 
it. I implemented (1) in my copy of win32::GUI.

NB:
It may be necessary to add blocks in other places (in fact I'm sure 
of it), but this is the only problem I am aware of.
I can't create and distribute a patch on work time, but in my own 
time (of which I have very little unfortunately) I will create a patch for 
0.0.502, and send this to Aldo, if he so desires.


-BEGIN PGP SIGNATURE-
Version: N/A

iQA/AwUBOlsd7ZsRND2Z+TaWEQLI4ACfT9k/+/Lm84a6GAhfnF8sa91kBGEAoIXP
QULIwerislw19RYsRAihlTY+
=5seU
-END PGP SIGNATURE-

Sam Jacobson
R & D Manager / Software Engineer
Selective Communications
Ph +64 9 302 1142
www.selective.co.nz