Anyone seen this one?

Huh. I was just resizing my main window with the inspector set to Meta-Data (with Notes), when the notes text view went screwy and the top part of it suddenly covered the label and status popups. Not quite sure when this happened, but I had been resizing the window, playing with vertical split views, and resizing the binder and inspector.

The trouble is that now, no matter how much I try, I cannot recreate this and I cannot see why this would happen in my code.

Has anybody else seen this happen? And if so, can anyone narrow it down so that it happens every time?

It’s not a major bug, as you can either just reopen the project, or probably you can just swap the inspector mode and then swap back again to fix it, but it’s annoying mainly because I can’t track it down.


I have never seen that one, but I have a few others that have happened only once, or I cannot get it to reproduce reliably.

There was one where I quickly wheel-scrolled the top split, and the text actually smudged, as if I had run a bit smudge blur across it in Photoshop. I’ve never seen that before in any program, so I’m not sure if it is a Cocoa bug, or something unique to Scrivener. I’ve only seen it that once, too. It was in a document that I have a lot of Scrivener Links in, but I cannot recall if I actually had the links placed yet (they were added fairly recently). Another complexity is that this happened at work, where I use a Fingerworks Multi-Touch SL keyboard. This is a combined mouse and keyboard device, and “wheel-scrolling” is actually a four finger gesture on a touch pad surface – so who knows if it is doing something weird that is impossible to duplicate on ordinary equipment (it does input cursor movement keystrokes far, far faster than ordinary keyboards, for instance). Whether or not Apple’s two-finger scrolling is similar is a good question.

Another odd one is that unresolved bug where the first time you select a colour during certain actions results in it defaulting to black, and changing the existing choice to black without your command. Detailed here.

As for your first one, this is a Cocoa bug. I am sure I sent you a screenshot of the same thing a couple of weeks back when we were discussing something or other off-list (yes, subject “*note box error”). I have seen this a few times in Scrivener, and can recreate it in certain situations in TextEdit (the screenshot I sent was actually taken in TextEdit).

Yes, that is precisely it. I forgot about that screenshot and just took a look at it again. What a weird one, but good it is just a Cocoa thing – and fairly rare at that.

I see that Fingerworks have gone out of business!


It has been gone a few years now. Before I was ever able to afford a full size keyboard too. :frowning:

EDIT: Explanation of joke - as far as keyboards are concerned the Fingerworks products were astonishingly expensive. So much so that as far as I could tell their only long term business plan was to go out of business.

I think I must be missing something - maybe because it is late here. What has FingerWorks got to do with this post? Must be missing the joke…

I think that’s the connection, Keith. :slight_smile:

Thanks Jot, spot on. That is the connection. I was trying to suggest, like some idiot cyber-detective, that if Fingerworks gave a clue to the problem then the problem could more easily be hunted down. Because Fingerworks itself caused people to get messed up text it might just help Keith join up some of the dots to figure out if a pattern exists for this particular bug.

It happened to me and I am using a TactilePro keyboard. I thought, rather than a keyboard issue, it might be a preferences file issue. It happened once and I just let it slide as a weird artifact, rather than report it as a bug.

I’ll spell it out next time.


I think his point is that the original post in this thread was about a note field resizing issue, which try as I might, I cannot reproduce either.

Thanks. You can see I was having a “dense Sunday” yesterday. :slight_smile: I should re-read things before posting, obviously… Anyway, the Fingerworks mouse has nothing to do with the issue about which AmberV was posting - that is just a Cocoa bug. The bug about which I was asking is nothing to do with either of these, it is just a rare resizing bug.