Dear Rene, > I understand your argument in your special case. > However we will not apply you suggestion > -because it will be a violation of the general rule > -very often the TH2::Projection functions do not produce graphics > -it is your problem if one of your canvas has the same name as the projection > of a 2-d histogram It is not only the canvas problem - it was just an example. I would have to make sure that nothing else(!) has the same name: Files, MappedFiles, Functions, Geometries, Canvases, Styles, Specials, ANY TObject in gDirectory... For a running program I can ensure this - but not for macros build by other people using our classes, because you always choose the most intuitive name for everything, which is the same in many cases. I think to make it possible for programmers to use this feature in a robust way you should either add a flag at last argument to the Project/Profile function which can be used to change the behaviour, find another solution or do the Project/Profile calculation in a new function which already takes the histogram pointer as an argument. After getting the pointer like before you could call this new function from your old ones. It is not me who is worried about the problem. I'm aware of it and normally it doesn't happen to me to step into it. But if it happens - and for a lot of people using our classes it happens oftenand easily - it takes alot of time to understand what's going on (normally half a day or more). So in my opinion it is worth to find a convinient solution for us and your rules. Best regards, Thomas. >>Dear rooters, >> >>having a possibility to update an existing profile histogram or a >>projection is a good idea, but finding the already existing histogram >>via gROOT->FindObject in my opinion is not a good idea. >> >>The reason in very simple: gROOT->FindObject searches first everything >>else (eg. canvases, current directory, etc) So the probability is high >>that for example a canvas with the same name is found - which results in >>strange behaviour. >> >>I guess the typical application is that I draw a profile into a pad. >>Somewhere (eg in a Paint-funtion) I change directory (cd()) into this >>pad and call Profile*() to update the existing profile. In this case it >>would be much more convinient if FindObject would first search in the >>current pad. Because I assume that this is a dangerous change - because >>other parts of the code may rely on the order of searches in FindObject >>I suggest to replace gROOT->FindObject by: >>TObject *obj = gPad ? gPad->FindObject(pname) : 0; >>if (!obj) >> gROOT->FindObject(pname); >> >>This in: TH2::ProfileX, TH2::ProfileY, TH2::ProjectX, TH2::ProjectY, >>TH3::ProjectionZ, TH3::Project3D >> >>Best regards, >>Thomas. > >
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:10 MET