I am reading your earlier post once again, and I have realized that maybe you are asking about a completely different thing.
Your question may be about changes in OPC server's address space, such as when new leaves (OPC items) or branches (this is what you might be calling "groups") are added, either by a dynamically behaving OPC server, or when OPC server's configuration is reloaded.
If so, this answer is basically negative - yes, if you want to detect such changes, you need to re-browse the address space, and detect the changes. Unfortunately, OPC Data Access specification does not cover this, so server's cannot generically notify their clients about such changes. This has been improved in the news specs (OPC-UA, Unified Architecture).
QuickOPC does, however, automatically re-subscribe to OPC items that appear invalid at one time - knowing the the server's configuration may change over time. So, if you Subscribe to an item, and it does not exist in the server at that time, you will get an error, but the item remains listed in the component, and after a configurable period, the component will re-try it. So, if the item becomes valid, it'll start working, without any coding in your app.
Hope this helps

Hello,
I am not sure if we are talking about the same thing or using the same terms.
I assume that you are referring to OPC groups. They are basically a concept in OPC that exists in order to allow efficient communication: A group has some common characteristics, such as update rate or percent deadband, and allows a mix of OPC items be added to it. The reason of existence for the OPC groups is to allow efficient communication (so that the common characteristics do not have to be repeatedly sent over the network, or over process boundaries, repeatedly), and - for some OPC servers - to allow them easier optimization of how they internally process the client's requests.
In the client application, the existence OPC groups does not bring much, if any, benefit. For this reason, we have designed the component so that it hides the existence of OPC groups as much as possible. If you have OPC items (tags) that share some common characteristics, such as the update rate, you simply state the update rate with each item, and the component internally takes care of putting them all into one group. The fact the group has been created, or removed, inside the OPC server, should have no application-level significance - or, what should that actually mean to you application?
If you are subscribing for item updates, and you are looking for a result of that operation, the application always gets this information in the first "item changed" notification it receives for that item. The notification is either successful, and already carries an value-timestamp-quality object with it, or it indicates an error, and the error is detailed in the Exception property of the event (for example, if the item ID is invalid, or if the server cannot be reached). Maybe this is what you are looking for?
Regards,

Hello,
no there is not such a notification or information. Can you, however, explain why you would need such thing?
Regards,