[Bug 25703] VMWare infrastructure client 4.0 fails with Wine-Mono

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=25703

--- Comment #11 from Vincent Povirk <madewokherd at 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 at 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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.