RHINO5 (&WIP): BoxEdit with Multiple Files open -> Crashes


I’m having regular crashing occur in both Stable and WIP with BoxEdit
It seems to occur when I have more than one file open (Seems to work with as little as 2 open).
I can’t recreate it 100% accurately, but can make it crash purposely within 1-2 minutes if I try. It seems to involve a mixture of me selecting geometry in one or more drawings, moving some solid geometry (In this case I’ve been rotating a polysurface) and then using BoxEdit.
Upon the BoxEdit GUI appearing I get an Error as shown at the bottom of the post.

Example actions to attempt crash:

  1. Open 2 different drawings
  2. Select a Solid in first file
  3. BoxEdit -> Works as expected
  4. Select random assortment of Solids, Groups, Blocks in second file
  5. Go back to first file and transform selected geometry
  6. Try BoxEdit
  7. If doesn’t crash, reselect other geometries in both files and repeat steps 4-6

I’ve had this crash happen a couple of times a month previously but never been able to spot what’s been happening. It’s only after intensely using BoxEdit this week that i’ve been able to narrow it down somewhat.

System.IndexOutOfRangeException: index
          at Rhino.Collections.RhinoList`1[Rhino.Geometry.Point3d].get_Item (Int32 index) [0x00000] in <filename unknown>:0 
          at Commands.Commands.BoxEditViewModel.GlobalDimX () [0x00000] in <filename unknown>:0 
          at Commands.Commands.BoxEditDialog.UpdateDialogControls (Boolean bFindSelectedObjects) [0x00000] in <filename unknown>:0 
          at Commands.Commands.BoxEditViewModel.OnTimer (TimerType timer) [0x00000] in <filename unknown>:0 
          at Commands.Commands.BoxEditViewModel+<CreateEventTimer>c__AnonStorey0.<>m__0 (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0 
          at Eto.Forms.UITimer.OnElapsed (System.EventArgs e) [0x00000] in <filename unknown>:0 
          at Eto.Forms.UITimer+Callback.OnElapsed (Eto.Forms.UITimer widget, System.EventArgs e) [0x00000] in <filename unknown>:0 
          at Eto.Mac.Forms.UITimerHandler+Helper.Elapsed () [0x00000] in <filename unknown>:0 
          at MonoMac.Foundation.NSActionDispatcher.Apply () [0x00000] in <filename unknown>:0 
          at (wrapper native-to-managed) object:[MonoMac.Foundation.NSActionDispatcher:Void Apply()] (MonoMac.Foundation.NSObject,intptr)


(Sorry for the delayed reply)

Thanks for reporting this and providing steps. Unfortunately, I’m not able to reproduce it on my end. If I could trouble you to provide a FileA.3dm and a FileB.3dm where this happens, that might help.

@JohnM you might want to take a look at the exception above.


Hi Dan,

2 files attached, Instructions are in File A

I narrowed it down to a specific block in my model (in ‘A’), might help figure out what’s happening, File B is just a cylinder I made to test with.

I just tested it 3 times, it crashed each time


FILE_A.3dm (2.6 MB)
FILE_B.3dm (2.3 MB)

Just back from vacation, looking into this now.

Created RH-41355 and assigned it to @tim since this is his command.


I tried to repeat your crash with the files you posted on September 7 and the instructions from both September 7 and August 18 and I cannot a crash to occur. I have geometry selected in both models and when I switch between the two I see the BoxEdit controls update pretty instantly. The dotnet exception info in your post from August 17 mentions something about an index out of range in the GlobalDimX function. That is an index into a 9 point array (8 bbox points and one pivot) and GlobalDimX function always uses 0 and 1. So it seems like maybe on your system the viewmodel switch (which happens when you switch models) gets hungup or something. Can you tell if the crash is more likely to occur based on the speed you switch models and touch boxedit controls? Like it crashes more often if you go real fast and less often if you go slow.


Hi Tim,

That’s unfortunate that it can’t be replicated. I’ve just tried to recreate it myself and had to repeat the steps a couple of time to crash, so it’s not always a given on my machine. It seems to work more frequently when I hold shift to select geometry.
It feels a bit buggy when switching windows like it’s selecting geometry from the previous window when I switch over, most times the Gumball in File A will be shown at the position of the cylinder in File B upon switching window, even when the block in A is already selected.

I’ve often been working with the models in question for 10+ minutes, because i’d then use BoxEdit after forgetting and suddenly panic when I realise I had more than one window open knowing that it would inevitably crash.

Would it be helpful for me to upload a video of the crash in action?



Yes I think a video would be very helpful. I didn’t know that the gumball was part of the equation and a video will show little details like that. Based on the dotnet callstack you initially posted I suspect there’s a very specific set of steps involved that you do frequently and we’re not doing.


I only just noticed the Gumball thing myself

Attached a video. The second time I select the block in File A is with shift held down (not sure if it makes a difference though)

Hopefully this makes it clearer

OK. Thanks. I was able to get the crash. I’m on it.

This crash should be fixed in the latest RhinoWIP (5E236w). Please give it a try.

1 Like

Seems to work, thanks!

1 Like