[python-win32] Trouble with SetWindowLong().

Tim Roberts timr at probo.com
Mon Jan 17 20:00:13 CET 2011


Ben Timby wrote:
> I don't think I am going to end up using a WndProc as that brings a
> lot of overhead, namely the need to call PumpWaitingMessages() or
> similar. The solution I am looking at right now is to simply create a
> hidden window and then call PeekMessage() passing it's hwnd. This
> polling method is simpler and works better with the structure of the
> daemon. I can simply check for messages inside each iteration of my
> main loop and exit when WM_CLOSE is received.
>
> However, this discussion does raise a couple questions.
>
> 1. Do I in fact need a window to receive a WM_CLOSE message? If not,
> how do I post a message to a process, rather than a window?

Messages in Windows are actually targeted to threads.  When you send a
message to a window, it gets sent to the message queue for the thread
that created the window.  It is possible for a thread to have a message
queue even without a window, but the queue is not created until the
thread checks for messages, so you would still need a message pump.

However, there are LOTS of ways to communicate between processes besides
window messages.  In your case, for example, you could easily create a
named event, and signal an event when you want the thread to die.  That
can be done without creating any windows at all.

> 2. Why is there two flavors of SetWindowLong() (win32gui and win32api)?

History.  Win32api attempts to map a wide variety of API calls as simply
as possible -- no typing, little parameter validation.  Win32gui is a
more sophisticated wrapper around the UI-specific parts of the API,
which attempts to provide a mapping between the API parameters and
Python types.

> 3. If I DO need a window to receive messages, what is the best way to
> find said window? Currently I am using FindWindow, but I am not very
> happy searching for the window by it's title,

I'm voting for a named event.

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.



More information about the python-win32 mailing list