How is Word repainting itself?

[Phil Crosby]

Hi

I'm using Spy++ to look at the WM_PAINT window messages moving across the
word process, to see how the windows in Word are related. If you edit the
content of the document using the keyboard, it seems like the only windows
that receive a WM_PAINT message are the two MsoCommandBar windows (that are
children of the WwB document window) and the status bar. I think the actual
repainting of the document is happening in the WwG window. Why is it
repainting when there is no WM_PAINT message? I'm no expert in win32
painting, but I thought it was a best practice not to paint outside of a
WM_PAINT message.

I'm concerned because I'm interested in monitoring closely what Word is
doing - especially when it's done painting. I'm doing this for a research
prototype, so all hacks are allowed and best practices ignored ;-) I was
thinking of listening for WH_CALLWNDPROCRET using SetWindowHookEx and finding
out when the appropriate window was done responding to a WM_PAINT event.
However, if the Word window doing the redrawing of the document isn't sending
a "done" message when it's done painting, well, that strategy won't work.

Update:
To further investigate what's happening, I implemented a hack to monitor
calls to the BeginPaint and EndPaint methods in USER32.DLL as outlined in
this article:

http://www.fengyuan.com/article/wmprint.html

It seems the only windows that call BeginPaint are the windows I mentioned
in my first post. What other drawing method would Word use to paint on the
device context that corresponds to the window containing the document content?

Someone else ran into this issue while trying to force a hidden window
capture of Word-
http://www.probo.com/timr/blog/pyblosxom.cgi/2005/Nov

He mentions that the Word rendering window probably has its window style set
as CS_OWNDC (which I can't verify in Spy++), but even in that case I thought
you still needed to call BeginPaint to draw. Clearly that's not the case, as
no windows call BeginPaint when the document is modified except the two
MsoCommandBar windows and the status bar


I'm at a loss how to proceed. Are there any general pointers I should look
into? If Word might be calling GetDC or some other giveaway win32 method when
it starts painting that I can listen for, what might that method be?

Thanks!

-Phil Crosby


Note: this is a repost from here:
http://msdn.microsoft.com/newsgroup...6d4f-4b7d-b7f1-c60b33f0165f&lang=en&cr=US&p=1

 

[Karl E. Peterson]

Hi Phil --

I'm using Spy++ to look at the WM_PAINT window messages moving across
the word process, to see how the windows in Word are related. If you
edit the content of the document using the keyboard, it seems like
the only windows that receive a WM_PAINT message are the two
MsoCommandBar windows (that are children of the WwB document window)
and the status bar. I think the actual repainting of the document is
happening in the WwG window. Why is it repainting when there is no
WM_PAINT message? I'm no expert in win32 painting, but I thought it
was a best practice not to paint outside of a WM_PAINT message.

Not at all. Windows frequently need to paint themselves to display, well,
whatever it is they're doing. WM_PAINT is designed for the system to alert
a window that all or a portion of it needs refreshing. But it's not
uncommon at all for a window to (re)paint at the instigation of some user
action, to update its progress in some operation, when its data changes, and
so on and so on.

I'm concerned because I'm interested in monitoring closely what Word is
doing -

Good luck! Word, like most Microsoft apps, is highly eccentric. While
Microsoft may publish "best practices," they rarely if ever "do as they
say."

especially when it's done painting. I'm doing this for a
research prototype, so all hacks are allowed and best practices
ignored ;-)

It seems the only windows that call BeginPaint are the windows I mentioned
in my first post. What other drawing method would Word use to paint
on the device context that corresponds to the window containing the
document content?

Dang near any imaginable. Maybe they're building an image of the window in
memory, then blt'ing it to the screen. Hard (impossible?) to say.
Especially given the source.

I'm at a loss how to proceed. Are there any general pointers I should
look into? If Word might be calling GetDC or some other giveaway
win32 method when it starts painting that I can listen for, what
might that method be?

Good darned luck. I wish I had something constructive to offer. What did
you intend to do, once you came to realize Word had (for the moment) stopped
painting?

 

[Phil Crosby]

Draw on top of it =) I'm researching digital document annotation, and the
prototype is based on drawing ink marks all over Word documents using the
Tablet PC SDK. Currently I'm redrawing ink strokes every 200ms, which gets
the job done but is not terribly elegant and causes some flicker. You can put
an InkOverlay object on top of a window and it will handle redrawing strokes
when the window repaints itself or gets invalidated, but unfortunately the
Word rendering window doesn't report these happenings and even seems to
sporadically redraw itself. I would expect Word to do whatever it has to to
make performance good, but it would be nice if we could have an API to hook
into the drawing surface.

Maybe I can hook into bltbit and see if that's what they're doing. I'll
report my findings.

Thanks Karl

-Phil Crosby