GH ScriptComponent & Search dialog & Goto Line = Crash! R5 (and later?)

bug
unhandled

#1

Every now and then my Rhino(5) & Grasshopper hangs. This happens when

  1. I have a (C#) ScriptComponent editor Search dialog open, and
  2. activate the Goto dialog.

These silly dialogs does not always get (edit-field) focus when opened. and so one can start typing not really knowing where the cursor focus is. And so the two dialogs can get messed up (Goto is modal) and Rhino/GrassHopper can become inaccessible with no possibility to close any of the two dialogs, and thus Rhino and GH is no longer accessible.

It seems that the two dialogs (in §1 & §2) “intertwine” and so the modal Goto dialog then can “lock” the UI altogether.

Workaround:

  1. Open the TaskManager,
  2. Click Show windows side by side
  3. Hover over the Rhino Icon in the windows Taskbar
  4. The Goto dialog (which was “locked” by the Search dialog) is now clickable
  5. Press OK or Escape button on the Goto dialog, and now the Search dialog (and Rhino & GH becomes accessible again).

I have not tested if R6 has same hassle, but most people would not try all the combinations to find out the workaround above - and I didn’t try it either, before today - and so the only thing left to do was to kill the Rhino process (and most probably lose unsaved work, and in this case, unsaved program code).

Well, this time I eventually tried very hard and found out how to “unlock” myself out of this situation, but please try to reproduce in R6 and later, and equally important :

- Set focus to the edit field in the dialogs when first opened, AND whenever (re-) activated!

(often the search dialog is keept open, and thus it can be “reactivated” with a new search term by pressing CTRL-F, and it is in this situation I most often end up with “locked intertwined” dialogs)

// Rolf


C# ScriptEditor is still a Pain... Everywhere
(Tom) #2

I would start the dialog in a separate thread, and after you are done you invoke a solution expire in the grasshopper thread.
Like any other Windows Form you can explicitly force the window to be on topmost…There is a property for it. You can of course add a form handle to any other handle, but this is hard to say without seeing the context

See this example for doing things outside of the actual gh thread:

AccessOtherComponents.gh (3.5 KB)


#3

Ah, I should have stated that this happens when I’m doing regular code editing using the ScriptComponent on the GH canvas (so not via script-access to the component).

// Rolf