hm, I'm trying to understand the problem you are in.
The active page can be determined with looking at:
It's index can be seen from:
You could check this every time an IdleEvent.ON_IDLE is emitted to a listener that can be done with an IdleTask object that is added to the app.
Ok, the title of this thread says "latest selected page".
That makes no sense to me. Or at least I do not know what you mean…
What do you think is the "latest selected page"?
Can you describe that in more detail?
Do you mean a selected page in the Pages Panel?
If yes, more pages than one can be selected at one time.
And one can only determine this if the panel is visible.
In your code snippet you are trying to use app.activeWindow.
That would be either a layout window or a story window. If a story window is the active one you cannot tell from that window the active page. If text is selected that could span several pages or spreads.
So ?? …
Ok, as you already noticed I'm quite new to InDesign specifics.
I have an old plugin that stores some metadata per page, I didn't do it, it was done with AS3 and now I'm porting it to JS.
How the old one works and the desired result is that you click on a page, that page gets selected and you see its metadata. You can click on the page even if its empty or in an item of the page and it works.
Looking at the code it uses quite some code and I was trying to simplify it.
The easy way would be using what you suggested of the activePage, but is not the same, since old users would be used to consider the pages metadata displayed to be from the last page they worked on, even if the scroll out of it.
In our scenario we would never have pageItems that spread across multipe pages.
Looking at the code it uses quite some code and I was trying to simplify it. …
So you cannot mean the Pages panel where the user is clicking the page. Ok…
Hm. I think my supposed listener attached to an IdleTask in combination with an idleEvent should work.
Though, I do not know if it would be sufficient for you. You also have to time the listener. If it will report too frequently it could perhaps slow down InDesign. If it will report not often enough you could miss a page…
For documents with one page per spread it should work.
With more pages on a spread like in facing pages documents there could be a problem.
I can be wrong here, but I think, that depending on zoom level and size of a page showing in the layout window a user could click on a page and still that would not make the page the active one.
Regarding selected page items crossing the page in a facing pages document:
One single page item is either on a page or not. Its parentPage value could be a distinct page object or null.
If null it's associated with the pasteboard surrounding a page.
What I do not get is how you like to determine from a selection—one or more objects selected all over a spread—what the "active" page should be? I mean, there is always a value for activePage in a layout window. Problem with that: is it the one a user would expect from such a feature?
Did you analyze the AS3 code how it will get the active page?
Hi Uwe, thank you for your help I really appreciate it,
the current code dispatches a custom event on the following situations:
IDScriptingEventAdapter.getInstance().addEventListener(Window.AFTER_ATTRIBUTE_CHANGED, this.handlePageChanged);private function handlePageChanged(event:com.adobe.indesign.Event):void
var actualPageIndexLocal:Number = (Spread)((LayoutWindow)(event.target).activeSpread).index;
if ((actualPageIndexLocal != currentPageIndex) || (actualPageIndexLocal == 0))
//trace("Actual Page: " + actualPageIndexLocal);
currentPageIndex = actualPageIndexLocal;
//Propagamos el evento a PageInformationPanel
trace ("ERROR: " + error.name + ": " + error.message);
After looking the old code more carefully, maybe its as easy as doing just what I pasted, does it make sense to you? I don't understand why the used event is AFTER_ATTRIBUTE_CHANGE but if it worked before... :-).
it could make sense to use AFTER_ATTRIBUTE_CHANGE . But I doubt it.
First of all, I think the custom handler is implemented a bit "sluggish".
Variable actualPageIndexLocal holds the index of the activeSpread. And not the activePage.
So perhaps you will get only info on the whole spread and not the active page.
No sure thing if you want to get info off a single page in documents with more than one page per spread.
I would test that very thoroughly.
Second, I ran a small test with several listeners on a 10 facing-pages document where I zoomed to 5% to see the whole document at one glance. If you now do a listener with AFTER_ATTRIBUTE_CHANGE on the layout window you have no chance to see a change in activePage or activeSpread if a user double-clicks a page. The "active" page in the Pages panel will change. But activePage.documentIndex or activeSpread.index will be the same than before. Why? The listener is not notified of a change.
With an idleEvent listener on an IdleTask object that is controlled on a timely bases ( every n milliseconds ) the same thing would happen.
But here comes the difference:
In a situation like that you have a chance to open the Pages Panel every n milliseconds and check what the selected page is there. ( Before you may close it again if the Panel's visible property was false before )
Just an idea, not tested well enough…