Rob, I wasn't aware of the circular reference, but I don't think anybody can argue with the two goals.
Your enhancements sound good. In principal, I'm a little wary of straying from MS's underlying interface, but I think that in the case of this control, the precedent was set in the early days of the module (from what I understand of the MS documentation, the SetTimer function creates the timer and sets its interval in one call). Your proposed new 'Kill' behaviour again strays a little from the MS standard, but it will achieve the goal of not breaking old programs. The only problem I can think of is if anybody were to repeatedly create and destroy a lot of timers, assuming standard MS behaviour, then memory usage (which seems to be a hot topic of late) might increase, as the timers would be simply disabled and not destroyed. But that's unlikely, and as long as the changes are documented, there shouldn't be a problem. So, in general, though I'm more of a user than a developer, I agree with your suggestions. Glenn -----Original Message----- From: Robert May [mailto:[EMAIL PROTECTED] Sent: Friday, 11 November, 2005 18:46 To: perl-win32-gui-hackers@lists.sourceforge.net Cc: Glenn W Munroe Subject: Win32::GUI::Timer [Was: Next Release soon on the users list] 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/ >
