Hi Rene,
I checked out from CVS and my test case works fine now.
However, looking at the output (see below) of three execs of the test case
rises two questions:
1.) hfile->GetListOfProcessIDs has for each run only one entry (the
actual), whereas hfile->GetNProcessIDs returns the correct number.
TFile::NProcesIDs is filled via a loop on all TKeys with name
ClassName TProcessID.
Why TFile::ListOfProcessIDs is not filled at the same time?
2.) Since TFile::ListOfProcessIDs has only one (the actual) TProcessID,
a hfile->GetListOfProcessIDs()->Print() and an iteration over
hfile->GetListOfProcessIDs() give only one element. The Name field
is always ProcessID0. A loop over the TKeys with ClassName TProfileID
lists the TProcessID with the actual ProcessID title field, but with the
correct Name field.
Is the Name attribute not filled correctly in the transient
TProfileID?
Maybe I expect just some different behaviour of the ProcessIDs and the
actual implementations is what you intended?
Thanks,
Dirk
-------------------------------------------------------------------------------
[lxplus010] ~/progs/RootTest/CTest001 > ./CTest001
OBJ: TProcessID ProcessID0 c8a06cf2-6379-11d6-a878-75a18a89beef
Entries = 1
NProcessIDs = 1
Name ProcessID0 Title c8a06cf2-6379-11d6-a878-75a18a89beef
Name ProcessID0 Title c8a06cf2-6379-11d6-a878-75a18a89beef
-------------------------------------------------------------------------------
[lxplus010] ~/progs/RootTest/CTest001 > ./CTest001
OBJ: TProcessID ProcessID0 cae9be82-6379-11d6-880f-75a18a89beef
Entries = 1
NProcessIDs = 2
Name ProcessID0 Title cae9be82-6379-11d6-880f-75a18a89beef
Name ProcessID0 Title c8a06cf2-6379-11d6-a878-75a18a89beef
Name ProcessID1 Title cae9be82-6379-11d6-880f-75a18a89beef
-------------------------------------------------------------------------------
[lxplus010] ~/progs/RootTest/CTest001 > ./CTest001
OBJ: TProcessID ProcessID0 cfaef298-6379-11d6-89fd-75a18a89beef
Entries = 1
NProcessIDs = 3
Name ProcessID0 Title cfaef298-6379-11d6-89fd-75a18a89beef
Name ProcessID0 Title c8a06cf2-6379-11d6-a878-75a18a89beef
Name ProcessID1 Title cae9be82-6379-11d6-880f-75a18a89beef
Name ProcessID2 Title cfaef298-6379-11d6-89fd-75a18a89beef
-------------------------------------------------------------------------------
On Thu, 9 May 2002, Rene Brun wrote:
> Hi Dirk,
>
> Thanks for reporting this problem with TRef.
> It is now fixed in CVS. The problem was in TProcessID::WriteProcessID
> where the line testing if a TProcessID was already encountered in the file
> was not correct.
>
> Rene Brun
>
>
> On Wed, 8 May 2002, Dirk Geppert wrote:
>
> > Dear Rooters,
> >
> > attached you may find a simple program with two classes A and B,
> > where B has an attribute pointing to an instance of A via TRef.
> > Both classes are written to two branches of a tree.
> >
> > Running the program ONCE works as expected:
> > - no error messages
> > - one TProcessID object is written out, listed via
> > a) hfile->GetListOfProcessIDs()->Print()
> > b) hfile->GetNProcessIDs()
> > c) loop over all TKeys in the created file with ClassName TProcessID
> >
> > However, updating the tree, i.e. running the program again,
> > - an error message appears in tree->Fill() (only when B is written out):
> > Error in <TObjArray::At>: index 2 out of bounds
> > (size: 2, this:0x08493030)
> > - the number of listed TProcessIDs is inconsistent:
> > via a) twice the number of created B objects,
> > with all the same Name and Title (of TProcessID)
> > via b & c) same as a) plus 1 (from first run)
> >
> > Version 3.03/05 on Linux RH 6.1 with gcc 2.95.2
> >
> > My questions are:
> > - Why does the error message appear? Is there something wrong in the way
> > the tree/branches are updated?
> > - Why for n>1 runs of the program not only one process ID for each time
> > the program is run is written to the file?
> > - Why are in TFile::ListOfProcessIDs only the new TProcessIDs stored
> > while TFile::NProcessIDs gives the correct answer?
> >
> > Thanks for you help,
> > Dirk
> >
> >
> >
>
>
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:52 MET