I often find that the Find/Replace window obscures the view of a found result in the original document, necessitating movement and/or resizing of the Find/Replace window or of the actual document window. It’s a nuisance.

It occurs to me that a relatively simple solution (at least, I hope you think it is, Martin!) would be to incorporate the Find/Replace dialog box in the Palette system. Ideally it would be available as a top-level item in the Palette Dock, and the Show Find… menu command and its shortcut would make the Find/Replace Palette Group the active Palette Group. The Find and Replace fields (text boxes) would need to be sufficiently large to accommodate lengthy expressions.

This way, full view of both the document and the current Find/Replace parameters would be retained during (manual) Find/Replace operations.

So I’d like to submit this as a feature request, particularly as Find/Replace is such an important component of word processor functioning and hence should be as easy to use as possible.

Thanks for the request Adrian. It certainly seems like a decent idea, at least as an additional optional way to access the find system, for those who might want it.

The trick here is making sure this hypothetical new find palette includes enough options and controls to be useful (eg: buttons for Find Next, Find All, etc) but not too many so as to appear cluttered. I think stuffing the entire current Find & Replace panel into a palette would be cramped and result in a poor experience. I'll certainly file the idea as something we can mull over.

In the meantime, I'll also file a smaller change request: if the find result / match in the document text is obscured by the find panel, Nisus Writer should just autoscroll the document area so the match is made visible (if possible).

I think it is possible to implement a Find Palette that offers all the required options within the confines of the Palette Dock but without appearing unduly cramped. And here’s proof!

Find Palette.jpg (257.21 KiB) Viewed 2152 times

This is a screenshot of a mockup on a 13-inch MacBook Pro. The window extends to the full height of the screen (apart from the main Menu Bar); the screen extends horizontally beyond the image. The document happens to be A6 size, but this is of little consequence in the present context. The important thing to note is the relative sizes of the Palette Dock and the content of the Find Palette mockup. All the options of the traditional Find/Replace window should fit in the Palette Dock without the need for scrolling within the Palette Dock — and this is on a small screen. Scroll bars that appear automatically in the Find and Replace fields when needed would probably be required.

I haven’t bothered to get the sizing of things exact: it’s just a mockup, after all. But I would go so far as to suggest that it would even be worthwhile extending (marginally) the width of the Palette Dock as a whole if that’s what it took to accommodate a non-cramped Find Palette.

The user could always choose to make the Find Palette a Floating Palette if desired.

In the mockup, I have used different highlight colors to distinguish between buttons and drop-down menus. Icons used are merely indicative.

I have taken the opportunity of suggesting alternative wording in places, as I for one find some of the existing wording confusing.

One technical issue that occurs to me is that the Find and Replace fields would need to be responsive to relevant choices from the main hierarchical menu (for example, when choosing a font). I think this would make the Find Palette unique amongst the Palettes.

Thanks for your additional thoughts on this potential enhancement Adrian. One thing that didn't come through: your mockup screenshot does not show. It looks like you added the image as a forum attachment, so I'm not sure where the problem lies. You might try posting it again.

I had thought of having the Find/Replace window move out of the way of the found term, but things might get too distracting

I absolutely agree with that. The Find/Replace window should not move automatically. That would be incredible distracting, annoying, and make subsequent clicking (eg: to repeatedly Find Next) very frustrating. The proposed solution is to have the *document text* autoscroll in such a way as to avoid the find panel. Basically what Nisus Writer does already (autoscroll find results into view), but avoiding the region on screen that's obscured by the find panel.

Sorry about the image’s failing to display. It did when I originally posted it.

I have had a lot of difficulty trying to re-post it now. Hard to get it to appear only once, and in the correct position. I tried drag-and-drop, inline button, img tag, URL with and without attachment tag. Original PNG file was rejected as too large, so I converted it to a reduced-size JPG file. No explicit instructions in the Forum FAQ about any of this makes posting images unnecessarily difficult.

Anyway, I’ve edited the posting so at least the image appears there now, albeit twice. You might be able to edit my posting so it appears properly, Martin.

Thanks for fixing the image. I think you just missed the "Place Inline" button that appears next to any attachments you upload while creating a post. That inserts the proper phpBB tags, which is the reliable way of showing an attached image inline, instead of manually managed [IMG] tags. I edited your post to eliminate the duplicate image.