I work with the properties panel on a separate monitor.
If I put the text cursor in a text field on that panel to enter a value, but move the mouse back over the rest of the Rhino GUI (without clicking) before I’ve typed the new value in, the new entry is ignored and the value stays as it was. In other applications, once the text cursor is placed in a panel that’s outside the main apps window, it stays receptive until something is entered or the mouse clicks elsewhere. This may be preferable performance.
Hello - On a single monitor here, I ‘restore’ the Rhino window to a small size and float Properties off to one side. I make some text, select it and in the Text field of Properties, modify the text… here, if I move my mouse off of Properties to the main Rhino window (no click) typing still goes to the Properties page. I think I understand that this is what does not work for you, on two monitors.
Can you try that, just to try to determine whether or not it is a two-monitor thing you are seeing?
I’ll go pick up a second monitor from the office in the next day or two if need be - would not be a bad idea anyway…
Thankyou Pascal. The issue isn’t restricted to a second monitor configuration
It occurred again this morning with a Properties Panel floating over the desktop (on the same monitor as Rhino).
The exact triggering actions I can’t determine.
When the bug occurs the behaviour in one instance was consistently thus: in a Text object’s Text Properties window (other object properties windows or incidences of the bug may differ) the text cursor disappeared / became inactive only if the mouse next passed - even for the shortest time - over any of the six formatting icons above the text input field on the text properties window. I did this repeatedly in one instance of the bug and the behaviour was consistent.
I then activated the Text Object’s General Properties window (and other windows on the panel) but couldn’t produce the bug on them. On returning to the Text Properties window I then couldn’t reproduce the problem, nor by various types of selection and reselection of the Text object, nor closing/reopening Properties Panel nor the project.
But there’s definitely an intermittent bug, and I’ve seen it in numerical input fields as well, which is of more concern.
It’s dangerous because it can easily go unnoticed and cause errors when working quickly in the usual manner by simultaneously moving with the mouse to select a next object while 1) inputting a new value for a currently selected object and 2) hitting enter. If those two actions have had no effect and the previous value remains unchanged for the first object, a user’s attention is now on the next object to be edited and important edits will remain undone though the usual action to make them has been taken.
I’m not going to work with the properties panel floating for now.
But just because I’ve noticed it in that configuration the intermittent bug may not only be in that condition. I’m changing the title of this thread to something more specific.
It’s not “2) Hitting Enter” above, it’s left clicking anywhere on the Rhino interface to end the field input which (when Bug’s active) actually deletes whatever’s been typed into the input field and the value reverts to its previous one.
Hi - I would say that the behavior that you show in that screen capture is the expected behavior (which I can easily reproduce on my single laptop screen here). You are moving the mouse away from the Properties panel. At that point, the focus is still on that panel (even though the mouse is not) and keyboard entry will end up in that panel.
The moment you move your mouse of a different panel, though, the focus gets shifted to that different panel and keyboard entry ends up there. In your specific example, this behavior allows you to, for example, modify the names of layers without having to click on them with the mouse.
-wim
