Skip to main content
W
WolfgangGo
Known Participant
March 15, 2012
Answered

Using ActiveSelectionObserver from a panel

  • March 15, 2012
  • 1 reply
  • 1288 views

Hi,

I want to get notified when the user sets the text curser into a text frame, while the panel of my plugin is open.

I have done a test with ActiveSelectionObserver added to a panel and that seems to work as expected.

The problem is that I cannot add the ActiveSelectionObserver to my existing panel, because it has a WidgetObserver that uses IID_IOBSERVER, and the ActiveSelectionObserver uses also IID_IOBSERVER. When both are present then InDesign does not load the plugin. The implementation IDs cannot be changed, because both have default implementations from the SDK. I have tried to add a second "dummy" panel, but when I set the property "visible" of the dummy panel to kFalse then the dummy panel is still visible, but the observer is no more notified. The best way would be to have an own implementation of the ActiveSelectionObserver with a different IID, but I don't know how to do this.

Additional information: I have just found in the file widgetid.h that there is an IID_ISELECTIONOBSERVER, so I will see if that helps.

Wolfgang

This topic has been closed for replies.
Correct answer Dirk Becker

For notification subscriptions an observer can have any IID, as you found you can take IID_ISELECTIONOBSERVER, or any private one.

When widgets are shown / hidden, AutoAttach/AutoDetach of their IID_IOBSERVER is invoked automatically. If you need a secondary observer on the same boss, you have to query that other interface from within your IID_IOBSERVER observer, and chain the AutoAttach etc. calls.

If you put your observer on a non-widget boss, you also have to find a way to invoke AutoAttach/Detach from outside, for example using a responder.

The ISubject calls to attach/detach an observer to the subject also have an additional IID parameter for the very same IID.

For completeness sake, if you use CObserver it has a separate constructor argument that sets the internally stored AttachIID to different IID - use IID_ISELECTIONOBSERVER or whatever IID you chose in the object model. The underlying partial implementation for the selection observer should pick it up from there when it does its own attach/detach.

Finally, you must never ever reuse implementation IDs from the SDK for own implementations, or boss IDs for own bosses. You got your plugin ID space for a reason - to prevent collisions.

Dirk

1 reply

P
Pickory
Legend
March 15, 2012

Have a look at the hidden text sample, that might help.

P.

W
WolfgangGoAuthor
Known Participant
March 15, 2012

Hi Pickory,

The hidden text sample, like most samples, is very simple, and thus it has only two interfaces on the panel widget boss. In such a simple case I can make it work too. My problem is that I cannot add two interfaces with IID_IOBSERVER to the panel.

I have now tried to replace IID_IOBSERVER by IID_ISELECTIONOBSERVER like in LinksUIPanelSelectionObserver, but in this case I'm not notified.

Wolfgang

D
Dirk BeckerCorrect answer
Legend
March 15, 2012

For notification subscriptions an observer can have any IID, as you found you can take IID_ISELECTIONOBSERVER, or any private one.

When widgets are shown / hidden, AutoAttach/AutoDetach of their IID_IOBSERVER is invoked automatically. If you need a secondary observer on the same boss, you have to query that other interface from within your IID_IOBSERVER observer, and chain the AutoAttach etc. calls.

If you put your observer on a non-widget boss, you also have to find a way to invoke AutoAttach/Detach from outside, for example using a responder.

The ISubject calls to attach/detach an observer to the subject also have an additional IID parameter for the very same IID.

For completeness sake, if you use CObserver it has a separate constructor argument that sets the internally stored AttachIID to different IID - use IID_ISELECTIONOBSERVER or whatever IID you chose in the object model. The underlying partial implementation for the selection observer should pick it up from there when it does its own attach/detach.

Finally, you must never ever reuse implementation IDs from the SDK for own implementations, or boss IDs for own bosses. You got your plugin ID space for a reason - to prevent collisions.

Dirk

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices