Eto + GetPoint/GetObject vs. viewport activation

Rhino Developer
1

When I use RunScript to run a command from an eto button, and the command uses a GetPoint or GetObject, I have to click on the viewport to “activate” it, before I can begin to select points or objects. However, this does not occur, for example, when picking points for Rhino’s own Focal Blur > select Focal Distance button:

When you see the cursor switch from the “hand” cursor to crosshairs, that is the point where I have clicked on the viewport. This can be reproduced with even the most trivial command:

protected override Result RunCommand(RhinoDoc doc, RunMode mode)
{
    new GetPoint().Get();
    return Result.Cancel;
}

The issue does not occur when running the command directly from the command-line, only when using RunScript from the eto event handler. I am testing this on win10, 7.8.21196.5001, 2021-07-15.

I have not yet found anything in the docs (or the forum) that speaks to this, and have tried random things like pointlessly calling RunScript from within an InvokeOnUiThread, or calling RhinoApp.SetFocusToMainWindow(doc) from within the event handler or the command itself, just to see if there might be any difference, but have not detected any. I have also tried running the command with dash and/or bang prefix, with echo set to true & false, and any other combination of things I can think of, with no apparent change.

As visible in the video, it just looks like things start out well, with the expected crosshair cursor being shown, and then focus is grabbed by the panel, main window, or other UI, as soon as the cursor is moved at all, at which point the cursor switches to the hand cursor, and mouse movement over a viewport does not register in the viewport until after clicking somewhere on it.

So I will appreciate any hints or direction on this.

2

Hey @jdhill,

This is pretty much all the button does:

private void OnButtonClick(object sender, EventArgs e)
{
  Rhino.RhinoApp.RunScript("_SetViewFocusDistance", true);
}

The command doesn’t appear to be doing anything special to set focus.

Not sure this helps.

– Dale

3

Thanks Dale, great to know that – I’ll keep looking.

4

Seems this has something to do with my use of Drawable as base for this button.

5

Hey @jdhill,

Is your drawable looking for a mouse down or up?

– Dale

6

It currently overrides OnMouseEnter/Move/Leave/Up, in order to track if the mouse is over it, and raise a Click event in OnMouseUp. I do call the base in those overrides.

7

Try commenting out your mouse enter and leave handlers and see if the issue goes away.

I can repeat what you are seeing, btw.

8

Just curious, what are you drawing?

9

It depends on context, you can see one thing I am drawing in the screencapture. I tried getting rid of the enter/leave overrides as you suggested, but still see the same behavior. I also tried putting a runscript directly in the OnMouseUp and that also behaves the same. But overriding OnMouseDoubleClick allows it to work as expected, and since there is no override for click, I guess that is what you are using to test?

10

I’m curious if just using a Button with an image works any better.

m_button = new Button
{
  Width = 20,
  Height = 20,
  Image = my_image,
  ToolTip = "Tooltip",
};
m_button.Click += OnButtonClick;

There is also Rhino.UI.Controls.ImageButton which might be fancier.

– Dale

11

I have checked, and Button does work. And I will have to re-work things and use that if I can’t find a workaround with drawable.

12

Rhino.UI.Controls.ImageButton is a drawable, btw.

Let me try something else…

13

Checking that, ImageButton shows the same behavior as my drawable.

14

I figured that. I’m sure the mouse leaving event is setting focus back to the the button and property form. Using a standard Button is the easy fix.

– Dale

15

Yes, seems that will be the way, thanks for your time & effort.

16

Following up, I seem to have found a workaround: raising my click event from OnMouseDown avoids this behavior when launching commands, but has other focus issues, so I put a bool on the class and raise it from OnMouseDown in these specific cases, and from OnMouseUp in other contexts, as I have been doing til now.

I do not want to use Button, as this button is used everywhere in my auto-generated UI, so switching gives me unwanted border/background/padding to try to get rid of, requires generating bitmaps that should be painted on demand, and would need testing to make sure nothing breaks with the change on either OS.

That said, any chance we could see an IMouseInputSource.MouseClick at some point, @curtisw? I can understand why an OnPaint would be unlikely for Button/Label/etc, so Drawable seems the way to go for custom buttons, but it seems strange to have a double-click event (which as noted earlier in the thread, does not show these issues), with no simple click event.

18

Hey @jdhill, just following up on this. I believe it should been fixed in 7.13 SRC with RH-64912, which is due to be released December 14. Please let me know if you still run into issues.