Re: Application.screenupdating always True?




Application.Screenupdating can have no effect while single stepping - each step releases control to the OS, which will refresh every application window - and it is, in effect, True at every breakpoint. It seems possible that the Watch Window might be reflecting this - if you set a break on change it does break, and then breaks again after the next statement so it seems as though it might be getting a little confused.

--
Enjoy,
Tony

www.WordArticles.com

"Julian" <msforums@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:OvGljSg$JHA.3732@xxxxxxxxxxxxxxxxxxxxxxx
Thanks Gordon -

Thanks for the input.

I share your experience of screen flicker even with screen updating false (and don't bother hiding the application either - that can cause code to crash, or at least it did with some Word 2002 under non Vista windows), and I do generally try to use the range object..

However - this topsy-like code is not a development project per se it's just written as needs dictate to suppoirt the real project which is the structure and formatting of a large (1000pp, 2million word) document [and there are very good reasons for not splitting it up!] A jumpy screen has not been a problem (when it is significant the code execution is taking 1min - 1hr+ so I'm not using Word at the same time) and so there's no incentive/time to rewrite.

I wrote a test routine that set Screenupdating to false and then retested it (IF Application.screenupdating = true then stop) then back to true 100 times - no break occurred; the question is essentially: if someone else has code that sets screenupdating to false and looks at the value in the watch pane while single stepping, do they see the value become false? What's your experience of this particular modus operandi?

Ta,

Julian


"Gordon Bentley-Mix on news.microsoft.com" <gordon(dot)bentleymix(at)gmail(dot)com> wrote in message news:C55896D9-477D-42CB-987E-951DB1AE1FE7@xxxxxxxxxxxxxxxx
Julian,

I'm assuming that you're trying to reduce the amount of "flickering" that
goes on while a document is building from a template. It's been my experience
that Application.Screenupdating doesn't work all that well - and never has.
Consequently, I don't bother with it. Instead I try to use the Range object
as much as possible; most things that can be done with the Selection object
can be done with the Range object, and the Range object doesn't make the
screen jump around in the background. (It's also faster in most cases.) There
*are* some exceptions, but they're few and far between.

If you can't (or don't want or need to) rewrite your code to use the Range
object over the Selection object, then you're probably stuck with a jumpy
screen. The only other thing I can think of trying is setting
Application.Screenupdating to False twice (or even three times) in a row. I
don't know if it will help in this case, but with other things - copying
styles between templates for example - it seems to work. And the fact that
you can get the value to change if you set it through the Immediate pane does
offer some hope in this regard.

BTW, you say that setting Application.Screenupdating to False seems to be
working in spite of what the watch window tells you, but are you sure?
Perhaps you should try commenting out that line and see if there's any
difference in behaviour.
--
Cheers!

Gordon Bentley-Mix
Word MVP

Please post all follow-ups to the newsgroup.

Read the original version of this post in the Office Discussion Groups - no
membership required!


"Julian" wrote:

[Word XP SP3 under Vista HP] I've just spent two and a half days trying to
track down a problem... and now I don't know what is normal anymore

For intensive work of course I set

Application.Screenupdating = False

but (in the IDE) now it seems that if I put a watch on
Application.Screenupdating it is always True even though it has been set to
False by code...

if I break the code and set Application.Screenupdating in the Immediate pane
the watch value *does* change to false.

The screen does not seem to be updating (so it seems to behave as though
Application.Screenupdating is False) but I thought I recalled that the watch
window used to change as I would expect it to do...

Any ideas?

Thanks, Julian

[BTW - things done to fix the original problem, and which have not changed
this Application.Screenupdating behaviour are:

"code clean" the Normal.dot template...
rebuilt Normal.dot from scratch
rebuilt the target word doc (getting rid of corruptions in the form of
orphaned "nulls" in ranges, export & reimport sections via RTF)
ran "detect & repair" on Word
using Graham Mayor's data key cleanup method
(http://word.mvps.org/FAQs/AppErrors/ProblemsStartingWord.htm)... which
might have actually resolved the original problem (word kept crashing when
running certain automated commenting code)]

--
Julian I-Do-Stuff

Some Vista stuff, but mostly just Stuff at http://berossus,blogspot.com



--
Julian I-Do-Stuff

Some Vista stuff, but mostly just Stuff at http://berossus,blogspot.com

.



Relevant Pages

  • Re: Application.screenupdating always True?
    ... Thanks Gordon - ... I wrote a test routine that set Screenupdating to false and then retested it then back to true 100 times - no break occurred; the question is essentially: if someone else has code that sets screenupdating to false and looks at the value in the watch pane while single stepping, do they see the value become false? ... Instead I try to use the Range object ...
    (microsoft.public.word.vba.general)
  • RE: debugger IDE hangs when stepping with properties in watch wind
    ... Thanks - but as I'm typically changing context with each step (from one ... adding and then removing items from the watch ... window before each step isn't really very helpful - basically, ... > watch window, it will cost debugger much time to resolve these variables, ...
    (microsoft.public.vsnet.debugging)
  • Re: Screen flicker w/ Screen-Updating = False?
    ... The window you get from excel when you print something doesn't respect the ... But you have to make sure that your code turns this LockWindowUpdate API off. ... it should -- ScreenUpdating is part of Excel, ...
    (microsoft.public.excel.programming)
  • Re: Float a window over sheet
    ... If you're using Excel 2002, or later version, you can use the Watch ... Choose Tools>Formula Auditing>Show Watch Window ... To go to a watched cell, double-click its name in the watch list. ...
    (microsoft.public.excel.programming)
  • Re: Getting MS-Projects HWnd from add-in
    ... Anyhow don't forget to set ScreenUpdating back to True eventually ... > takes forever so I needed to find the window and lock it ... so my add-in code does this. ... > Mark Durrenberger, PMP ...
    (microsoft.public.project)

Loading