https://bugs.winehq.org/show_bug.cgi?id=25703
--- Comment #11 from Vincent Povirk madewokherd@gmail.com --- Tried with dotnet core winforms (wine-mono master branch) and got a similar exception, with an entirely different path to get there:
[00000009:] EXCEPTION handling: System.NotSupportedException: Specified method is not supported.
"Launcher UI" tid=00000009 this=01DB0120 , thread handle : 00583F68, state : not waiting at VpxClient.SecuredTextBox.get_Text () [0x00017] in <e97f4f3658ae4be5a90197e35ebc7c8a>:0 at System.Windows.Forms.TextBox.WndProc (System.Windows.Forms.Message&) [0x0009e] in <6a676adda4bb4b01a42b7ddcebf1aba2>:0 at System.Windows.Forms.Control/ControlNativeWindow.OnMessage (System.Windows.Forms.Message&) [0x00001] in <6a676adda4bb4b01a42b7ddcebf1aba2>:0 at System.Windows.Forms.Control/ControlNativeWindow.WndProc (System.Windows.Forms.Message&) [0x000b3] in <6a676adda4bb4b01a42b7ddcebf1aba2>:0 at System.Windows.Forms.NativeWindow.Callback (intptr,int,intptr,intptr) [0x00030] in <6a676adda4bb4b01a42b7ddcebf1aba2>:0 at (wrapper native-to-managed) System.Windows.Forms.NativeWindow.Callback (intptr,int,intptr,intptr) <0x00067> at <unknown> <0xffffffff> at (wrapper managed-to-native) System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW (System.Windows.Forms.NativeMethods/MSG&) <0x00012> at System.Windows.Forms.Application/ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop (intptr,int,int) [0x001d7] in <6a676adda4bb4b01a42b7ddcebf1aba2>:0 at System.Windows.Forms.Application/ThreadContext.RunMessageLoopInner (int,System.Windows.Forms.ApplicationContext) [0x00282] in <6a676adda4bb4b01a42b7ddcebf1aba2>:0 at System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x0001a] in <6a676adda4bb4b01a42b7ddcebf1aba2>:0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.Application/ThreadContext.RunMessageLoop (int,System.Windows.Forms.ApplicationContext) [0x00033] in <6a676adda4bb4b01a42b7ddcebf1aba2>:0 at System.Windows.Forms.Application.Run (System.Windows.Forms.Form) [0x0000d] in <6a676adda4bb4b01a42b7ddcebf1aba2>:0 at VpxClient.Program.Main (string[]) [0x000c1] in <e97f4f3658ae4be5a90197e35ebc7c8a>:0 at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) [0x00027] in <e97f4f3658ae4be5a90197e35ebc7c8a>:0
Examining this get_Text method, it seems it throws NotSupportedException if Control.RecreatingHandle is false.
OK, so why does TextBox.WndProc call get_Text? Because of this code: 896 if ((m.Msg == Interop.WindowMessages.WM_PAINT || m.Msg == Interop.WindowMessages.WM_KILLFOCUS) && 897 !this.GetStyle(ControlStyles.UserPaint) && 898 string.IsNullOrEmpty(this.Text) && 899 !this.Focused)
But this is the implementation of winforms used by native .NET, isn't it? So it must work there somehow, right?
Apparently not, it seems this was a recent addition:
commit a31aa1d4232dbc54dd8b763128c3b06104f5e9af Author: Stefan Stefanov stefanov-stefan@users.noreply.github.com Date: Tue Jan 22 20:54:18 2019 +0200
Added PlaceholderText functionality (#238)
If we check whether placeholder text has been set BEFORE checking this.Text, it works. That seems wrong, because somehow WM_PAINT can work without calling get_Text, but it does demonstrate that this is a bug in dotnet core winforms.