Re: TGeoElementTable::Instance (fwd)

Hi Andrei & Rene,
Thanks! I've tested the fix and I seem to be able to build two geometries now in memory and switch between them.   I'm wondering if you can expand a little bit on this restriction:  > - do not try to draw in the same time 2 geometries I can see that it would be a problem to draw two geometries on the same canvas simultaneously, but I'm wondering if I should expect that it's possible to draw 2 geometries sequentially in the same root
session after switching gGeoManager to point to the current geometry? In my own experiment this fails: the first geometry draws okay, the second does
not.
Thanks again,
-Sue

Andrei Gheata wrote:

> 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 Mon Apr 25 2005 - 06:06:14 MEST