Yet another utterly replicable crash bug involving the Name Property Text Being highlighted

Rhino Rhino for Mac
1

Ok, this is just getting stupid. I’ve been BEGGING for months to not leave the name property field text highlighted after renaming an object. Besides the obvious PITA of having most of the objects I carefully name get renamed because you insist on leaving the entire text highlighted after one changes the name property which results in all my careful naming to self document construction lines / history and whatnot being utterly wasted because they all get renamed again with whatever you type next (my Rhino projects have thousands of items named “move” / “copy” / “line” whatever) here’s yet another fatal bug.

Don’t ask me for a project file because you don’t need one. READ the instructions. If I sound pissed it’s because I am. I’ve had it with this one thing causing so damn much grief.

So here’s the FATAL crash due to the stupid behavior of the name property field remaining highlighted after one changes the name of objects.

Drawing a couple objects. Does not matter what they are, lines rects, it’s irreverent.

Select them. Go to properties and name them anything. Hit return. Now go to Edit / Groups / and group them. Instant crash.

FFS this is like the 3rd or 4th fatal bug related to the asinine practice of leaving the text highlighted after renaming and while you keep fixing the symptoms you never address the cause.

If I wanted to continuously rename stuff I’d reselect the text in the name property field and do it again. I don’t need you to keep the text selected for me only to utterly waste hours of careful naming of things to have that all lost because of this behavior.

Please fix this as it is reaching a boiling point for me that I’m ready to go back to autocad. At least with autodesk they make it clear they could give a rats ass if the 20 year old bugs ever get fixed.

This has been going on now since V5 and I’ve filed literally dozens of bug reports on it that for whatever reason your system ignores all the mac generated crash reports. Why even bother having a crash report mechanism it if it just goes into the bit bucket and gets ignored?

Sorry but I just lost 2 hours of work due to this and it’s not even close the first time that damn name field thing has cost me a bunch of time.

The auto save thing doesn’t help me as my files are on a NAS which doesn’t support Apple’s behind the scenes auto versioning auto save hocus pocus. So my choices are to save every few minutes manually and put up with Rhino harassing me for my frequent saves which leads me to yell at it “if you din’t friggin crash all the damn time I wouldn’t have to save so friggin much”.

Pardon the rant, but I’ve had it.

2

When they are reported, with a repeatable example, they are added to the list for fixing like this one:
https://mcneel.myjetbrains.com/youtrack/issue/RH-62337

Instead of ranting, why not report a repeatable example like the one above?

3

I have been. For years. Via the crash reporter. Up until recently I assumed (falsely) that all the time I spend filling in details when crashes occur they were being looked at. However the last one (export selected) resulted in my finally going to the forum to report it, because (again) I figured the whole “Rhino crashed, what were you doing when it occurred” part of the crash reporter was being looked at, yet somebody at McNeel informed me on the forum that that wasn’t the case for Mac error reports as they aren’t automatically aggregated or something.

I had no idea that that was the case, and until I posted on the forum they were going unseen.

In this case? I’ve reported this one multiple times via the crash reporter.

But again, you’re missing the point. It’s the name field remaining lighted that’s behind all these bugs. Just deselect the friggin text when you hit enter, and not only will all the these bugs go away, I won’t have projects with dozens of items named “line”, “copy”, “move” etc.

The whole point of being able to name things is to make your work self documenting, and that’s utterly wasted because of the insistence on leaving the text selected.

PLEASE change this. It’s beyond annoying. Way beyond annoying. Spending a few minutes very carefully selecting several objects amidst a sea of hundreds of other objects for the purpose of renaming them, then doing something else to them while still selected is utterly wasted if I have to click off them to deselect them just because the stupid name property field has them still selected, and then go reselect them tediously a second time to do the next thing I was going to do.

From a workflow standpoint it’s infuriating. It serves zero purpose. If nothing else at least give us a settable preference that we can use to have the text in the name field auto deselect once we hit return so we can do the next thing without butchering the carefully selected objects that were named for a reason so down the road we have an idea of what this particular curve or line or whatever was put there for in the first place. Having hundreds of objects named copy or move does not help one iota when reopening a project I worked on weeks or months ago and need to fine that one curve in a sea of construction curves to change something.

