Change X from 18 to 16 makes the circle bigger. WHY?
Also, please bring back edit box function for worksession object, even just showing the sizes in gray boxes.
Edit box is good in Rhino 6 the way it was, please bring it back to Rhino7!!! Gosh, it’s unusable now, thanks!!
Confirmed.
I believe McNeel were working on Boxedit to fix the performance issue. Looks like they broke it again in the process: @brian, in SR9 (7.9.21196.7001, 2021-07-15) if you change the value in a Size box the program populates the Scale boxes with spurious values so that when you apply the change the scale is applied as well as the desired size one (or maybe instead of, I haven’t done the math). This didn’t happen in the last SR8 release.
I’m sorry to say it, but this really does feel like Groundhog Day.
Yeah! Same problem, I’m trying to input specific dimensions and it all goes screwey! What’s going on???!!!
I had to do a major rewrite of the BoxEdit panel in order to accommodate complaints with regards to performance as well as how the “Size” section works. Thanks for the bug report on the Size section behavior; I’ll try to get to this asap.
Our development process is to ship release candidates for a service release every week for a month to make sure it is stable with regards to bug fixes. We now know that a new bug exists with respect to the BoxEdit rewrite and we will make sure it is fixed before we ship our official service release.
Sorry Steve, but this isn’t some obscure bug to be revealed by a customer’s unusual Use Case. We’re glad to take SRC’s to help drive those out. This is about as basic, uncomplicated and visible a bug as you can get: reduce the size value, does the object get smaller? No, it gets bigger! Then that’s a fail. That’s basic unit testing, that’s (I’m 90% certain) actually a regression.
A Service Release Candidate should, by definition, be something McNeel determine to be potentially ready for release. To have that confidence your software must have passed unit testing and regression testing.
If you feel I’m wrong and we are here to do those things for you, then speak out and tell us. I for one will, regretfully, stop taking SRCs. I don’t have time for that level of unpaid commitment.
Sorry, we missed it. This was a special case in that a massive amount of code had to be rewritten in order to overcome performance issues with BoxEdit as well as complaints regarding the behavior of the Size inputs. This was big enough of a change that we had several internal people test the changes as well as users like @Jarek. It may have been that everyone was focused solely on the performance issues and not the sizing issues. The good news is that this was caught in an initial release candidate instead of the official service release. We can get this bug fixed and send out another release candidate.
Hi Steve
Can we have the ability in Rhino7 BoxEdit to display the size of a worksession object? This is something still working in Rhino6 which is super handy as I can tell a worksession object’s size without have to measure it.
This is something disabled in Rhion7.
Fixed yet?
This was discovered 4 days ago. I am working on the bug today and will hopefully have it fixed for our weekly release candidate tomorrow.
This is on my list of features to work on. My current focus is on the size bug right now.
Well that’s a relief. Thanks for fixing this
Something else is wrong… the edtibox fields are grayed out after picking an object, it only lets me change the value after i switch the panel, like: go to the layer panel then go back to the BoxEdit panel, then the fields are unlocked and changeable.
Worksession objects are still not working with EditBox, that’s, the sizes are not display, unlike Rhino6
I’m having trouble repeating this bug. Are there any specific steps I need to take?
Hi @stevebaer,
I have just seen this same issue:
One or more of the following may be pertinent:
Randomly selecting different objects did not populate the Boxedit values, I had to run the BoxEdit command (I had the object pre-selected) to do so.
HTH
Jeremy
