Issues with Boxedit (in 6.5.18128)

Could boxedit get some love? Lots of issues:

  1. It is usually slow to reflect an object selection or change of object selection, sometimes it does not reflect it at all.
  2. Having selected two objects in the model, boxedit recognises only one item selected and dimensions reflected the single object (sometimes).
  3. 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.
  4. When typing a value into a field the field update lags behind the keystroke, sometimes by seconds.
  5. If digits in a field are highlighted, typed values do not replace them as is normal, they are appended.
  6. 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

GeForce GPU/PCIe/SSE2 (OpenGL ver:4.6.0 NVIDIA 388.08)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: Height

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 10-19-2017
Driver Version:
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 1 GB

C:\Program Files\Rhino 6\Plug-ins\Commands.rhp “Commands”
C:\Program Files\Rhino 6\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 6\Plug-ins\RhinoRender.rhp “Rhino Render”
C:\Program Files\Rhino 6\Plug-ins\rdk_etoui.rhp “RDK_EtoUI”
C:\Program Files\Rhino 6\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Common Files\McNeel\Rhinoceros\6.0\Plug-ins\PanelingTools (6caed836-bc06-4ebc-b1fd-e10886a0dc94)\2018.3.1.650\PanelingTools.rhp “PanelingTools”
C:\Program Files\Rhino 6\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 6\Plug-ins\RhinoCycles.rhp “RhinoCycles”
C:\Program Files\Rhino 6\Plug-ins\Toolbars\Toolbars.rhp “Toolbars”
C:\Program Files\Rhino 6\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 6\Plug-ins\Displacement.rhp “Displacement”
C:\Program Files\Rhino 6\Plug-ins\Calc.rhp “Calc”
C:\Program Files\Common Files\McNeel\Rhinoceros\6.0\Plug-ins\SectionTools (fbdb1d7f-8cfb-42c1-9858-87cb6315932c)\2018.1.9.1166\SectionTools.rhp “SectionTools”


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.


Hi Pascal,

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 can reproduce the incorrect increment issue from the off though: Note that this applies to all the increments, not just size.


And here is an example of boxedit showing nothing selected when items are:


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…


Thanks Pascal, good to have something to look forward to!

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:

Closing the boxedit panel restores the yellow highlighting in the viewport:

excuse my side kick, but Pascal I am wondering about the testHideOnDeractivate command.

because it does not work here, latest update installed.

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.


just noticed that there is a typo in your post and I just copied the command without looking.
testHideOnDeactivate works… without the r :slight_smile:
and in deed it also affects viewports not just toolbars :smile:

Sorry - fixed the typo above - thanks!