Using default Eto Control over Rhino variant

Rhino Developer
, ,
1

Hey all, I was wondering if there is a preferred solution for using a default Eto Control, such as the ColorPicker, instead of using the variant Rhino provides/overrides? I am using the same UI components in several projects so it’s easier to not have to maintain custom logic based on the environment and Rhino’s versions has slightly different behavior/properties. I quickly tried creating my own Control that inherits from ColorPicker but I get the same variant so I am guessing the base class is being overridden somehow. Appreciate any feedback or suggestions, thanks!

image
vs.
image

2

Hi,

That’s a weird one and I’m sure there’s a simple explanation for this, however I will give my input anyway and assume that you followed all the right procedures.

AppDomain.CurrentDomain.AssemblyResolve += (sender, args) => {
    if (args.Name.StartsWith("Eto"))
    {
        // Load your embedded Eto assembly
    }
    return null;
};

You can force loading a specific assembly using this resolution technique, ensuring that you’re using your own version of Eto.

Or you could crate a custom class that inherits your specific eto assembly

public class MyColorPicker : Control
{
    private Eto.Forms.ColorPicker _etoColorPicker = new Eto.Forms.ColorPicker();
    
    public Color Value
    {
        get { return _etoColorPicker.Value; }
        set { _etoColorPicker.Value = value; }
    }
    
    // Add other properties and methods as needed
}

That being said, the issue you described is kinda weird, It sounds like both assemblies are loaded and It choses to stick to the first one loaded (Rhino).

Anyhow these solution should solve your issue 100%, but I’d investigate and ensure that you did not make some silly mistake along the way such as loading the wrong assembly.

Hope this helps,
Farouk

3

Hey Farouk, thanks for the detailed response.

While running in Rhino I use the Eto build that is bundled with Rhino as I assumed trying to load another version would cause other issues or bad behavior.

I also already tried the second approach and it still loads the Rhino variant of the ColorPicker.

My guess is Rhino either checks the base class of some Eto Controls and somehow swaps them with custom types when instantiated or they have a custom branch build of Eto that modifies the base classes at the origin. One other possibility is styling overrides but their ColorPicker is different enough that it looks like a completely different Control object.

4

Send me a script snippet so I can replicate this situation and help you solve it easily.
@alfarok

5

Anywhere I use new Eto.Forms.ColorPicker(), I get the Rhino variant. If you are able to show the default Eto ColorPicker without replacing the Eto.dll’s provided by Rhino, that solves my issue.

6

@dale @curtisw Do you guys have suggestions for this scenario? You guys have both provided tons of useful samples and knowledge on other Rhino/Eto related posts that have helped me along the way. Hoping you can shed some light on how exactly Rhino handles overriding Eto Controls so I can come up with a solution for this. Thanks!

7

I can see the ControlObject property on any instantiated ColorPicker in Rhino is set to RhinoWindows.Controls.ColorButton instead of Eto.Wpf.Forms.Controls.EtoColorPicker, which is what it is set to in other applications running the same code.

8

Hey @alfarok,

To use the standard Eto controls you’ll need to create a separate platform instance to create the control. Something like:

      // create a new copy of the current platform type (Wpf or macOS)
      var platform = Platform.Get(Platform.Instance.GetType().AssemblyQualifiedName);

      // Create the color picker based on the standard platform controls
      ColorPicker picker;
      using (platform.Context)
        picker = new ColorPicker();

      // show it in a dialog:
      var dlg = new Dialog();
      var layout = new DynamicLayout();
      layout.AddRow("Color Picker", picker, null);
      layout.AddSpace();
      dlg.Content = layout;
      dlg.ShowModal();

Hope this helps!

1 Like
9

Thanks @curtisw! I ended up using the ColorDialog control instead which so far has more consistent behavior between platforms. The issue was that I was trying to using the ColorPicker in a TreeGridViewer and the properties and events between a the WPF control and Rhino control were very different so it was very difficult to get 1:1 behavior without a bunch of conditional logic depending on the platform. Moving to a dialog made things simpler but this is great knowledge for future reference. Thanks again!

1 Like
10

I was able to make another pass on this today and can now confirm the solution posted by @curtisw works for using default Eto controls in Rhino:

image

1 Like