Every once in a while (several times a month realistically) I’ll open a rhino file to find my toolbars are all missing.
I know it’s a common issue, but is there a known root cause, or any way to prevent it from happening? I work with a lot of large files, and it’s really irritating to wait 3 minutes for a file to open, only to have no toolbars, and have to do it all over again.
There are several possible causes but none can fully explain it.
The most common is when Rhino closes, the state of the toolbars is updated and saved.
If that process is interrupted by Windows hibernating, then we rely on Windows reopening everything in the right order. That seems to be the main cause.
This can be avoided if you never let or force Windows to hibernate with Rhino running or quickly after closing Rhino. File saving and updating is scheduled as a background task.
In practical terms:
As a result, I haven’t lost my toolbars for several years on any computer I use.
Thanks John,
I’ll start following these practices.
Since you mention it, I haven’t lost the toolbars on my home computer EVER, and that’s an always-on desktop that only gets rebooted periodically for updates.
Work is a laptop, with typical windows hibernation and wake issues.
If you walk away from your laptop with Rhino running, then disable all of the hibernation tools in Windows.
If you never walk away with Rhino running, (like for lunch), then you can leave the power saving tools on.
I’ve had this happen a few times, so I back mine up from time to time.
I think the answer might be: Rhino loads without toolbars because their coding needs a little looking at.
If you think we haven’t tried, you’re sadly mistaken.
Because we can’t fix how Windows saves files, all we can do is make automatic backups, and commands like ToolbarReset to replace them when Windows damages them.
For me it happens when I am running several big apps along with Rhino.
Photoshop Illustrator and Rhino for example simultaneously. Yes my machine doesn’t sweat.
What happens to the toolbars is that all the check boxes in Tools>Options>Toolbars get unchecked.
Putting the checks back gets my custom screen (dual) set up back…
NEW THOUGHT- Duplicate Edge needs an undo ( like many other commands have) if you inadvertantly select a wrong edge you have to start the command over. Probably held over from Rhino2!
Interesting.
The list of open toolbars is stored in the System Registry in HKCU\software\McNeel\Rhinoceros\5…
I seems very odd that another application would effect that.
I wonder if something is blocking writing to the Registry…
Another thing to avoid is closing Rhino and starting Rhino again too quickly. If you close Rhino then need to restart wait a minute or so before restarting.
If you run Rhino and the toolbars are missing and you still have another instance of Rhino running with all the toolbars, close the instance with no toolbars wait a few seconds then close the instance with the toolbars wait a minute, the next time you run Rhino it should have all the toolbars back.
Mark
That makes perfect sense.
Closing Rhino asks Windows to delete, rename, and save files which Windows schedules as a Background task.
If you start another session while the previous session’s toolbars files are being background saved, the toolbar RUI file may not exist when the new Rhino session tries to open it. Then the new session will have no toolbars.
I am sorry, John Brock. Were you sure there was a sword in my hand before you drew yours?
Theoretically, could not Rhino keep a couple of toolbar backups kicking around?
That is true, because none of the above explain mine… I regularly get the toolbars messed up - they’re not “missing”, they’re simply closed, all the docking is messed up, and a bunch of things are reset to default such as the command line going to the top (normally I have it on the bottom), the command help tab appearing, etc… The phenomenon is always accompanied by the famous cryptic command line message “root element missing”.
However, this is not happening on a laptop, but rather a workstation. I can’t “close the lid”, and it never goes into hibernation. I do shut down the computer at night, but long after I have closed Rhino. So my feeling is that either Rhino is taking a LOT longer to write to the registry than just a minute in some cases (which is actually an eternity for the tiny bit of info it needs to write) or, it never manages at all.
The only solution is to stop writing the toolbar docking info to the registry. Most of the missing and jumbled toolbar problems stem from there. It needs to write a normal ini-type data file somewhere protected, and only once that file is correctly written, does it replace the existing one (much like Rhino .3dm files are now saved). That way, if writing the file fails when Rhino is closing, at least the previous file is available the next time Rhino starts. You could even back up the previous file so that a secondary backup is available in case the first one got corrupted somehow.
–Mitch
As an experiment, if go to Computer Management / Event Viewer / Windows Logs / System, and choose a column to sort them by, you can see just how long Windows takes to work with the registry. Xp did not suffer like this; Windows 7 and 10 struggles.
I lose my toolbars almost on a daily bases. I have a desktop so there is never the issue of closing my lid. Losing my toolbar problem never happened till I loaded Windows 10. Sure wished I had kept using Windows 7 till the empty toolbar bug gets fixed. I had the most perfect custom toolbar setup with complex python scrips that I wrote before losing my entire setup. But I am not about to try to attempt to customize my toolbars again till this problem is resolved. My feelings are that Windows 10 and Rhino hate each other 
If you have heavily customized your toolbars, always back them up - just like you would with any other file that you have worked on for awhile and you consider to be important. You should also always save them under a new name - as something like ToolbarReset will overwrite the Default.rui toolbar file - by design, as you normally only do this when your toolbar file gets corrupted.
Actually the Mac Rhino style of doing things - not letting you modify the default workspace at all, forcing you to create a new one if you want to do any mods - is actually a pretty good idea. I find the implementation on the Mac side a bit clumsy, I think all that is maybe needed in Windows Rhino is a dialog that comes up when you start modifying your toolbars which forces you to save it under a new name.
I have a whole set of custom toolbars under Windows 8 and 10, and I’ve never lost them. I do keep several backups.
–Mitch
Can you define “lose” in this case? Does the toolbar file become corrupted/unreadable? --Mitch
Hey Helvetosaur,
Thanks for the great advice about backing up my default.rui. But at the time I first lost my toolbars I did not even know there was a default.rui. I am very talented at quickly destroying stuff on my computer. After I lost my toolbars i researched and found that there was a default.rui. So I deleted the default.rui on my computer and reinstalled it thereby losing all my custom toolbars. Now I know I need to back up the default.rui, but at this moment there is no need because I don’t have any personal toolbars to backup. When I say “lose” I mean that all my toolbars become blank with nothing in them. Well there is something in them I just cannot see the little icons inside the toolbars. I can still click the blank toolbar icons and they will work but I don’t know what I am clicking. When I use the command “ToolBarReset” and close and reopen Rhino I get my toolbar icons back just like they were when I installed Rhino the first time.
Thanks very much for your helpful input and would strong advise everyone who has custom toolbars to backup their Default.rui!!!
The blank toolbar problem is specific to Windows 10.
They actually aren’t blank.
Some unknown problem occurs (rarely, under unknown circumstances), when Windows is saving the RUI file, and the pixels in the bitmaps stored in the RUI file are replaced with white (RGB - 255, 255, 255) pixels.
The work-around is using ToolbarReset if your RUI file hasn’t been modified, or as Mitch pointed out, manually renaming a backup copy of your customized and saved RUI file.
The backup is stored in the same folder as default.rui. There just is no tool in Rhino to automatically replace a copy of an RUI file with a user specified name.
This used to happen very rarely to my toolbars, until I started using Rhino6 and especially Rhino7.
I’ve noticed that it will occur after an update, pretty much every time.
And since Rhino7 updates like 27 times a year, it pretty much happens 27 times a year.
Rhino5 used to pretty much never update and so pretty much never happened.
Why does Rhino7 update so much, it’s kinda crazy imo.
Rhino should only update monthly (12). If your Update Frequency is set to Service Release Candidate, then is will be almost every week and closer to 50 times a year.