This code simply parses the Event tree branch list to find matching objects, and parses out the label/instance/process handles to create art::InputTags as a list. Then the calling code can do something like the following:

First, I thought getManyByType was too hard, since I requested it about a year ago by email and didnt' get any response...? Looking at the source code, it wouldn't be easy to hack.

We are sorry the email request was lost. Please submit future requests through the issues tracker system so they do not get lost.

Second, getManyByType doesn't do exactly what I want: I not only want the data products, but also the InputTag information, so I can output to the user. Maybe ART has that semantic in there somewhere.

In order to keep the reading speed of gallery as fast as possible, Provenance information is not available. This is the information required to provide reliable InputTag construction.

But you could easily wrap my suggestion to also give the same result as getManyByType.. that would work fine for most people.

Although we are able to provide the gallery::Event::getManyByType facility, unlike the art::Handle, the gallery::Handle does not provide provenance information. Given the lack of access to provenance information, is adding this facility to gallery still of interest?

Here's the use case: an event viewer or simply a file cataloger. You know the file might contain Hits, but you want to list all the possible Hit lists the file contains so that the user can select the one they want (or put the correct name into an ART job so they can find them).

Again, simply adding my solution as a function in gallery::Event might be good enough for most users, and this is low priority for me (since you nicely provide a pointer to the raw Tree for me to operate on).

See #16547-7. Looks like I dropped the ball on this one--I probably should have put this back in "Accepted". As discussed in the aforementioned reference, we should have the ability to look at our backlog of issues in the next week or so.