THxx embedded in a class and their ownership

Dear ROOTers,

I made a class that perform my analysis tasks. This class embeds (with pointers) some histograms “THxx” objects, taking care of their creation and deletion.

It can happen that a TFile is open when such objects are created, so they are also inserted in the list of objects of the TFile by default. If later the TFile is closed, such histograms are also deleted, and my pointers in my class points to some deallocated memory.

The manual suggests to THxx::SetDirectory(0) to change the ownership of the object. So I did, but when my class methods try to draw on such histogram calling TTree::Draw("…>>hname", …), no histograms with such a name can be found (because it is searched only in the current directory)

So the only solution that I found is to put the histogram in the current dir just for a while for the Draw call, something like:

myhisto->SetDirectory(gDirectory);
mytree->Draw("... >>myhistoname",...);
myhisto->SetDirectory(0);

Is this the intended approach in such a situation?

Thanks,
Matteo

BTW Is there any plan to add to the TTree::Draw method a signature like TTree::Draw(TH1* targethisto, …etc…) or similar (and maybe the same for a TEventList…)?

[quote]So the only solution that I found is to put the histogram in the current dir just for a while for the Draw call, something like:[/quote]Yes, this is a solution. The other is to attached the histogram to a non-file based TDirectory (for example gROOT, myshito->SetDirectory(gROOT)) and cd to this directory before the Draw (gROOT->cd()).

Cheers,
Philippe.

PS. [quote]Is there any plan to add to the TTree::Draw method a signature like TTree::Draw(TH1* targethisto, …etc…) or similar (and maybe the same for a TEventList…)?[/quote]It would be nice, but we have not yet been able to design the interface such that it supports (correctly and intuitively) all the features of the current interface.

Related to the same subject (so no reason to open a new post) I have just realized that TEventList (and maybe also some other objects) are NOT added to the current directory WHEN created by a copy constructor like the following example:

std::map <std::string, TEventList> prova2
prova2["1"] = TEventList("evl1","evl1")
.ls
TFile**         f1.root
 TFile*         f1.root

Maybe the temporary TEventList(“evl1”,“evl1”) is inserted and then removed just after the copy (or maybe compilers optimize and they are able to skip the copy…)

So I can use a STL container of TEventList, being sure that no closing file will delete them. Moreover the STL container take care of deleting the TEventList object when it is removed from the container.

Is there any bug in this argument?

[quote] that TEventList are NOT added to the current directory WHEN created by a copy constructor[/quote]That is correct.

[quote]So I can use a STL container of TEventList, being sure that no closing file will delete them[/quote]Yes.

Philippe.