WindowSelectionChange event failing to fire

[Fletcher James]

We are seeing a problem at our customer sites, where the
WindowSelectionChange event fails to fire, which is interfering with the
proper functioning of one of our applications. In order to trace this, we
have written a macro which simply declares an object as WithEvents
Word.Application, and pops up a message box, when the event fires (see
below). Testing at various sites, we have found that the macro fails at a
small percentatge of client sites. We know that at least one site is
running Word 2003, but we're not sure about the others.

The problem always goes away (i.e. the event is always raised) if we keep
any custom .DOT's from loading. In one case, we isolated a single .DOT from
another vendor, and that vendor was able to figure out that the problem was
due to code in the following form:

On Error Resume Next
Application.Run "macroname"
On Error GoTo 0

where "macroname" was invalid, and where the code was excuted through an
AutoOpen. That vendor removed the line of code, and the site is now up &
running. However, we have found two other sites where the event fails to
occur, and where we could isolate a single .DOT which controlled it. In
these cases there were two different .DOTs triggering the problem, both of
which include AutoOpen processing. However, as far as we can tell (one of
those being from another product of ours) neither .DOT contains code in the
above format.

If you have any idea why this might happen, I would very much appreciate it
if you could cc: any reply directly to me, as well as to the group.

The test macro is as follows:

---- .bas module ------

Attribute VB_Name = "Test"
Option Explicit

Private moTest As CTest

Sub TestWSC()

If moTest Is Nothing Then
MsgBox "Starting Test WSC"
Set moTest = New CTest
Else
MsgBox "Stopping Test WSC"
Set moTest = Nothing
End If

End Sub

---- .cls module --------

VERSION 1.0 CLASS
BEGIN
MultiUse = -1 'True
END
Attribute VB_Name = "CTest"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = False
Attribute VB_Exposed = False
Option Explicit

Private WithEvents moWordApp As Word.Application
Attribute moWordApp.VB_VarHelpID = -1

Private Sub Class_Initialize()
Set moWordApp = Application
End Sub

Private Sub moWordApp_WindowSelectionChange(ByVal Sel As Selection)
MsgBox "In WindowSelectionChange: Select text: " & vbCr & Sel.Text
End Sub

Public Property Get WordApp() As Word.Application
Set WordApp = moWordApp
End Property



--
Fletcher James
President
Levit & James, Inc.

(703)771-1549
MailTo:[email protected]
http://www.levitjames.com

 

[Hugh Gillespie]

We have also found this to be a problem. If you do a Application.Run
on a macro that does not exist it breaks the WindoSelectionChange
event. Once this error has happened you must restart Word to get the
event to fire again. In our situation we are doing the Application.Run
and trapping the error as there is no easy way to iterate the loaded
macors currently in scope to test if the macro is available before
doing the call! Please report this to Microsoft as a Bug! We are
currenlty testing to see if this is still a bug in Office 12.

Thanks
Hugh Gillespie
Infoware

 

[Fletcher James]

We'll be reporting it at our 1st opportunity. Our unfortunate situation is
that we need to support all versions of Word, so MS fixes don't do us any
good <(g)>. We're therefore most concerned with developing workarounds.

There are a number of tricks you could try for dealing with the
macro-doesn't-exist problem, including using the extensibility model to find
out what they are (yuck! And doesn't work for passworded templates) or
putting in a dummy replacement for any macro which is missing.

We're going to try the latter approach, because the main difficulty we'll
have to deal with is a) Customer cannot change versions of Word; b) Problem
comes from another 3rd-party addin; c) Other add-in vendor is not able to
provide a hot-fix for this problem (e.g. they need to add a configuration
switch so they know whether call will be valid, and they can't easily
release a patch to the version the customer is running); BUT, d) other
vendor IS able to tell us the name of the missing macro.

If we put in a dummy macro, we will possibly have it raise an Error 4633 --
Macro Not Found. That way, if the errant application is trapping the error,
it will have an error result. We will be experimenting to see whether that
works, or whether any Application.Run with an error results in the
supression of the event. We'll keep you posted.

BTW: Do you know which versions of Word have this problem?

Also: Feel free to call me on the telephone if you'd like to chat about
other possible approaches.

--
Fletcher James
President
Levit & James, Inc.

(703)771-1549
MailTo:[email protected]
http://www.levitjames.com