[Bug 18531] New: FontValidator (.NET based app) needs OleInPlaceObject_InPlaceDeactivate properly implemented
wine-bugs at winehq.org
wine-bugs at winehq.org
Tue May 19 15:13:28 CDT 2009
http://bugs.winehq.org/show_bug.cgi?id=18531
Summary: FontValidator (.NET based app) needs
OleInPlaceObject_InPlaceDeactivate properly
implemented
Product: Wine
Version: 1.1.21
Platform: Other
URL: http://www.microsoft.com/typography/FontValidator.mspx
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: shdocvw
AssignedTo: wine-bugs at winehq.org
ReportedBy: focht at gmx.net
Hello,
now that some urlmon MIME support patches are on the way which are essential
for this app ("text/xml" MIME is later needed to show XML content in embedded
browser window) I file an "intermediate" bug that needs to be fixed before we
can verify the new functionality with real apps ;-)
The story is basically about in-place activation and deactivation of embedded
browser control.
The current shdocvw OleInPlaceObject_InPlaceDeactivate stub is mostly harmless
for many embedded browser control hosting apps because they don't rely on the
fact that in-place deactivation doesn't really take place (control will be
destroyed shortly anyway).
This app use case is a bit special hence the current in-place deactivation stub
becomes the culprit.
Steps to reproduce:
1. clean WINEPREFIX
2. winetricks -q dotnet20
3. start app, "Font files" -> "Add..." -> select whatever true/opentype font
from your system
4. "Table tests" -> "Clear All" -> select only "BASE" (shortens test)
5. "Rasterization" -> deselect "Test rasterization of TrueType outlines"
(shortens test)
6. hit "Start validation"
The .NET 2.0 app creates an embedded browser control:
--- snip ---
...
0029:trace:ole:CoCreateInstance (rclsid={8856f961-340a-11d0-a96b-00c04fd705a2},
pUnkOuter=(nil), dwClsContext=00000001,
riid={00000000-0000-0000-c000-000000000046}, ppv=0x32e2a4)
...
0029:fixme:shell:URL_ParseUrl failed to parse L"Interop.SHDocVw"
...
0029:trace:win:WIN_CreateWindowEx L"Shell Embedding" L"Shell Embedding"
ex=00000100 style=46010000 0,0 0x0 parent=0x500b4 menu=(nil) inst=0x61020000
params=0x136d00
...
0029:trace:win:WIN_CreateWindowEx created window 0x100b6
...
0029:trace:shdocvw:create_shell_embedding_hwnd parent=0x500b4 hwnd=0x100b6
...
0029:trace:shdocvw:OleObject_DoVerb (0x136d00)->(-5 (nil) 0x3c80034 -1 0x500b4
0xadd434)
0029:trace:shdocvw:OleObject_DoVerb OLEIVERB_INPLACEACTIVATE
...
0029:trace:win:DestroyWindow (0x500b4)
...
--- snip ---
and a "parking window" to host the control in inactive/hidden state until the
real hosting window is about to be created and displayed to avoid runtime
penalties of destroying and recreating browser control each time.
This blog gives some insight in the world of "parking windows":
http://blogs.msdn.com/sburke/archive/2007/06/20/flashback-windows-forms-parking-window.aspx
--- snip ---
0029:trace:win:WIN_CreateWindowEx L"WindowsFormsParkingWindow"
L"WindowsForms10.Window.8.app.0.378734a" ex=00010000 style=02010000 0,0 0x0
parent=0xfffffffd menu=(nil) inst=0x400000 params=(nil)
...
0029:trace:win:WIN_CreateWindowEx created window 0x100b8
0029:trace:win:show_window hwnd=0x100b6, cmd=0, wasVisible 1
...
0029:fixme:shdocvw:OleInPlaceObject_InPlaceDeactivate (0x136d00)
0029:trace:shdocvw:WebBrowser_AddRef (0x136d00) ref=11
0029:trace:ole:GetErrorInfo (0, 0x32d9b0, 0x19a9c4)
0029:fixme:shdocvw:WebBrowser_QueryInterface
(0x136d00)->({df0b3d60-548f-101b-8e65-08002b2bd119} 0x32d9a8) interface not
supported
0029:trace:shdocvw:WebBrowser_Release (0x136d00) ref=10
0029:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b84385b
ip=7b84385b tid=0029
...
0029:trace:win:WIN_SetWindowLong 0x100b6 -4 61031784 W
0029:trace:win:alloc_winproc reusing 0xffff0057 for (nil)/0x61031784
0029:trace:win:WIN_DestroyWindow 0x500b4
--- snip ---
The CLR exceptions resulting from E_NOTIMPL of
OleInPlaceObject_InPlaceDeactivate are handled gracefully.
The window which is the real target for the browser control gets created later:
--- snip ---
0029:trace:win:WIN_CreateWindowEx L"C:\\windows\\temp\\tmp47b0.tmp.report.xml"
L"WindowsForms10.Window.8.app.0.378734a" ex=00050040 style=46cf0000
-2147483648,-2147483648 376x358 parent=0x10088 menu=(nil) inst=0x400000
params=(nil)
...
0029:trace:win:WIN_CreateWindowEx hwnd 0x600b4 cs 0,0 376x358
...
0029:trace:win:show_window hwnd=0x600b4, cmd=5, wasVisible 0
0029:trace:shdocvw:WebBrowser_AddRef (0x136d00) ref=11
0029:trace:shdocvw:OleObject_DoVerb (0x136d00)->(-5 (nil) 0x3c80034 -1 0x600b4
0xaece88)
0029:trace:shdocvw:OleObject_DoVerb OLEIVERB_INPLACEACTIVATE
0029:trace:shdocvw:WebBrowser_Release (0x136d00) ref=10
0029:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b84385b
ip=7b84385b tid=0029
0029:trace:seh:raise_exception info[0]=80131509
0029:trace:seh:raise_exception eax=7b82ca1d ebx=7b8c2918 ecx=00000000
edx=0032d958 esi=0032d958 edi=e0434f4d
0029:trace:seh:raise_exception ebp=0032d920 esp=0032d8bc cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00000246
--- snip ---
The CLR exception leads to following backtrace dialog (and abort):
--- snip ---
************** Exception Text **************
System.InvalidOperationException: Unable to get the window handle for the
'AxWebBrowser' control. Windowless ActiveX controls are not supported.
at System.Windows.Forms.AxHost.EnsureWindowPresent()
at System.Windows.Forms.AxHost.InPlaceActivate()
at System.Windows.Forms.AxHost.TransitionUpTo(Int32 state)
at System.Windows.Forms.AxHost.CreateHandle()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr
wparam, IntPtr lparam)
--- snip ---
The activate_inplace() OLE verb bails out early because Wine thinks the control
is in-place activated (This->inplace) -> real in-place deactivation never took
place.
.NET runtime tries to fetch hosted control's window handle which fails because
no parent switch was done.
Adding simple in-place deactivation (releasing IOleInPlaceSite, resetting
This->inplace) lets this app succeed, having windows properly
switched/re-parented.
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.
More information about the wine-bugs
mailing list