Automatic Viewport-Mesh creation takes application focus because of Command Prompt

I have a lot of object creation and destruction happening in the background (unrelated to user input). Now every time a meshable object gets added to the ActiveDoc, it is meshed instantly, unless a view manipulation is active (e.g. RMB Orbit).

The problem is - if the user has the mouse in a drop-down menu, and at this moment an object is added in the background (from my script), the Rhino Command prompt outputs "Creating Meshes... Press Esc to cancel" and by doing so takes the window focus. This results in the drop-down menu closing instantly.

If there any way to detect that the mouse is on the drop down menu i can delay the creation myself. I wouldn’t want to rely on mouse position in trying to figure out the state (as people have all kinds of view setups / multiple monitors etc.)

Any ideas?

I am using C# - I see there is RhinoApp.MainWindow, but i don’t know if this is the right place to start, and also what to do with the handle from here on…

Through experience and doing things wrong we have discovered what we call the ICC pattern on how to run Rhino commands:

  1. Identify: the user identifies the geometry they want to change
  2. Change: show the user the changes, with e.g. command line parameters or a GUI to set parameters. The changes are shown in a DisplayConduit and no changes are made to the document at this stage. The user can easily bail from the command.
  3. Commit: The user finishes the command and the command can now make changes to the document to reflect the command outcome.

If you keep to this pattern, the changes are only made to the document when the user commits to making the changes. Doing stuff in the background will get you into all kinds of trouble.

hi @menno, I understand, but this is a quite special case, as I have a collaborative plugin in the works, that actually is functional by now (imagine rhino-realtime-multiplayer) and the only thing posing a user experience problem right now is the effect i described above… Maybe you can help me out?

To expand a bit: it is a inherent part of the design that the document gets changed all the time by other users, and i have thread safe queues, networking and everything else working keeping the documents synchronised in realtime across all clients. (except Blocks, but they are a tricky thing). So when a user creates / moves / edits a object, it gets updated across all clients - and if one of those is in the menu, the console takes the focus…

I see, that does make it a special case indeed! Maybe you can wait for the RhinoApp.Idle event before committing queued changes?
Another thought is to create/copy meshes yourself in the background prior to adding the objects to the document? I assume the meshes are not sent over the wire?

RhinoApp.Idle will be quite useful down the road…
I managed creating the meshes as you suggested:

GeometryBase g = (GeometryBase) new Sphere(Point3d.Origin, 10).ToBrep();
Guid obj = RhinoDoc.ActiveDoc.Objects.Add(g);
RhinoObject objref = RhinoDoc.ActiveDoc.Objects.Find(obj);
objref.CreateMeshes(MeshType.Render, MeshingParameters.DocumentCurrentSetting(RhinoDoc.ActiveDoc), true);

i actually tried this before, but with other MeshTypes - did not imagine that it need the MeshType.Render for the viewport.

All works now, thanks alot!

1 Like