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.
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.
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.
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