question regarding FindWindow

[Marcus Meissner]

Hi,

While debugging Google Earth I see hangs in FindWindow...

Apparently the 
    if (GetWindowTextW( list[i], buffer, len + 1 ) && !strcmpiW( buffer, title )) break;
call hangs on the server... But how is this possible?

+win,+server snippet:

trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE
0009: redraw_window( window=0x10020, flags=00000005, region={} )
0009: redraw_window() = 0
trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE
0009: redraw_window( window=0x10020, flags=00000005, region={} )
0009: redraw_window() = 0
0009: get_window_children( parent=0x10020, atom=0000, tid=0000 )
0009: get_window_children() = 0 { count=3, children={0x10026,0x10024,0x10022} }
fixme:win:WIN_FindWindow before getwindowtext
fixme:win:WIN_FindWindow after getwindowtext
fixme:win:WIN_FindWindow before getwindowtext
0009: send_message( id=0010, type=1, flags=0, win=0x10024, msg=0000000d, wparam=00000023, lparam=55937970, x=0, y=0, time=000010a4, info=00
000000, timeout=0, callback=(nil), data={} )
0009: send_message() = 0
0009: get_msg_queue( )
0009: get_msg_queue() = 0 { handle=0x148 }
0009: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 )
0009: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 }
0009: select( flags=4, cookie=0x55c1f6f8, signal=(nil), timeout=0, handles={0x148,0x80} )
0009: select() = PENDING
*hang*

What debug to enable and what to look at?

Ciao, Marcus

[Rob Shearman]

Marcus Meissner wrote:
> Hi,
>
> While debugging Google Earth I see hangs in FindWindow...
>
> Apparently the 
>    if (GetWindowTextW( list[i], buffer, len + 1 ) && !strcmpiW( buffer, title )) break;
> call hangs on the server... But how is this possible?
>
> +win,+server snippet:
>
> trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE
> 0009: redraw_window( window=0x10020, flags=00000005, region={} )
> 0009: redraw_window() = 0
> trace:win:RedrawWindow 0x10020 whole window flags: RDW_INVALIDATE RDW_ERASE
> 0009: redraw_window( window=0x10020, flags=00000005, region={} )
> 0009: redraw_window() = 0
> 0009: get_window_children( parent=0x10020, atom=0000, tid=0000 )
> 0009: get_window_children() = 0 { count=3, children={0x10026,0x10024,0x10022} }
> fixme:win:WIN_FindWindow before getwindowtext
> fixme:win:WIN_FindWindow after getwindowtext
> fixme:win:WIN_FindWindow before getwindowtext
> 0009: send_message( id=0010, type=1, flags=0, win=0x10024, msg=0000000d, wparam=00000023, lparam=55937970, x=0, y=0, time=000010a4, info=00
> 000000, timeout=0, callback=(nil), data={} )
> 0009: send_message() = 0
> 0009: get_msg_queue( )
> 0009: get_msg_queue() = 0 { handle=0x148 }
> 0009: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 )
> 0009: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 }
> 0009: select( flags=4, cookie=0x55c1f6f8, signal=(nil), timeout=0, handles={0x148,0x80} )
> 0009: select() = PENDING
> *hang*
>
> What debug to enable and what to look at?

Look at why the message loop for 0x10024 doesn't process the message. 
This may be one of the things that Windows handles in the server rather 
than sending messages to each window.

Rob

[Marcus Meissner]

> Look at why the message loop for 0x10024 doesn't process the message. 
> This may be one of the things that Windows handles in the server rather 
> than sending messages to each window.

The window its trying to WM_GETTEXT is created by ole32.CoInitializeEx(0,2)
(called by Google Earth startup code), and hangs only some lines later
in a kernel32.WaitForSingleObject() (also called by a google earth supplied dll).

WFSO does not do windows messageloop handling. :/

So, is CoInitializeEx(NULL,COINIT_APARTMENTTHREADED) is perhaps
doing the wrong thing here.

Ciao, Marcus

On Thu, 15 Dec 2005 09:52:50 +0100, Marcus Meissner  
 wrote:
> > Look at why the message loop for 0x10024 doesn't process the message.
> > This may be one of the things that Windows handles in the server rather
> > than sending messages to each window.
>
> The window its trying to WM_GETTEXT is created by  
> ole32.CoInitializeEx(0,2)
> (called by Google Earth startup code), and hangs only some lines later
> in a kernel32.WaitForSingleObject() (also called by a google earth  
> supplied dll).
>
> WFSO does not do windows messageloop handling. :/
>
> So, is CoInitializeEx(NULL,COINIT_APARTMENTTHREADED) is perhaps
> doing the wrong thing here.
>
> Ciao, Marcus

Dragon naturally speaking also spews large quantities of the WM_GETTEXT  
errors and the huge/negative window dimension errors posted about recently.

It is also a heavy OLE user.

[Robert Shearman]

Marcus Meissner wrote:
> > Look at why the message loop for 0x10024 doesn't process the message. 
> > This may be one of the things that Windows handles in the server rather 
> > than sending messages to each window.
>
> The window its trying to WM_GETTEXT is created by ole32.CoInitializeEx(0,2)
> (called by Google Earth startup code), and hangs only some lines later
> in a kernel32.WaitForSingleObject() (also called by a google earth supplied dll).
>
> WFSO does not do windows messageloop handling. :/
>
> So, is CoInitializeEx(NULL,COINIT_APARTMENTTHREADED) is perhaps
> doing the wrong thing here.

We should definitely create a window for single-threaded apartments. 
Native might delay the creation of the window until it is actually 
needed though.