Re: TGeoElementTable::Instance (fwd)

Hi Sue,

I will fix the problem with TGeoElementTable and let you know. Hopefully you should not run into other problems - different geometries can reside in the same time in memory - however you will be the first testing this in detail. The only cautions you should take are: - set gGeoManager pointer to 0 before adding a new geometry in memory (by whatever method)- if you have already one. - switch gGeoManager to the active geometry before starting to use it. - do not try to draw in the same time 2 geometries

I will let you know,
Regards,
Andrei

>Hi root team,
>I'm making use of the TGeo associated classes to build
>our detector geometries. We need to be able to build more
>than one geometry in the course of a job, and we store these multiple
>geometries in a loan pool of geometries available for use. These
>geometries are to be used within a vmc application, but also for other
>purposes.
>In order to manage multiple geometries in memory, I realize
>I need to manage the gGeoManager global pointer so
>that it points to the geometry in use and I've attempted to do this.
>I've run into my first problem however, in that I find that I receive
>a complaint when building a second geometry after the first is built
>which is:
>
> Error in <TGeoElementTable::ctor>: Element table already instantiated
>
>Investigating a bit, I see that TGeoElementTable is a singleton to
>hold the default list of elements, but it's not really treated like a
>singleton.
>For example, the TGeoManager destructor will delete the Instance.
>This is of course a problem when one has multiple geometry in memory,
>one of which may go out of use before another. Can this behavior be
>changed?
> A more general question: will I run into other problems trying to manage
>multiple geometries in memory in this way? How do you recommend handling
>this problem?
>Thanks,
>-Sue
>
>
>
>
Received on Wed Apr 20 2005 - 08:51:45 MEST