|Message: Re: Setting Track Info for secondaries||Not Logged In (login)|
Click on the Forum title, e.g. on the "Forums by Category" page, to read a sequence of postings to the Forum and its threads all in one page. If you are only interested in one thread or the thread following a specific posting, click the thread or the posting, which takes you to a smaller page, which contains only the part you are interested in and may be easier to navigate.
Messages are "chained" if there are only replies at the first level, i.e. 1/1.html, 1/1/1.html etc. In case of "chained" messages the message number is replaced by the icon and there is no indentation.
Inline: Display the subject line only or also the text of the posting(s); for the choice "All" the "Outline" choices are switched off.
|1||0||1||no text / full text of posting|
|2||1||All||text for level 1 only / text for All postings|
Outline: Choose the depth of the posting thread, successive toggle controls provide increasing detail.
|1||2||1||2 levels / 1 level (original posting)|
|2||3||2||3 levels / 2 levels|
|3||3||All||3 levels / all levels (all postings)|
Good points, all! I'll respond to what I can.
> I thought that the recently-added function > G4Step::GetSecondaryInCurrentStep() would be just what I needed, but > there are problems. > > This function returns a vector of pointers to const G4Track, so it's not > easy to add an information object pointer via > G4Track::SetUserInformation(). I'd be interested to know why the design > was done this way, as the self-same track pointers are available in > non-const form via the likes of G4Step::GetSecondary(), if you only knew > which ones relate to the current step.
The idea was so user can't modify secondary tracks or add/remove tracks but your issue may have been an oversight. I'll confirm that the developer is aware of your posting.
You could use the GetfSecondary() as in:
This also shows you how to extract just the secondaries in the current step.
> So, following a suggestion from Tom Roberts in his reply "Re: Passing > info to tracks" (12 Sep 2009), I set up a std::map to relate tracks to > information objects. My first attempt used the track ID as key, but > unfortunately this didn't work: the IDs in the tracks provided by > GetSecondaryInCurrentStep() were all zero (when making the call from > within ProcessHits(), at any rate).
> So in my next attempt I changed the map to use a pointer to const > G4Track as key instead. This largely worked but with occasional > surprises. It occurred to me that tracks are deleted during the > processing of an event, and if an area of memory got re-used for a new > track, the new track would magically acquire the information object from > the old one.
As you found out, it is not a good idea to use the pointer to a G4Track as a key for your map.
> I'd be very grateful for your expert thoughts on: > > (1) Do people in fact just cast away const in order to force > SetUserInformation() to work? (It would save a lot of trouble!)
Yes, you'll find code that uses const_cast even in the G4 examples, but it is not encouraged.
> (2) At what point do the many members of G4Track become valid? It would > be useful if the ID were one of the early ones.
called from G4EventManager::DoProcessing()
> (3) Is there a way for the user to intervene at the moment a secondary > is created, in order to (for example) implement routine copying of > context-dependent information from parent to secondary?
Well, yes - but not exactly 'at the moment a secondary is created' because this happens inside processes.
You can implement ClassifyNewTrack in your StackingAction:
|Inline Depth:||Outline Depth:||Add message:|