4

One thing I can suggest for you is that you post this stuff directly on YouTrack, you should be able to log in with your Rhino Account log-in.

Simply state the title of the bug and then put in all the steps necessary to re-create it (succinctly, no rants, this is a bugtrack system, not a forum), you can also attach screenshots and/or example files.

The advantage of it is this: the report goes directly to the developers and the system makes sure it is assigned to someone and classified as to priority, etc. IIRC repeatable crash bugs also get worked on as a priority over bugs that may cause various problems, but don’t cause crashes. Once the problem is assigned, there will be a version/service release estimate as to when it will be fixed.

You will also get mails when the bug is in process of being worked on, so you will know when it’s fixed.

1 Like
5

Does not appear to work for me. My Rhino accout userid and password are not accepted by YouTrack.

Is it a good idea to encourage the average visitor to this forum to enter bugs directly into YouTrack? It could quickly lead to the system being overwelmed (more than it currently is). More McNeel staff time would be required to sort through the new items, delete the superfulous and inappropriate, verify that the problems have not alread been reported (multiple) times, and assign to the appropriate developer.

6

image

Hmm, OK, I though it should work with the one above. I think I use my Google account for YouTrack, haven’t logged out in a long time…

Well, in this case, it is not the 'average visitor" - he has posted with this bug several times and seems not to be getting satisfaction - hence the suggestion. The YouTrack system is designed to be open. However, I don’t think the ‘average person’ will be very interested in learning how to do it anyway.

7

It doesn’t work. Won’t take my account username / pw, forum username PW or any other mcKneel bookmark I have.

It still doesn’t answer the question as to why if I’ve logged bugs multiple times (in some cases dozens) via the crash reporter that they appear to have gone utterly undetected.

And furthermore, now that this is the 3rd or 4th fatal bug related to the Name Property renaming mechanic, that it still goes utterly ignored.

As it turns out, it doesn’t even matter if you’ve hit return and the “Name” property text is highlighted, as I’ve gone in and manually clicked in the selected text to cause it to deselect, but the text entry field itself is still “active” i.e. has focus, and that alone is sufficient to cause this and other crashes.

There’s something very wrong there and it needs to be addressed.

And again, I should be able to rename something, hit return and type a command and have it do the command rather than renaming the objects the command name.

I cannot stress enough how many hours that behavior has cost me over the years since V5 Beta, which was when I first started using Rhino. I’m fairly OCD about naming things particularly construction lines because they were put there for a reason, and when dealing with very complicated geometry to where one has to zoom way the hell in to be able to select one line out of maybe 20, having them labeled so you don’t have to zoom way out to see what it is then way back in to do whatever you were attempting to do is in my estimation a key workflow.

Having things get renamed when that was not the intent wrecks that whole process, and months later when I have to revisit a file to tweeze something I need that info. If Rhino was fully parametric this would not be such a big deal, but because it’s not, it IS a HUGE deal, as those named construction objects are often the entire mechanism to be able to do a revision to something long after you even remembered how you did it in the first place.

8

image
image433×270 10.4 KB

@brian - is this supposed to work? I tried punching the 'McNeel Accounts" button on the YouTrack login page as in the image above and I got this:

image
image485×384 8.24 KB

9

Since it’s the weekend, why not post a simple message here with the details and specifics I asked for?
You can use the YouTrack item I linked as an example.
Then if we can repeat it; and I suspect we can, we’ll get it into YT so it can be fixed.

I get it that you’re steamed, but all of that makes it painful to wade through to find the actionable items we need to fix it.

Thanks

10

@John_Brock

In the very first post I already gave you exact instructions as to how to reproduce it. And I started with “don’t ask me for a project file” because this is the 3rd fatal crash I’ve reported on this very forum that you’ve asked for project file when the report itself said you don’t need one, and this one is no different.

FWIW, I’ve done software development, I know what a reproducible bug is, and I know what you need to reproduce them. If it needed a file, I’d have attached one.

