From: Glenn W M. <gwm...@gm...> - 2007-02-08 21:31:55
|
I've been working on an old project and am seeing an old problem and a new one. The old problem is the: "(in cleanup) Can't call method "FETCH" on an undefined value..." message on program exit. Rob thought he had this one pinned down, but it seems there's still a problem somewhere. It goes away as usual when I put the: undef $mw statement after exiting the Dialog phase. The new problem is with the new UserData method. I tried saving a hash reference, but am getting this error: Can't use string ("1") as a HASH ref while "strict refs" in use... on use of the expression $mw->tbTab->UserData()->{key} The same expression works OK in a trivial example: =============================================== #!perl -w use Win32(); use Win32::GUI 1.05 (); my $mw = new Win32::GUI::Window(-name => "mw"); $mw->AddTabStrip(-name => "tbTab"); $mw->tbTab->UserData(5); Win32::MsgBox($mw->tbTab->UserData()); $mw->tbTab->UserData("String"); Win32::MsgBox($mw->tbTab->UserData()); my $hashref = { key => "value" }; $mw->tbTab->UserData($hashref); Win32::MsgBox($mw->tbTab->UserData()->{key}); ================================================ I also saw the message: "userData ref count not 1 during destruction - please report this..." at one point (but am having trouble reproducing that one). I am using version 1.05 of the module. I know the next request will be to provide a minimal example demonstrating the problems, but this program is a labour of love and is almost 4000 lines long! I can work around both problems and am only reporting them for the record as it was requested. Then again, I don't mind sending a copy of the program if anybody wants to look into it. Glenn |
From: Robert M. <rm...@po...> - 2007-02-08 22:31:50
|
Glenn W Munroe wrote: > I've been working on an old project and am seeing an old problem and a new > one. The old problem is the: > > "(in cleanup) Can't call method "FETCH" on an undefined value..." > > message on program exit. Rob thought he had this one pinned down, but it > seems there's still a problem somewhere. You say later that you're using v1.05. The fix for this isn't in 1.05, it's only in CVS. > The new problem is with the new UserData method. I tried saving a hash > reference, but am getting this error: > > Can't use string ("1") as a HASH ref while "strict refs" in use... > > on use of the expression > > $mw->tbTab->UserData()->{key} Can you split this into 2: my $somescalar = $mw->tbTab->UserData(); my $value = $hashref->{key}; and have a look at what $somescalar has in it - the error suggests that you're not getting a hashref back from the user data, and if not, then we'll need to have a look at where you set it ... > I also saw the message: > > "userData ref count not 1 during destruction - please report this..." If you can reproduce this, I'd like to hear about it, as there shouldn't be any way this can happen! > I am using version 1.05 of the module. I know the next request will be to > provide a minimal example demonstrating the problems, but this program is a > labour of love and is almost 4000 lines long! I can work around both > problems and am only reporting them for the record as it was requested. Then > again, I don't mind sending a copy of the program if anybody wants to look > into it. Let's see if we can get there without having to share 4000 lines of code :-) Thanks for taking the time to report these problems. Regards, Rob. |
From: Glenn W M. <gwm...@gm...> - 2007-02-09 14:17:38
|
Thanks, Rob. I really appreciate the work you've put into this module recently, and I'm sure everyone on the list would agree. As I was adding my comments below, I decided to have a go at producing a minimal example demonstrating the problem. At some point, I realised that the original program was working! Doubting my own sanity, I ran last night's backup and it, too was working. It is quite possible that I *am* cracking up, but there may just be a pointer problem somewhere. Still, for now, I will keep plugging away using UserData, and will get back to you if I can describe something that makes more sense than this! Cheers, Glenn > -----Original Message----- > From: Robert May [mailto:rm...@po...] > Sent: 08 February 2007 19:32 > To: Glenn W Munroe > Cc: per...@li... > Subject: Re: [perl-win32-gui-hackers] Global destruction error and > UserData problem > > Glenn W Munroe wrote: > > I've been working on an old project and am seeing an old problem and a > new > > one. The old problem is the: > > > > "(in cleanup) Can't call method "FETCH" on an undefined value..." > > > > message on program exit. Rob thought he had this one pinned down, but it > > seems there's still a problem somewhere. > > You say later that you're using v1.05. The fix for this isn't in 1.05, > it's only in CVS. > [Glenn W Munroe] Doh! Note to self: RTFM > > The new problem is with the new UserData method. I tried saving a hash > > reference, but am getting this error: > > > > Can't use string ("1") as a HASH ref while "strict refs" in use... > > > > on use of the expression > > > > $mw->tbTab->UserData()->{key} > > Can you split this into 2: > my $somescalar = $mw->tbTab->UserData(); > my $value = $hashref->{key}; > > and have a look at what $somescalar has in it - the error suggests that > you're not getting a hashref back from the user data, and if not, then > we'll need to have a look at where you set it ... > [Glenn W Munroe] OK... $somescalar gets the value 1. I actually set the value right after the tabstrip is created with these lines: my $rhTab = { ambiguous => 0, change => 0 }; $mw->tbTab->UserData($rhTab); > > I also saw the message: > > > > "userData ref count not 1 during destruction - please report this..." > > If you can reproduce this, I'd like to hear about it, as there shouldn't > be any way this can happen! > [Glenn W Munroe] I will have a shot at stripping the code down as much as possible. If I can recreate this, I'll let you know. > > I am using version 1.05 of the module. I know the next request will be > to > > provide a minimal example demonstrating the problems, but this program > is a > > labour of love and is almost 4000 lines long! I can work around both > > problems and am only reporting them for the record as it was requested. > Then > > again, I don't mind sending a copy of the program if anybody wants to > look > > into it. > > Let's see if we can get there without having to share 4000 lines of code > :-) > > Thanks for taking the time to report these problems. > > Regards, > Rob. |
From: Robert M. <rm...@po...> - 2007-02-09 21:05:03
|
Glenn W Munroe wrote: > Still, for now, I will keep plugging away using UserData, and will get back > to you if I can describe something that makes more sense than this! Please do. Rob. |