There are plenty things wrong here. Welcome to a different world.
As a rough concept, an observer is notified for changes within or close to a particular object. So you'd watch for some very special aspect of a single page item, e.g. its attribute or its position (geometric bounds), or when it gets associated with a different link.
With your approach you'd have to attach such an observer to every single of the 10.000 images within the publication / document. Won't work. Instead, typical page item notifications are also notified at the document object itself. But only, when the item itself changes.
If you select an image, most of the time you actually select the enclosing page item which is a spline item. You'd use the direct selection tool (the other arrow) to select the image, likely you do not want that limitation.
Then, this is about the selection. A very different thing than the actual image. Your observer should observe the selection rather than the page item. Search the SDK for SelectionObserver, it is a bit complicated to even follow the selection across multiple windows of the same document, or other documents, or no document at all.
Your other approach to add an event handler is a no-go, as neither the image item boss nor the interface are yours. There can be only one implementation for an interface, that becomes part of the overall object. This is unlike scripting where any object can accept a ton of separate event listeners. Anyway, event handlers are far too lo level, forget about them. You would not want to decode the mouse click on an image to back-guess that it might have something to do with selection. That mouse click would get decoded in a far different object.
Let's return to the selection though. InDesign's selection is an abstraction. You might have selected no item, one, or a multitude of them. Different ones - text frames, form fields at the same time. Within the structure selection (aka XML) you might have a selection across many pages. Text frames, via their story, can also have a link.
To correctly participate in the selection, you have to think about those cases. You ask the selection to get its (in your case: image link), in an abstract way, and it deals about it in all the different concrete cases.
E.g. you have a text selection with three anchored image anchored somewhere within character 200 and 399, would you consider their links?
Also there are more kinds of images - as you mention kImageItem but omit PDF, EPS, WMF and so forth. What do you want to see, and later on what do you want to modify, when there are multiple images selected. Or if only one page item is selected that happens to be a group of 10 spline items which all enclose a different kind of image.
This concept of an abstract selection with different concrete implementations is expressed by a suite, as you already have found one. It is not meant though to just pass you the selection and let you work on that from outside. If you want to work on details, you have to implement your own suite. Define how they are aggregated across the multi-selection (even if that to you just means to give up and show blank) of each concrete selection's target. There you'd also handle the cases of these nested images (group, anchored etc.).
Finally, as you say "my goal … when I click or select it" - the click is a different beast. E.g. you can have an image locked (see layer panel) so not selectable, but use the eyedropper tool to pick up some attributes from it. That would be a click. A link-peeker could even display the link below it on mouse-over. Completely different subsystem, and somewhere closer to an event handler. Do you really want that?
1 Correct answer
13
Replies
AdChoices