Find and Replace doesn't go to page if cursor is already on that page

[MikeTO]

1. Create a document with at least two pages and a text frame on at least the first page
2. Type some text on page 1
3. Scroll to the last page
4. Use Find to search for the text on the first page - Publisher thinks the first page is still the current one so it won't snap the view to it - double clicking the search result won't change pages
5. But if you type now, you're typing on the first page

The only way to show the first page is to scroll bar or to place the cursor on the visible page and then use Find to search for that text on the first page. But of course if you started typing you overtyped the selected search result so you won't be able to find it now.

This isn't new, it's in 1.10, too.

[walt.farrell]

45 minutes ago, MikeTO said:

Scroll to the last page

 

45 minutes ago, MikeTO said:

Publisher thinks the first page is still the current

And it probably is current, if you only scrolled.

What does the Page Navigator in the Status Bar show?

[MikeTO]

29 minutes ago, walt.farrell said:

And it probably is current, if you only scrolled.

What does the Page Navigator in the Status Bar show?

Page 1. But still it needs to display the page for the selected search result.

[walt.farrell]

14 minutes ago, MikeTO said:

Page 1. But still it needs to display the page for the selected search result.

It should, true.

[Hangman]

On 11/2/2023 at 6:00 PM, MikeTO said:

Page 1. But still it needs to display the page for the selected search result.

This is simply because of how you're viewing Page 1, it's no different to scrolling Page 1 off-screen horizontally, you've 'chosen' where to position Page 1, either in the viewport or outside the viewport, regardless, Page 1 is still selected up until the point you select another page, you've just chosen for it to not to appear in the viewport itself.

Having Page 2 selected, i.e., so Page 2 shows the grey border around the page in the Pages panel and then doing a Find for text on the first page will correctly bring Page 1 back to the centre of the viewport.

This is no different to typing with Page 1 selected but not visible in the viewport, Page 1 is still selected so your typed text is added to the page as you would expect but you've decided to position the page outside the viewport for whatever reason.

[MikeTO]

2 hours ago, Hangman said:

This is simply because of how you're viewing Page 1, it's no different to scrolling Page 1 off-screen horizontally, you've 'chosen' where to position Page 1, either in the viewport or outside the viewport, regardless, Page 1 is still selected up until the point you select another page, you've just chosen for it to not to appear in the viewport itself.

Having Page 2 selected, i.e., so Page 2 shows the grey border around the page in the Pages panel and then doing a Find for text on the first page will correctly bring Page 1 back to the centre of the viewport.

This is no different to typing with Page 1 selected but not visible in the viewport, Page 1 is still selected so your typed text is added to the page as you would expect but you've decided to position the page outside the viewport for whatever reason.

I know all this. It's still a bug. If you click a search result it is supposed to take you to the search result, regardless of what page Publisher thinks you are viewing.

[Hangman]

1 hour ago, MikeTO said:

If you click a search result it is supposed to take you to the search result, regardless of what page Publisher thinks you are viewing.

That's the point, it does but you've chosen how you want to view the page...

If you have a document and you zoom out so the page appears at say 10%, performing a Find for text on that page still finds and highlights the result when selected in the Find and Replace Panel but it doesn't change the zoom level you've set...

Likewise, if you scroll the page left or right so it no longer appears in the viewport (for whatever reason), selecting text in the Find and Replace panel again finds and highlights the result but it doesn't change how you've decided you want to display the page.

Individual pages sit in what appears to be an infinite space scrollable in any direction and zoomable between 0.2 and over 2 billion per cent.

It would actually be incredibly annoying if, for example, you've decided you want to display the document in a specific way or at a particular zoom level if every time you click a search result in the Find and Replace panel Publisher decides to change the way the page is displayed, e.g., by changing the zoom level you've specifically set...

So clicking a search result is taking you to that search result but it's also honouring how you've asked that page to be displayed...  

[MikeTO]

Thank you, but I know exactly how it works and why it's working this way but it doesn't align to industry standards or even to Publisher's help page: "Select any result in the list to focus the document view on the corresponding text on its page".

Since the dawn of computers users have been typing their own bookmarks such as ** and then searching for them as a way to jump back to where they were. I've never seen an app that can't perform this basic task.

[Hangman]

Whether this is 'by design' or a 'bug' I really have no idea and I don't necessarily disagree with you, I'm just pointing out the fact that there's an additional element at play here which needs to be taken into consideration, i.e., the Page View. In the example you cited it doesn't matter how far you scroll, you will always have Page 1 selected...

Based on "Select any result in the list to focus the document view on the corresponding text on its page", what is your expectation when you zoom out so both Pages 1 and 2 fill the viewport prior to doing a Find?

Anyway, if it's a bug, it will be logged as such, if it's expected behaviour then I'm sure we'll hear from someone in the Dev team and it will be logged for improvement.

[Old Bruce]

I have to agree with @MikeTO that there is something going on with the Find not jumping to highlight the string if the text caret is in the text on the page which contains the string. I see this happening a fair bit. Has been happening for a while. I do find that selecting / hitting find again will jump to the next occurrence of the string though. Not much help if the string results in a unique found instance.

[DWright]

This Issue has been logged with our developers