Utterly reproducible crash

Versions afftecte: Beta, Rhino 7, Rhino 6, doesn’t matter. Been there for a while, got asked for a 3DM file last time, you don’t need one.

Select any object, doesn’t matter what it is. Edit it’s name in the properties. Because of the annoying behavior of the name field in the properties (also discussed previously) it remains highlighted when you hit enter (and it shouldn’t, as any text you type afterwards renames it, when you THINK you are entering a command. The number of objects I have in projects that are named “move”, “copy”, “CPLane” etc is off the hook, and is particularly frustrating as I tend to name things for a reason so when I come back to them I remember why this line at a goofy angle having out in space was for amidst all the other construction geometry, but I digress.

With the utterly annoying name field still highlighted, select export selected from the file menu.

Blammo, death by annoying Name Property Field.

Does not matter what version, Been there since V6. Doesn’t matter which Mac OS version.

You do not need an uploaded model file to reproduce this, it happens all the time, specifically any time you rename something (which I always do right before exporting it as 3MF) and FORGET to click on something else to kill the accursed “remains highlighted for no good reason” name property text field.

Rant mode offf.

Sorry, just had it happen again for the 3rd time today, and was annoyed.

I’ll try to reproduce it.

Did you send in a crash report with your email address so we have a call stack pointing to the problem?
If not, please do so.

Thanks

Running V7

  1. I started a new file
  2. Drew a rectangle
  3. Selected it and gave it a name “Box”. Creative, I know.
  4. Deselected the box clicking in empty space.
  5. Selected it and renamed it “Box Box”, then “Box Box Box”
  6. Pressing Enter when the name is selected does not crash my Rhino.

What are you doing differently?

V6 acted exactly the same way.
No crash.

This is a 16" MBP running Big Sur.

In Windows, the cursor goes to the front of the field when I press Enter.
Still no crash

You didn’t read it all.

I suspect the crash is because the name property text is SELECTED and when you hit “export selected” it’s somehow thinking the text fields selection is a model and pukes at that point.

1 Like

I’ve sent dozens of crash reports with this exact bug.

Pretty much every time it happens, unless it’s the 3rd or 4th of the day.

It turns out Mac crash reports can’t be processed automatically like Windows reports can. That’s why I can’t find any.

I tried it again.
Drew a box, named it, changed it’s name, and with the name selected, I ran ExportSelected by using the ExportSelected under the Save icon.

I tried ExportSelected again from the File pull-down menu, and did get a crash.

Thanks for the clarification.

Using the icon is a good temporary work-around.

I’ve added a defect report:
https://mcneel.myjetbrains.com/youtrack/issue/RH-62076

I can confirm that this causes a crash for me.

@LewnWorx
The developer identified the problem and just checked in a fix.
I’ll be able to test that fix later this week.
My guess is it will be included in the 7.3 service release.

Thanks

@John_Brock

Thankee.

Any particular thing mac users need to do to ensure the crash reports are being seen? I was utterly unaware that the hundreds of crash reports I’ve sent in over the past few years aren’t being seen, just sorta figured the “send to McKneel” button on the dialog meant you folks were getting those…

Now if we could change the behavior of the text remaining selected (which results in inadvertantly renaming objects on a far too regular basis, as you rename it, hit enter, forget it’s still selected, go to type a command and thus rename the just named object to the command name, that’d be spiffy.

I have hundreds of objects that are named after commands, which isn’t particularly helpful, as the whole point of naming them is to assist when selecting amongst multiple overlapping objects, to allow one to recall why this particular curve or object which serves as construction geometry to be understandable hours days or weeks later, only to discover the painstaking time spent naming all this stuff is for naught as they’re all now named “move”, “copy” or whatever.

You’re mistaken.
Mac crash reports are seen and we used them anonymously to try to find patterns of problems to fix.
We do the same thing for Windows crash reports, but because on the differences between them, we can automatically process them and tech support people can get a very brief look at how many crashes from an email address, and how the processing tagged them. It give us a little glimpse into what might be the cause of a problem that we do not have for Macs.

As I mentioned, the fix was checked into code this morning.
I’ll test it later this week.
It will be in the next Service Release Candidate.

Here is an example of what I can find a a tech support person from a submitted Windows crash.
This is what an Intel GPU driver crash looks like:

I don’t get this information from Mac crash reports.
They need to be manually read by a developer with the right tools.

@LewnWorx

I just tested the fix.
It will be released in V7 SR3
It will be available as a Service Release Candidate when V7 SR2 is released.

Thankee