I've had reason to look in more detail at the changes that Reini made some months ago. I propose that I'm going to make another round of changes to the timer class:

(1) I want to get rid of the circular reference.  I think this is possible.
(2) I'd like to not break existing implementations.

I propose the following interface:

new(PARENT, [NAME, [ELAPSE=0]])

creates a Win32::GUI::Timer object, adds it to the PARENT window's hash etc. as today. I'll add the capability of creating the object with ELAPSE=0, which will create the object, but not start the timer.

Interval([ELAPSE])

get or set the timer interval, as today.  I will modify it so that when
setting it returns the previous interval. Setting the interval to 0 will suspend the timer.

Kill([REMOVE=0])

Calling Kill with no parameters (or any parameter that evaluates to false) will suspend the timer exactly like Interval(0).

Calling Kill with a parameter that evaluates to True will remove all traces of the timer from the parent hash, although true destruction will still only happen when the object's ref-count goes to zero. In most case this will happen after a Kill(1).

Additionally, by removing the circular reference, I believe that regular destruction when the (parent) window object goes out of scope will happen, rather than the current implementation where if you have not called Kill explicitly, object destruction doe not happen until the final garbage collection sweep when the program terminates.

If we can agree on this, then I will make the changes, update the documentation and update the tests.

Your comments welcome, as always.

Regards,
Rob.

Robert May wrote:
Hi Glenn,

Thanks for the investigation. The changes were made by Reini, to try to bring the behaviour in line with what part 4 of the tutorial says about timers. Having looked at this text myself, I'm not sure that what he has done matches what the tutorial says, although I think his implementation is good.

Under the current implementation kill() destroys the timer completely (including, as you say, removing it's reference from the parent window). To disable the timer temporarily you need to set the interval to 0.

If we all agree that the new implementation is good, then I'll update the Timer documentation and part 4 of the tutorial to reflect this. I'll also make sure that this behavioural change gets mentioned in the release notes.

Regards,
Rob.

Glenn W Munroe wrote:

I had been building the new version using MinGW, but I just reinstalled it from Rob's PPM. This installed the new documentation correctly and I now see
that there is some Timer documentation.
Apologies for flooding the list with replies to myself...

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Glenn
W Munroe
Sent: Friday, 28 October, 2005 12:27
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [perl-win32-gui-users] Next Release soon


I spent a little time to dig into this more. As I suspected, this isn't a
bug, but a change in implementation. Under version 1.01_01, the Kill()
method simply made a call to the system function KillTimer. Version 1.02_02 explicitly destroys the timer, which includes removing its definition from
the window hash. Hence, my "nothing strange" code below was defining each
timer then destroying it in the next step!

In practice, there was a more subtle difference. The effect of the old
Kill() method was simply to disable the timer; it could then be resurrected
with a new Interval(). I'm not sure that this behaviour was correct or
desired, but I was using it in my program. I can't just remember why I did it that way, but it was probably a "safe" way of ensuring the timer didn't
fire until I was ready for it (the alternative being either to make the
Interval() very large--for some arbitrary value of "very large"--or to
repeatedly kill and redefine the timer). It could also have been to cover a
deeper problem in the implementation, but time will tell.

The Win32::GUI documentation for Timers is bare, but the MSDN documentation
does suggest that the new behaviour is correct. However, version 1.02_02
will break any program using the old behaviour. The addition of a simple
definition to the method documentation would help.

Glenn

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, 21 October, 2005 16:44
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [perl-win32-gui-users] Next Release soon


Sorry for the delay, but it's been hectic at work this week.

I've attached (an image of) the error message. Sure enough, a 'dump' of the
main window object shows that the timers don't get registered for some
reason:

bless({
  # tied Win32::GUI::Window
  "-accel"         => 41_681_429,
  "-font"          => -334_885_755,
  "-handle"        => 2_032_212,
  "-minheight"     => 595,
  "-minwidth"      => 850,
  "-name"          => "mw",
  "-timers"        => {},
  "-type"          => 0,

etc.

There's nothing strange about the declaration of the timers:

$mw->AddTimer("tmList",100000);
$mw->tmList->Kill();
$mw->AddTimer("tmLoop",100000);
$mw->tmLoop->Kill();

etc.

The same script runs with no problem on 1.01_01. There, the dump shows:

bless({
  # tied Win32::GUI::Window
  "-accel"         => 25_036_785,
  "-font"          => "-1626733967",
  "-handle"        => 6_358_280,
  "-minheight"     => 595,
  "-minwidth"      => 850,
  "-name"          => "mw",
  "-timers"        => {
                        1 => "tmList",
                        2 => "tmLoop",
                        3 => "tmStatus",
                        4 => "tmYearVerify",
                        5 => "tmTrackVerify",
                        6 => "tmGenreVerify",
                      },
  "-type"          => 0,

etc.

I'll keep trying to narrow it down and will post back if I do.

Glenn

------------------- reply ---------------

From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: [perl-win32-gui-users] Next Release soon
Date: 2005-10-19 15:40:09
----------------------------------
[EMAIL PROTECTED] wrote:

hit another more worrying problem: I have a large-ish program, which
uses a number of timers. With 1.02_02 I get an error whenever any one
of the timers tries to fire (Can't locate auto/tmList.al in @INC...).
I  tried to replicate this in a smaller program, but was unable to; a
simple program with a timer works fine. It's quite possible that my
program has a flaw, of which 1.01_01 is more tolerant, but there may
be a problem in the new GUI code.


That is indeed worrying. There have been some minor changes to the timer code that Reini made when he put his tests together, but I can't immediately see anything that would cause this.

Typically when I see errors like that it turns out to be a mis-spelled method call or window name, but if that was the case I would expect it to fail in 1.01_01 too.

If you can't get a short example to exhibit this problem, can you post the exact error message that you're getting.

Rob.
--
Robert May
Win32::GUI, a perl extension for native Win32 applications
http://perl-win32-gui.sourceforge.net/






-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Perl-Win32-GUI-Users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/





-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Perl-Win32-GUI-Users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/


Reply via email to