WPF form (created by HumanUI) causes rhino to crash

Serengeti (Rhino WIP)
1

I’m aware that HumanUI is not supported in Rhino. But up untill the latest version of Serengeti it worked just fine. I flag this, not to support HumanUI, but to let you know that there was a change that makes Rhino crash under some weird circumstances.
HumanUI-test.gh (4.5 KB)
You usually don’t love external plugins in test-files, but it was the only way I could recreate it.

2

Hej Timo -

image
image1626×706 115 KB

On my end, v0.8.2 is the latest version of human-ui in the Package Manager. On Food4Rhino, it’s 0.8.1.3 for Rhino 6. In your file, you have a component from a 0.8.8 version. Where did you get the newer version?
-wim

3

I mean - latest version of Rhino WIP

4

Hej -
Let me try this again.
The file you posted contains a component from a plug-in that doesn’t seem to exist.

image
image2014×772 159 KB

For us to be able to try to reproduce this issue, we’d need to be able to install that plug-in.
-wim

5

@wim

Looks like you are trying to install a Windows only (HumanUI - WPF based UI builder) on a MacOS machine.

Cheers

DK

FYI - I have tried the file on Windows in Rhino 9 WIP, and have seen the crash.

6

Hi David -

image

As the tag shows, this thread was started on an Apple product.
There is no additional information about the platform, nor Rhino version number. As such, we use that tag as information for which platform to test.

Developers of plug-ins can make it so that the plug-in does not show in the Package Manager on platforms that are not supported. As far as I can tell, I successfully installed v0.8.2 on my Mac. Then again, I have no intention of using it other than testing that file, so I wouldn’t know if it’s working or not.

Perhaps Timo can provide more information…
-wim

7

Hi wim,

That’s a mistake on my end with the tag. Apologies.
It’s a windows only problem.
I got the behaviour confirmed across three different companies that use HumanUI.
It’s not about HumanUI, it’s about the fact that a change came in on of the latest WIP, that caused it to crash when moving a window (created by HumanUI).

So if it’s isolated to HumanUI I of course don’t expect you to prioritize it, but if Rhino generally can crash from moving windows, I fear there is a bug that may cause more trouble than just in HumanUI.

I know the issue wasn’t there in 9.0.26097.12306,2026-04-07

8

Hej Timo -

Thanks, (9.0.26110.18305, 2026-04-20) is the last version that doesn’t crash.
I’ve put this on the list for a closer look [RH-95143 - not publicly visible]
-wim

9

Hi @Timo_Harboe_Nielsen,

Looks like this is a bug in MahApps.Metro, which is used by Human UI, explained here Windows not movable with .NET 10 · Issue #4554 · MahApps/MahApps.Metro · GitHub.

It is using reflection to a private property which was renamed in .NET 10, so there’s nothing we can do to provide compatibility with that. Ideally, Human UI would be updated to use a new version of MahApps.Metro that doesn’t have this bug.

In the meantime, you should be able to get it working again by switching to the .NET 9 runtime using the SetDotNetRuntime command (and ensuring the .NET 9 windows desktop runtime is installed).

Hope this helps!

10

Hi Curtis. I really appreciate you taking time to research this. Thanks!