The failure here is you getting defensive and not reading.

If this wasn’t a repeating pattern, I wouldn’t be so steamed, but you default to “upload a file, put it in the bug tracker” (that we can’t even log into to do so, thank you very much) and don’t pause for a second to consider that maybe, just maybe everything you need to deal with the issue is in the very post in question.

11

I have followed your directions on my MacBook running Rhino7 to try to duplicate the crash. I can report that the name of the selected items does stay highlighted in Properties after pressing “Enter”, but when I pull down the Edit menu and call “Group” the highlighting comes off the name field in Properties without changing the name to “Group” or anything else, and the lines are grouped. No crash.

Windows version of R7 seems to work a little differently- pressing “Enter” after naming the items leaves the name intact and not highlighted and puts the active cursor at the beginning of the name field, which is only slightly less dangerous. Pulling down the Edit menu and calling “Group” just groups the items without crash.

Please add my vote to change the behavior of this in both Windows and Mac versions of R7. Pressing “Enter” should accept the current result and close the operation. Rhino should be ready to accept the next command whether it is typed or selected from icon or menu.

12

Now that’s interesting. What version OSX are you running?

I’m on 10.13.6 as it’s as far as I can go on my 2010 Tower and still have a working GPU (had to put in an AMD Radeon metal compatible card to do so).

I had been running 10.12.x just to keep CUDA support for a pair of GTX 970’s I used to have installed to make Cycles fly, so had to go to the metal card just to be able to run the new Rhino.

13

@LewnWorx
Please click on the YouTrack item I listed above.
There is a link in it to the Discourse post where it was reported.
It is the same problem.
It was reported by @will4 and is on the developers list.

14

MacOS: Catalina 10.15.7
MacBook Pro 15" 2017
Processor: 2.9 GHz Quad Core Intel Core i7
Memory: 16 GB 2133 MHz LPDDR3
Graphics: AMD Radeon Pro 560 with 4 GB VRAM

15

@abrahamwechter it crashes when hitting CMD+G with the name field highlighted
@LewnWorx for now the best workaround is hitting tab twice instead of enter, bring the focus back to the command line

16

@John_Brock

Fair nuff.

However, we can view them, but only if we have a link, as has been reported elsewhere in this thread, I (and apparently several others) can’t actually log into YouTrack to make reports.

FWIW, @abrahamwechter reports he’s not seeing this on 10.15.7. l’m running 10.14.6. Not sure if that has any bearing or not.

17

@Gijs just tried CMD+G with the name field highlighted and still no crash. Lines were grouped and no change in the name field. Hitting Tab twice just brings the focus to the layer field (next down), but no highlight on this… Still not ready to accept a typed command.

I’ve screwed up so many times typing a command without checking if I’m in the right box first that I think I am subconsciously programmed now to look at this before typing, which is a hassle for sure. Hope this gets sorted out soon.

18

Not everyone can post to YT.
@Helvetosaur can. He’s earned his way to that admin rights level.

Everyone can read the YT items unless the ticket is tagged as Developer only. This happens if the ticket has potentially sensitive user information in them.

19

crashes here on 10.15.7 in both 6.33 as well as 7.2

strange… here the first tab brings it to the print width, next commandline

20

I get the same results as @abrahamwechter - no crashes whether I use CMD-G or select Group from the menu (tried both ways several times).

Rhino 7 SR3 2021-1-12 (Rhino 7, 7.3.21012.11002, Git hash:master @ 93cfba46488299a62365c4ea00af2e011f3d3950)
License type: Commercial, build 2021-01-12
License details: Cloud Zoo

Apple Intel 64-bit macOS Version 10.15.7 (Build 19H114) (Physical RAM: 32Gb)
Mac Model Identifier: iMac15,1
Language: en-US (MacOS default)

AMD Radeon R9 M295X OpenGL Engine (OpenGL ver:4.1 ATI-3.10.19

Also no crashes with Version 8 WIP (8.0.21005.12306, 2021-01-05)

I do see the crash with Version 6 (6.33.20343.16432, 2020-12-08)

-Kevin