Rhino 7 has a bug related to its integrated Notes. After switching to the window of another program and then reverting back to Rhino 7, the text inside the Notes will be automatically selected and scroll bar moved to the very bottom.
1 Like
Hi Bobi -
We have this on the list as RH-65292 Notes: Selection when Rhino for Windows gets focus
-wim
1 Like
Hi Wim, I noticed that this particular bug reports is marked as âRelease target: 8.xâ. Does that mean that the âMcNeelâ team intend to leave the bug in Rhino 7, despite being reported since 2021? Hopefully, it will not follow the same fate like many other known bugs that were reported for years and never got fixes.
In the past the auto-selection of the text inside Notes was not a huge deal to me, but recently I lost all my saved notes there due to an accidental press of another key. The other annoying thing (also shown in my video) is that upon change of opened windows back to Rhino 7 the focus goes all the way down to the last text instead of keeping the state of the Notes unchanged.
Cheers! 
Hi Bobi -
I was actually surprised to see that this bug report was so recent. This behavior has been in Rhino as long as notes have been in Rhino.
I see that some management of expectations is in orderâŚ
Yes, that wonât be fixed in Rhino 7.
There are, per now, 46 remaining items on the Rhino 7 list (only 5 of these are public). 35 of those are crash reports. Weâll see how many of those will end up being moved to Rhino 8. We are not touching the Rhino 7 code unless we absolutely have to.
-wim
Now that I deal with modifying longer notes that exceed the height of the Notes window, the bug with auto-selection of the whole text is even more disturbing since it always moves the scroll bar to the bottom. While itâs not a drastic bug that crashes the program, itâs definitely something that leads to bad user experience, and even could lead to accidental deletion of notes.
Iâm quite surprised to learn that this particular bug in Notes was well known since the very beginning many years ago, yet the management and programmers never bothered to fix it. If the fix is finally there and proven to work in Rhino 8 WIP, why donât use the solution to that old bug in Rhino 7, too? The worse part is that these things happen quite often, including serious bugs left unresolved for Rhino 7, like this one for example:
That is kinda the point of bringing out new versions⌠at some point you have to stop fixing the old ones.
Everyoneâs idea do a âseriousâ bug will be different. Right now the only crash bugs are considered serious enough to put any work into fixing the soon-to-be previous version instead of working on new stuff for the next one.
Being a basic Rhino user , Iâm not the person who will tell how the business model must be done, I just express my thoughts about the simple fact that proven solutions to important bugs in the current commercial version are already there since months and even years, however, they are not released for it. The main issue is that there are numerous known bugs that were reported years ago, even 10 or more years ago, yet they will be left unresolved in Rhino 7, despite being fixed in 2022 or 2023, but instead held exclusive only for the non-released future Rhino 8. Yes, I wrote it right. While itâs perfectly fine for new features to be held exclusive to the upcoming Rhino 8, it does not do any favour that bugs in Rhino 7 will forever remain there. The solution is there, just needs some willingness from the developer to add the existing code to Rhino 7.
Sorry if Iâm too vocal about these bugs, but I LOVE Rhino and always try to make it more public and well known from people who either hear about it for the first time or are not aware of its true capabilities. I often report bugs or make suggestions for new functionality as a way to give my contribution to the community and help with improving Rhino in the most critical aspects.
The most underdeveloped surfacing tools are âMatch surfaceâ and âBlend surfaceâ, yet they are still nearly the same since Rhino 4, with extremely minor improvements (âBlend surfaceâ in Rhino 5 actually often behaves better than what it does in Rhino 7). If Iâm not mistaken, âMatch surfaceâ was even downgraded in Rhino 4 by removing the âRefine matchâ option.
Also, âBlend surfaceâ uses âSweep 2 railsâ in its core, which is why it produces overly-dense output surface, rather than taking advantage of the âEdgeSrfâ tool known for its clean surfaces with the bare minimum of control points.
âBlend surfaceâ still lacks a simple option to follow the same direction as the side edges of the input surfaces, while its major competitors have it. Rhino users were asking for this particular feature since Rhino 3 if I remember correctly. Now we wait for Rhino 8, yet itâs still not there.
Many users wanted to see various features seen in VSR for Rhino 5 being implemented natively in Rhino 6, but they still only dream about those and most likely wonât see them until Rhino 9 or Rhino 10.
The Zebra analysis still does not have a âStaticâ option (another huge advantage of VSR for Rhino 5), instead, itâs dependent on the camera view. Not to mention the lack of light lines.
Bringing new versions is due to the following reasons:
-
Making more money. After all, itâs a business like any other, so itâs understandable that the hard working developers are striving to expand their sales with a supposedly better new product. This is not related to fixing known bugs.
-
Lack of compatibility, changes in the latest Windows OS, willingness to take advantage of newly released hardware features and all the other things not possible with the current version of the program. This is not related to fixing known bugs.
-
New core engine, adding groundbraking new tools and features, new UI. This is not related to fixing known bugs.
As has been said many times here, itâs not as simple as just âadding a couple of lines of codeâ. If it was that simple, it would have been done without anyone asking. Anything added to software as complex and interwoven as Rhino risks breaking other stuff down the line - and thus needs extensive testing. Time which should not be spent on what is now considered as the more or less âfinalâ stable version of this release. In the current WIP, they are not too worried about breaking things, thatâs what itâs there for so that this stuff can be discovered and fixed.
Those are your issues. Everyoneâs are different. Iâm not a car designer, the first two donât matter much at all to me. And Iâm not really distressed about the third one either.
Well, another software which I use occasionally (which shall remain nameless) just fixed a serious âbugâ which I complained about probably 20 years ago. I nearly fell off my chair when I saw that, I had given up a long time ago.
1 Like
Of course that the code of the fixed bugs must be added carefully in the proper place, not at the other end of the general code. This is what programmers do at a daily basis. They are hired professionals for that very reason.
Testing is done easily: simply try the fixed version of Rhino 7 in a few occasions and if it works, then itâs done! Rhino users are also testers, I would say. If something else breaks, Rhino users will find the issue really soon and then send reports to the developers, myself included. I will be happy to test those fixed tools for free on my Rhino 7 Superfixed version and report any bugs I can find. This is why âService release candidateâ exist in the first place! Stable versions are named âService releaseâ (no âcandidateâ in the name). âService release candidateâ is like âtry it at your own riskâ version destined to those who want to try the updates and fixes at the risk of facing a somewhat unstable Rhino. I regularly use SRC and Iâm perfectly fine with those.
Also, many remember that there were multiple occasions where Service releases of both Rhino 6 and Rhino 7 introduced certain issues and the developers simply advised the Rhino users to switch to a previous, stable version, until they resolve the bug in the next version.
On the other hand, if the developers donât even try to fix the known bugs in Rhino 7 that already have their fixed code done for Rhino 8 WIP, then Rhino 7 will remain buggy forever. I would rather have a Rhino 7 LLFD (Last Love From the Developers) version with many bugs fixed, than having an official stable Rhino 7 SR full of known bugs leaved there in extinction. The ability to revert to an earlier SR is always there in case that Rhino 7 LLFD or some reason does not meet the criteria of the general user.
Both, âMatch surfaceâ and âBlend surfaceâ are among the most important modeling tools in Rhino. No need to be a car designer to use them, since they are a crucial part of the majority of product designs. Maybe you are a rare exception if they both donât matter to you, but most Rhino users rely on those two tools quite a lot.
3 Likes
Just for your reference here is the list of publicly visible unresolved issues: https://mcneel.myjetbrains.com/youtrack/issues?q=%23Unresolved%20 . And that is only the public unresolved issues. Multiply that by 16 to get a better idea of the number of outstanding issues.
Rule # 1 with software: Itâs never finished.
Rule # 2 with software: Itâs never finished.
Rule # 3 with software: ItâsâŚ
etc.
I understand that, but I talk about already found solutions to bugs in Rhino 7 that the developers refuse to include in the next Rhino 7 Service release, and rather prefer to keep them exclusive to the future Rhino 8.
The code between v7 and v8 may have considerably changed that the fix for v8 is not viable for v7.
Many other fixed bugs shared across Rhino 7 and Rhino 8 WIP proved that itâs perfectly viable to implement the fix in both versions.
Sure, but many doesnât mean all.
With other words, this particular bug with Notes will be forever left unresolved in Rhino 7 by the developers?
Youâll have to ask that question from @JohnM .
OK, Iâm sending him a PM now to ask the same question. Thanks!
Thereâs a very good chance this will not be fixed in Rhino 7. Major portions of UI have been rewritten based on a different user interface framework. This may include the notes panel.
As far as I know, Notes is not part of the main UI and toolbars, but instead a stand-alone pop-up window.
The inability for the Notes to stay visible while clicking on another program (for example, opening a small window with Notepad or Wordpad) is yet another thing to consider fixing. It makes it difficult to compare existing text in other documents with those inside Rhinoâs Notes.