It is usually slow to reflect an object selection or change of object selection, sometimes it does not reflect it at all.
Having selected two objects in the model, boxedit recognises only one item selected and dimensions reflected the single object (sometimes).
Model selection highlighting disappears, possibly with a Rhino-originated (not user-originated) shift of focus to boxedit (boxedit window open, undocked, before selection(s) made).
4.When boxedit first opened and a size scroll button clicked, the increment applied is 1 regardless of value in the increment box. You have to change the increment value and then change it back to get the correct value to work.
When typing a value into a field the field update lags behind the keystroke, sometimes by seconds.
If digits in a field are highlighted, typed values do not replace them as is normal, they are appended.
Boxedit performance gets even worse when a second, high-definition, screen added to system and used to display Rhino viewports (in 6.3, not yet tried in 6.5).
All the above is with a floating boxedit panel: I don’t dock it.
System information (note the release candidate has updated prior to grabbing this);
Rhino 6 SR5 2018-5-12 (Rhino 6, 6.5.18132.5131, Git hash:master @ b8b8945d46018b7f175f54f1e384ede46df9745d)
Licence type: Commercial, build 2018-05-12
License details: Cloud Zoo. In use by: Jeremy Swift ()
Windows 10.0 SR0.0 or greater (Physical RAM: 16Gb)
Machine name: SB-JEREMY
Thanks Jeremy, I posted elsewhere but I am also finding trouble with Box Edit. I used this a lot in R5 and it worked great, but in R6 is giving me issues such as the listed above. I’m also having issues with “transform individually” for the position parameter (for example if you set all Z values to zero, it won’t move all itmes to coordinate Z zero as it used to but applies a zero unit transformation, so would be same as not having the individual transformation ticked… BoxEdit is a great tool, and the added features in R6 are very promising but we need it fully functional and fast as it was in R5.
Thanks team!
Hi Jeremy - thanks - the slow select/update is known and getting attention. I am trying to reproduce the other things you mention - so far, I am not successful, but I am setting up simple tests, not working for real… I will continue to mess with this - I do have two screens, one is hd.
I thought I’d copy part of my model and create a test environment for this, but boxedit behaves better in it, so maybe problems only build after you have been opening and closing the panel a lot, or doing a lot of modelling. I’ll keep an eye on that.
I waited a couple of minutes before recording this in case this was just the usual slow response.
I normally do screencaps with SnagIt, but the undocked boxedit panel disappears when I open SnagIt and then reappears once I close it - when it reappears it has been populated with the missing values…
Hi Jeremy - the trick to capturing floaters with Snagit (etc) is to temporarly set the Rhino command testHideOnDeactivate to not hide floaters when Rhino loses focus. But - no need, I believe you.
Now, there’s been, just today, a bottle-neck clearing in BoxEdit that should help most and possibly all of the issues- I’ve seen it in action and it’s back to being fast. The bad news is that the fix is for SR6…
In case SR6 is not the universal panacea, here is an example where objects selected in the viewport lose their yellow highlighting and show as black (n.b. their line colour is set to red) following the boxedit panel displaying the values that apply to the objects:
It caught my attention because I would recommend to have the possibility to keep floating viewports visible when switching to another App. In my case I would often like to keep the image for reference while working in another application on the main screen.
Edit
just noticed that there is a typo in your post and I just copied the command without looking.
testHideOnDeactivate works… without the r
and in deed it also affects viewports not just toolbars
great!
