Find Command Glitch?

There seems to be a Find command glitch, where in some instances it will not find the search word even though it is definitely in the file being searched.

I first had a Scrivening open and locked in the editor. Then I opened one of those files in a QuickReference window and the Find command wouldn’t find words that I was able to find in the same file in the Scrivening. Then I closed the QuickReference window and opened that same file in the alternate Editor, same Find failure. In both instances sometimes Find would work properly, other times not. I have a vague sense that this failure might be related to either having first searched on the word in the main editor, then the find would fail in either the QuickReferece or alternate Editor view of the same file, or else it may have occurred when the Find window was left open in the background of the Editor (sometimes I had to close this Find window, open it again, then close it once more, before I could get it to work properly).

Very frustrating, and although I regularly get this problem, I haven’t been able to isolate the particular set of commands that reproduces it.

Mac running 10.8.5 and Scrivener 2.5.

Any thoughts?

I’m wondering if perhaps the keyboard focus isn’t in the editor when you first open the QuickReference panel. This may depend on whether you have full keyboard access enabled in Keyboard System Preferences. For me, when I pull up a QR window the focus is on the label widget, which is nice since I can change those with the keyboard if I want, it’s one of the few ways you can do so. But, it does mean Cmd-F and Cmd-G just beep if I try to use them. I just need to tab twice into the editor first.

Yes, of course, the focus was in the edit window when I tried to Find something in that window.

I did just discover that in QuickReference windows, when you use the Find command, it will only find things from the beginning of the file to the end. But once at the end it WILL NOT go back and start looking again from the beginning. This means that before Finding something, one needs to always place the cursor at the head of the file. Seems like this is inconsistent behavior should be corrected.

I’m not seeing that behaviour either. I can both search and have search wrap back around to the top of the QR editor without deviation. The only thing odd that I see is that when using the black HUD style for panels, the little symbol that pops up when search wraps around ends up in the main window instead of the QR panel, but it still works. What version of Scrivener are you running, and OS X?

Year-old MB Air, running running OS 10.8.5 and Scrivener 2.5.

When I switch to the black HUD style for QR windows, I do NOT see the the search wrap symbol at all. However, the behavior I see exactly matches that of the search wrap code getting hung up somehow. This does not seem to be affected by what is in the underlying Editor.

** I once tried to close the underlying Edit window, expecting to keep the QR window open solo, not realizing this would close the entire project. The project closed, but I also got a Scrivener crash (I just sent you the crash log). I could not get this crash to repeat. No idea if this might be related?

Okay, I’ve tested using the exact same configuration you are using, down to the hardware. :slight_smile: It’s still working fine over here, so it seems the bug requires some factor I don’t have. I would try re-installing the software from a fresh download, just to get that out of the way. Weird interface problems like this can sometimes result from a faulty install.

Perfect, downloading a fresh version of Scrivener did it.


Curiouser… I just discovered that some files are hindered in the above way, while most are not. And I can convert a misbehaving file into a well-behaved one simply by duplicating it inside the project.

Maybe the reloading of Scrivener didn’t really do anything, or perhaps a glitchy Scrivener application was creating these glitchy files.

If it is something you can reproduce so easily, it sounds like you might have a working example of the bug stored in the project. If you can do so, please send us a copy of the project to the tech support e-mail. Reference this thread URL so they can forward it to me.