Don’t use global state to manage a local problem, practical exam


There was much speculation as to how the "Ignore other applications that use Dynamic Data Exchange" setting got set. Well, one possibility is that somebody used global state to manage a local problem.

"Why on earth does this setting exist?" I don't know, but there appear to be scripts which rely on it.

The setting is exposed to scripts, and perhaps at some point you ran a script which didn't want Excel to be interrupted while it was running. The documentation for the Excel Application Object does say that it contains application-wide (global) settings.

I'm not saying that's why you are encountering the problem, but it's just one possibility I ran across while doing some Web searching to learn more about the setting.

One of those Web searches took me to Susan Bradley (the SBS Diva) who gave one reason why somebody would enable this checkbox: It shuts up a different warning.

Comments (3)
  1. santosh says:

    Today’s article was like reading a wiki page. Just 8 links without any content :P

  2. John says:

    @santosh: I agree.  It was too much work for me so I just gave up.  I hope I didn’t miss anything.

  3. Morten says:

    Looks like something common to all dev teams: myopia. Some coder has gone "I’ll just fix this here dang problem by preventing it altogether" without considering the consequences to other programs, even within the same package. It’s good to see that for all the quality control MS invests in it can still happen. It warms my heart – I’m not alone then. ;-)

Comments are closed.