We are experiencing a consistent number of failures on a significant number of machines that resemble a topic from 2 years ago but with slightly different circumstances. The issue is the Text, TextEdit, TextObject, and Insert commands failing to load their UIs. The difference in circumstances is that we are now using Windows 10 and the issue only seems to present itself after loading a large, complex GH definition, but it is yet to be confirmed that this is the source of the issue. For reference, please see this thread:
Here’s the info from two different machines having the same issue:
Windows 10.0.17763
Rhino 6.18.19266.14201, Rhino 6.26.20147.6511
.NET 4.8 (Release 0x80eb1/528049)
Launch Rhino
Do some stuff
Text commands work fine
Launch GH and load an incredibly complex definition with Custom UI, layer listening, cloud analytics, REST calls, flow control, data schemas, etc
Text, TextObject, TextEdit, and Insert commands sometimes stop working (no UI comes up at all), but not always
Using python to create text works
Using “_-” prefix on text commands in the command line works
Wondering if @JohnM has any thoughts on this topic as it would seem he was the solver of the original issue.
The “Text command not working in V6” thread references RH-45443 Which contains commits from @Alain and @tim. The interesting thing about this report is it mentions the Insert command UI not working which is different than the other thread that mentions annotation dialogs that share common UI components. The insert dialog does not use any of the annotation dialog components but is a Eto dialog. At first glance this looks like something in the GH component is causing the Eto UI to fail.
It would be helpful to have a GH component that causes this to happen so we could try to reproduce this on our end.
@curtisw Do you have any thoughts as to what would cause the Eto based dialogs to start failing?
Sorry, I’m not sure what could possibly be causing the UI to not even show up (and not cause a crash). Perhaps the custom UI is doing something that corrupts WPF (which Eto uses on Windows) in some way… It’d be interesting to know what the custom UI is written in (WPF, WinForms, other?).
Custom UI is written in WPF, it is our own deeply developed branch of HumanUI, which has modified all of the main classes, including MainWindow. I do remember this problem surfacing back in the day when I was working with the OS build of HUI though – although I have never personally seen the Insert command fail (but one of my users has reported it). Any idea on how this could be debugged, particularly when it doesn’t happen reliably?