Lately I’ve had a problem where the Isolate command simply hides stuff. So I have to click on Isolate and then HideSwap to get the effect I’m going for.
I also have had an issue where clicking on Window > Toolbars does type the Toolbar command into the command line but instead of opening the Rhino Options window set to the toolbars tab, it then immediately types Toolbars (plural) in the command line and then says it’s an unknown command.
Restarting Rhino fixes these issues.
I’m wondering if anyone else has experienced these issues (a potential bug)? I’m also wondering if intense python scripts could somehow trigger such issues even if they never call these commands? What about a script that does call the toolbar command?
So far I haven’t noticed a pattern, these issues just randomly start happening.
I just had it happen in Rhino9 WIP. I went to isolate and it hid instead. I immediately clicked on Window > Toolbars and sure enough the _Toolbar command ran and then it immediately tried to run _Toolbars (with an ‘s’) and got an unknown command.
The last of my scripts that I ran was a mult-gem prong tool I made. But I don’t know if that triggered it.
It is my Reorder Gems script, which is a script I use whenever I have mirrored some gems or mixed two groups of gems together. This helps my other tools play nicely with that set of gems. Whenever I run the reorder script, the _Isolate and _Toolbars are immediately affected. This happens in Rhino 6 - 9.
I will see if I can isolate the problem part of the script as soon as I get a chance.
Hi, Wim. It seems to be caused by calling Rhino.UI.EtoExtensions.PushPickButton() and having that call a function that calls Close() on a dialog. Below is a minmal python script that triggers the bug and a video showing it in action. Once the push-pick-close bug is triggered, the _Isolate and _Toolbar commands do not work correctly until Rhino is restarted. And this happens in Rhino 6 - 9…the only difference being that in Rhino 6 & 7, you access _Toolbar via Tools > Toolbar Layout instead of Window > Toolbars.
I can work around this in my kit. So, this bug doesn’t have to be fixed for me. But I can’t tell how important it could be from the point of view of the developers.
The way to avoid this bug is to be sure to call the dialog’s Close() method only after the PickPushButton() method is completely done. Basically, AFTER the target method called by PickPushButton() has finished. Avoiding the bug can easily be done in the event handler for the button by calling self.Close() after calling PickPushButton().
# this avoids the push-pick-close bug
def HandleButtonClick(self, sender, e):
Rhino.UI.EtoExtensions.PushPickButton(self, self.SomeTargetMethod)
self.Close()
The script below adds an “avoid” button that handles form closing after calling the pickpushbutton in a way that avoids the bug. push_pick_close_bug2.py (2.3 KB)
Well, a bug in the script. You were closing your form in the middle of the PushPickButton handler, which put Rhino in an odd state. I see you’ve learned from your ways.