can't disable Poll Console Windows

[Will Dean]

At 22:03 31/01/2000 -0600, you wrote:

>In his reply Wez questioned why this setting would ever need to be
>turned off.  Well, with it turned on, you see no updates to a variety
>of different windows.  I don't know alot about the different types,
>but pop-up msg windows, control panels (i.e. Services), progress
>meters, etc. don't update automatically unless this setting is turned
>off and/or poll full screen is turned on.  Quite annoying to say the
>least.
>
>Wez, based on what I've experienced, I wonder what the behavior is
>*supposed* to be and why you're assertion about this setting is so
>different than my experience (and that of others' apparantly).

I'm not Wez, but I do know roughly how it's _supposed_ to work.  Basically, 
a global message hook (that's what's in VNCHooks.dll) tries to generate 
hints to VNC about the parts of the screen that have been updated.  In 
theory, perfectly 'pure and well behaved' applications exclusively draw to 
the screen as part of handling a WM_PAINT message.   In fact, this isn't a 
hard and fast rule, and it's widely flouted (particularly for things which 
are drawn as a result of a timer or mouse movement (like drag & drop, for 
example).  For this reason, VNCHooks looks at lots of messages and 
generates lots of hints to WinVNC about what might have changed.

Messages passing to console windows cannot be hooked, so this technique 
doesn't work at all.  For this reason, it is always necessary to poll 
console windows to find out what's changed about them.

The problem is that many windows fall somewhere between the two extremes - 
this is why there are fall-backs like the 'click on a window to refresh 
it'.  It's very undesirable to fall right back to polling all windows - it 
can be very expensive for the server computer to keep blitting-up chunks of 
the screen and examining them for changes.

Although the 'progress bars don't update' complaint is common, I'm unable 
to reproduce it here, with clients and servers running in both directions 
between NT4 and Win2K.

Could someone seeing this problem reliably confirm the following:

That you're running 3.3.3r2
What OS the client's running?
What OS the server (WinVNC) is running on?
If possible, is it a standard operating system application that I could see 
the problem on?

Cheers,

Will












>In any case, I'm anxiously awaiting a fix for this one.




---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------