From: Ben Morrow on 20 May 2010 08:27 Quoth Ted Byers <r.ted.byers(a)gmail.com>: > On May 19, 6:54�pm, Ben Morrow <b...(a)morrow.me.uk> wrote: > > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > Trace: > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/ > > > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > > > destruction. > > > > > Compilation finished at Wed May 19 16:41:23 > > > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the > > last line here? > > > > � � sub DESTROY > > � � { > > � � � � my $self= shift(@_); > > � � � � return � if �tied(%$self); > > � � � � my $unload; > > � � � � eval { $unload= $self->{UNLOADME}; 1 } > > > > If so I can't see how that could be calling tie magic, since the code's > > just checked that it *isn't* tied. In any case, back up your copy of > > Win32/TieRegistry.pm and add > > > > � � use Devel::Peek (); > > � � use Carp (); > > � � Devel::Peek::Dump($self); > > � � Carp::confess("huh?"); > > > > just before that line, and post the result. > > I hadn't noticed that, but I was out of my depth as I have never used > the tie magic, and didn't know which of the packages I used would or > why. > > In any event, here is the output after adding the four lines you > suggest: > <snip> > SV = RV(0x22c15b0) at 0x22c15a4 > REFCNT = 1 > FLAGS = (PADMY,ROK) > RV = 0x1c53074 > SV = PVHV(0x1e45c4c) at 0x1c53074 > REFCNT = 2 > FLAGS = (OBJECT,SHAREKEYS) > STASH = 0x1f5b01c "Win32::TieRegistry" > ARRAY = 0x222f58c (0:14, 1:14, 2:4) > hash quality = 121.5% > KEYS = 22 > FILL = 18 > MAX = 31 > RITER = -1 > EITER = 0x0 OK, so the hash definitely isn't tied. (If it had been there would have been a whole MAGIC section, including the line MG_TYPE = PERL_magic_tied(P) ..) Can you confirm that the code does in fact get as far as l1485, and doesn't get any further? (Take out the 'confess', and put a 'warn' before 'eval { $unload=...' and another before 'my $debug=...'.) If it does, then the only remaining option is that $self->{UNLOADME} *is* tied, and that the tied object is getting destroyed before its parent. You can confirm this by changing the Devel::Peek::Dump line you added before to Devel::Peek::Dump($self->{UNLOADME}); If that output includes the MAGIC line I mentioned above, post it. Ben
From: Ted Byers on 20 May 2010 10:32 On May 20, 8:27 am, Ben Morrow <b...(a)morrow.me.uk> wrote: > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote: > > > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > Trace: > > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ > > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ > > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/ > > > > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > > > > destruction. > > > > > Compilation finished at Wed May 19 16:41:23 > > > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the > > > last line here? > > > > sub DESTROY > > > { > > > my $self= shift(@_); > > > return if tied(%$self); > > > my $unload; > > > eval { $unload= $self->{UNLOADME}; 1 } > > > > If so I can't see how that could be calling tie magic, since the code's > > > just checked that it *isn't* tied. In any case, back up your copy of > > > Win32/TieRegistry.pm and add > > > > use Devel::Peek (); > > > use Carp (); > > > Devel::Peek::Dump($self); > > > Carp::confess("huh?"); > > > > just before that line, and post the result. > > > I hadn't noticed that, but I was out of my depth as I have never used > > the tie magic, and didn't know which of the packages I used would or > > why. > > > In any event, here is the output after adding the four lines you > > suggest: > > <snip> > > SV = RV(0x22c15b0) at 0x22c15a4 > > REFCNT = 1 > > FLAGS = (PADMY,ROK) > > RV = 0x1c53074 > > SV = PVHV(0x1e45c4c) at 0x1c53074 > > REFCNT = 2 > > FLAGS = (OBJECT,SHAREKEYS) > > STASH = 0x1f5b01c "Win32::TieRegistry" > > ARRAY = 0x222f58c (0:14, 1:14, 2:4) > > hash quality = 121.5% > > KEYS = 22 > > FILL = 18 > > MAX = 31 > > RITER = -1 > > EITER = 0x0 > > OK, so the hash definitely isn't tied. (If it had been there would have > been a whole MAGIC section, including the line > > MG_TYPE = PERL_magic_tied(P) > > .) > > Can you confirm that the code does in fact get as far as l1485, and > doesn't get any further? (Take out the 'confess', and put a 'warn' > before 'eval { $unload=...' and another before 'my $debug=...'.) > > If it does, then the only remaining option is that $self->{UNLOADME} > *is* tied, and that the tied object is getting destroyed before its > parent. You can confirm this by changing the Devel::Peek::Dump line you > added before to > > Devel::Peek::Dump($self->{UNLOADME}); > > If that output includes the MAGIC line I mentioned above, post it. > > Ben Thanks Ben Yes, it is confirmed that it gets to line 1485 and no further. And changing the peek line as suggested produces the following: SV = PVLV(0x185b6b4) at 0x22245bc REFCNT = 1 FLAGS = (TEMP,GMG,SMG) IV = 0 NV = 0 PV = 0 MAGIC = 0x243554c MG_VIRTUAL = &PL_vtbl_defelem MG_TYPE = PERL_MAGIC_defelem(y) MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x22245cc SV = PV(0x1fa55d4) at 0x22245cc REFCNT = 1 FLAGS = (POK,pPOK) PV = 0x1836474 "UNLOADME"\0 CUR = 8 LEN = 12 TYPE = y TARGOFF = 0 TARGLEN = 1 TARG = 0x1bdb234 SV = PVHV(0x1e45c6c) at 0x1bdb234 REFCNT = 3 FLAGS = (OBJECT,SHAREKEYS) STASH = 0x1f5b034 "Win32::TieRegistry" ARRAY = 0x22298cc (0:14, 1:14, 2:4) hash quality = 121.5% KEYS = 22 FILL = 18 MAX = 31 RITER = -1 EITER = 0x0 Elt "CntValues" HASH = 0x359bb702 SV = IV(0x230a7a0) at 0x230a7a4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "MaxSubClassLen" HASH = 0xb3d551a2 SV = IV(0x230a850) at 0x230a854 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "FLAGS" HASH = 0x1773e623 SV = IV(0x230a9b0) at 0x230a9b4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 136 The "MG_TYPE = PERL_magic_tied(P)" isn't there. Instead, I see "MG_TYPE = PERL_MAGIC_defelem(y)" What next? Would this be an issue with DBI, or the MySQL driver? Is it likely to do any harm? The program runs fine otherwise. I am just troubled that this error arises after the code I wrote finishes. And seeing the name of the package where the error occurs is "TieRegistry", I am concerned this error may introduce, or be a consequence of, errors in my registry. Thanks again Ted Thanks again, Ted
From: Ted Byers on 20 May 2010 10:33 On May 20, 8:27 am, Ben Morrow <b...(a)morrow.me.uk> wrote: > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote: > > > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > Trace: > > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ > > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ > > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/ > > > > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > > > > destruction. > > > > > Compilation finished at Wed May 19 16:41:23 > > > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the > > > last line here? > > > > sub DESTROY > > > { > > > my $self= shift(@_); > > > return if tied(%$self); > > > my $unload; > > > eval { $unload= $self->{UNLOADME}; 1 } > > > > If so I can't see how that could be calling tie magic, since the code's > > > just checked that it *isn't* tied. In any case, back up your copy of > > > Win32/TieRegistry.pm and add > > > > use Devel::Peek (); > > > use Carp (); > > > Devel::Peek::Dump($self); > > > Carp::confess("huh?"); > > > > just before that line, and post the result. > > > I hadn't noticed that, but I was out of my depth as I have never used > > the tie magic, and didn't know which of the packages I used would or > > why. > > > In any event, here is the output after adding the four lines you > > suggest: > > <snip> > > SV = RV(0x22c15b0) at 0x22c15a4 > > REFCNT = 1 > > FLAGS = (PADMY,ROK) > > RV = 0x1c53074 > > SV = PVHV(0x1e45c4c) at 0x1c53074 > > REFCNT = 2 > > FLAGS = (OBJECT,SHAREKEYS) > > STASH = 0x1f5b01c "Win32::TieRegistry" > > ARRAY = 0x222f58c (0:14, 1:14, 2:4) > > hash quality = 121.5% > > KEYS = 22 > > FILL = 18 > > MAX = 31 > > RITER = -1 > > EITER = 0x0 > > OK, so the hash definitely isn't tied. (If it had been there would have > been a whole MAGIC section, including the line > > MG_TYPE = PERL_magic_tied(P) > > .) > > Can you confirm that the code does in fact get as far as l1485, and > doesn't get any further? (Take out the 'confess', and put a 'warn' > before 'eval { $unload=...' and another before 'my $debug=...'.) > > If it does, then the only remaining option is that $self->{UNLOADME} > *is* tied, and that the tied object is getting destroyed before its > parent. You can confirm this by changing the Devel::Peek::Dump line you > added before to > > Devel::Peek::Dump($self->{UNLOADME}); > > If that output includes the MAGIC line I mentioned above, post it. > > Ben Thanks Ben Yes, it is confirmed that it gets to line 1485 and no further. And changing the peek line as suggested produces the following: SV = PVLV(0x185b6b4) at 0x22245bc REFCNT = 1 FLAGS = (TEMP,GMG,SMG) IV = 0 NV = 0 PV = 0 MAGIC = 0x243554c MG_VIRTUAL = &PL_vtbl_defelem MG_TYPE = PERL_MAGIC_defelem(y) MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x22245cc SV = PV(0x1fa55d4) at 0x22245cc REFCNT = 1 FLAGS = (POK,pPOK) PV = 0x1836474 "UNLOADME"\0 CUR = 8 LEN = 12 TYPE = y TARGOFF = 0 TARGLEN = 1 TARG = 0x1bdb234 SV = PVHV(0x1e45c6c) at 0x1bdb234 REFCNT = 3 FLAGS = (OBJECT,SHAREKEYS) STASH = 0x1f5b034 "Win32::TieRegistry" ARRAY = 0x22298cc (0:14, 1:14, 2:4) hash quality = 121.5% KEYS = 22 FILL = 18 MAX = 31 RITER = -1 EITER = 0x0 Elt "CntValues" HASH = 0x359bb702 SV = IV(0x230a7a0) at 0x230a7a4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "MaxSubClassLen" HASH = 0xb3d551a2 SV = IV(0x230a850) at 0x230a854 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "FLAGS" HASH = 0x1773e623 SV = IV(0x230a9b0) at 0x230a9b4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 136 The "MG_TYPE = PERL_magic_tied(P)" isn't there. Instead, I see "MG_TYPE = PERL_MAGIC_defelem(y)" What next? Would this be an issue with DBI, or the MySQL driver? Is it likely to do any harm? The program runs fine otherwise. I am just troubled that this error arises after the code I wrote finishes. And seeing the name of the package where the error occurs is "TieRegistry", I am concerned this error may introduce, or be a consequence of, errors in my registry. Thanks again Ted Thanks again, Ted
From: Ted Byers on 20 May 2010 10:33 On May 20, 8:27 am, Ben Morrow <b...(a)morrow.me.uk> wrote: > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote: > > > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > Trace: > > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ > > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ > > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/ > > > > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > > > > destruction. > > > > > Compilation finished at Wed May 19 16:41:23 > > > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the > > > last line here? > > > > sub DESTROY > > > { > > > my $self= shift(@_); > > > return if tied(%$self); > > > my $unload; > > > eval { $unload= $self->{UNLOADME}; 1 } > > > > If so I can't see how that could be calling tie magic, since the code's > > > just checked that it *isn't* tied. In any case, back up your copy of > > > Win32/TieRegistry.pm and add > > > > use Devel::Peek (); > > > use Carp (); > > > Devel::Peek::Dump($self); > > > Carp::confess("huh?"); > > > > just before that line, and post the result. > > > I hadn't noticed that, but I was out of my depth as I have never used > > the tie magic, and didn't know which of the packages I used would or > > why. > > > In any event, here is the output after adding the four lines you > > suggest: > > <snip> > > SV = RV(0x22c15b0) at 0x22c15a4 > > REFCNT = 1 > > FLAGS = (PADMY,ROK) > > RV = 0x1c53074 > > SV = PVHV(0x1e45c4c) at 0x1c53074 > > REFCNT = 2 > > FLAGS = (OBJECT,SHAREKEYS) > > STASH = 0x1f5b01c "Win32::TieRegistry" > > ARRAY = 0x222f58c (0:14, 1:14, 2:4) > > hash quality = 121.5% > > KEYS = 22 > > FILL = 18 > > MAX = 31 > > RITER = -1 > > EITER = 0x0 > > OK, so the hash definitely isn't tied. (If it had been there would have > been a whole MAGIC section, including the line > > MG_TYPE = PERL_magic_tied(P) > > .) > > Can you confirm that the code does in fact get as far as l1485, and > doesn't get any further? (Take out the 'confess', and put a 'warn' > before 'eval { $unload=...' and another before 'my $debug=...'.) > > If it does, then the only remaining option is that $self->{UNLOADME} > *is* tied, and that the tied object is getting destroyed before its > parent. You can confirm this by changing the Devel::Peek::Dump line you > added before to > > Devel::Peek::Dump($self->{UNLOADME}); > > If that output includes the MAGIC line I mentioned above, post it. > > Ben Thanks Ben Yes, it is confirmed that it gets to line 1485 and no further. And changing the peek line as suggested produces the following: SV = PVLV(0x185b6b4) at 0x22245bc REFCNT = 1 FLAGS = (TEMP,GMG,SMG) IV = 0 NV = 0 PV = 0 MAGIC = 0x243554c MG_VIRTUAL = &PL_vtbl_defelem MG_TYPE = PERL_MAGIC_defelem(y) MG_FLAGS = 0x02 REFCOUNTED MG_OBJ = 0x22245cc SV = PV(0x1fa55d4) at 0x22245cc REFCNT = 1 FLAGS = (POK,pPOK) PV = 0x1836474 "UNLOADME"\0 CUR = 8 LEN = 12 TYPE = y TARGOFF = 0 TARGLEN = 1 TARG = 0x1bdb234 SV = PVHV(0x1e45c6c) at 0x1bdb234 REFCNT = 3 FLAGS = (OBJECT,SHAREKEYS) STASH = 0x1f5b034 "Win32::TieRegistry" ARRAY = 0x22298cc (0:14, 1:14, 2:4) hash quality = 121.5% KEYS = 22 FILL = 18 MAX = 31 RITER = -1 EITER = 0x0 Elt "CntValues" HASH = 0x359bb702 SV = IV(0x230a7a0) at 0x230a7a4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "MaxSubClassLen" HASH = 0xb3d551a2 SV = IV(0x230a850) at 0x230a854 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 0 Elt "FLAGS" HASH = 0x1773e623 SV = IV(0x230a9b0) at 0x230a9b4 REFCNT = 1 FLAGS = (IOK,pIOK) IV = 136 The "MG_TYPE = PERL_magic_tied(P)" isn't there. Instead, I see "MG_TYPE = PERL_MAGIC_defelem(y)" What next? Would this be an issue with DBI, or the MySQL driver? Is it likely to do any harm? The program runs fine otherwise. I am just troubled that this error arises after the code I wrote finishes. And seeing the name of the package where the error occurs is "TieRegistry", I am concerned this error may introduce, or be a consequence of, errors in my registry. Thanks again Ted Thanks again, Ted
From: Ted Byers on 20 May 2010 12:29
On May 20, 10:33 am, Ted Byers <r.ted.by...(a)gmail.com> wrote: > On May 20, 8:27 am, Ben Morrow <b...(a)morrow.me.uk> wrote: > > > > > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > On May 19, 6:54 pm, Ben Morrow <b...(a)morrow.me.uk> wrote: > > > > Quoth Ted Byers <r.ted.by...(a)gmail.com>: > > > > > > Trace: > > > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/ > > > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/ > > > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485 > > > > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/ > > > > > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global > > > > > destruction. > > > > > > Compilation finished at Wed May 19 16:41:23 > > > > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the > > > > last line here? > > > > > sub DESTROY > > > > { > > > > my $self= shift(@_); > > > > return if tied(%$self); > > > > my $unload; > > > > eval { $unload= $self->{UNLOADME}; 1 } > > > > > If so I can't see how that could be calling tie magic, since the code's > > > > just checked that it *isn't* tied. In any case, back up your copy of > > > > Win32/TieRegistry.pm and add > > > > > use Devel::Peek (); > > > > use Carp (); > > > > Devel::Peek::Dump($self); > > > > Carp::confess("huh?"); > > > > > just before that line, and post the result. > > > > I hadn't noticed that, but I was out of my depth as I have never used > > > the tie magic, and didn't know which of the packages I used would or > > > why. > > > > In any event, here is the output after adding the four lines you > > > suggest: > > > <snip> > > > SV = RV(0x22c15b0) at 0x22c15a4 > > > REFCNT = 1 > > > FLAGS = (PADMY,ROK) > > > RV = 0x1c53074 > > > SV = PVHV(0x1e45c4c) at 0x1c53074 > > > REFCNT = 2 > > > FLAGS = (OBJECT,SHAREKEYS) > > > STASH = 0x1f5b01c "Win32::TieRegistry" > > > ARRAY = 0x222f58c (0:14, 1:14, 2:4) > > > hash quality = 121.5% > > > KEYS = 22 > > > FILL = 18 > > > MAX = 31 > > > RITER = -1 > > > EITER = 0x0 > > > OK, so the hash definitely isn't tied. (If it had been there would have > > been a whole MAGIC section, including the line > > > MG_TYPE = PERL_magic_tied(P) > > > .) > > > Can you confirm that the code does in fact get as far as l1485, and > > doesn't get any further? (Take out the 'confess', and put a 'warn' > > before 'eval { $unload=...' and another before 'my $debug=...'.) > > > If it does, then the only remaining option is that $self->{UNLOADME} > > *is* tied, and that the tied object is getting destroyed before its > > parent. You can confirm this by changing the Devel::Peek::Dump line you > > added before to > > > Devel::Peek::Dump($self->{UNLOADME}); > > > If that output includes the MAGIC line I mentioned above, post it. > > > Ben > > Thanks Ben > > Yes, it is confirmed that it gets to line 1485 and no further. > > And changing the peek line as suggested produces the following: > > SV = PVLV(0x185b6b4) at 0x22245bc > REFCNT = 1 > FLAGS = (TEMP,GMG,SMG) > IV = 0 > NV = 0 > PV = 0 > MAGIC = 0x243554c > MG_VIRTUAL = &PL_vtbl_defelem > MG_TYPE = PERL_MAGIC_defelem(y) > MG_FLAGS = 0x02 > REFCOUNTED > MG_OBJ = 0x22245cc > SV = PV(0x1fa55d4) at 0x22245cc > REFCNT = 1 > FLAGS = (POK,pPOK) > PV = 0x1836474 "UNLOADME"\0 > CUR = 8 > LEN = 12 > TYPE = y > TARGOFF = 0 > TARGLEN = 1 > TARG = 0x1bdb234 > SV = PVHV(0x1e45c6c) at 0x1bdb234 > REFCNT = 3 > FLAGS = (OBJECT,SHAREKEYS) > STASH = 0x1f5b034 "Win32::TieRegistry" > ARRAY = 0x22298cc (0:14, 1:14, 2:4) > hash quality = 121.5% > KEYS = 22 > FILL = 18 > MAX = 31 > RITER = -1 > EITER = 0x0 > Elt "CntValues" HASH = 0x359bb702 > SV = IV(0x230a7a0) at 0x230a7a4 > REFCNT = 1 > FLAGS = (IOK,pIOK) > IV = 0 > Elt "MaxSubClassLen" HASH = 0xb3d551a2 > SV = IV(0x230a850) at 0x230a854 > REFCNT = 1 > FLAGS = (IOK,pIOK) > IV = 0 > Elt "FLAGS" HASH = 0x1773e623 > SV = IV(0x230a9b0) at 0x230a9b4 > REFCNT = 1 > FLAGS = (IOK,pIOK) > IV = 136 > > The "MG_TYPE = PERL_magic_tied(P)" isn't there. Instead, I see > "MG_TYPE = PERL_MAGIC_defelem(y)" > > What next? > > Would this be an issue with DBI, or the MySQL driver? > > Is it likely to do any harm? The program runs fine otherwise. I am > just troubled that this error arises after the code I wrote finishes. > And seeing the name of the package where the error occurs is > "TieRegistry", I am concerned this error may introduce, or be a > consequence of, errors in my registry. > > Thanks again > > Ted > > Thanks again, > > Ted On a different note, any ideas why Google is sending my notes multiple times to this forum? This is actuall the first time I have seen this nuisance arise. If it matters, I am using Firefox to access usenet via google/groups. I have no other way to access this forum, or any other. |