Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
DiscussionsAccessExcelInfoPathOutlookPowerPointPublisherWord
DirectoryUser Groups
Related Topics
Outlook ExpressInternet ExplorerWindowsMS Server ProductsMore Topics ...

MS Office Forum / Word / Programming / March 2006

Tip: Looking for answers? Try searching our database.

WindowSelectionChange event failing to fire

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Fletcher James - 28 Mar 2006 19:38 GMT
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

Signature

Fletcher James
President
Levit & James, Inc.

(703)771-1549
MailTo:fjames@levitjames.com
http://www.levitjames.com

Hugh Gillespie - 29 Mar 2006 15:51 GMT
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 - 29 Mar 2006 19:31 GMT
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.

Signature

Fletcher James
President
Levit & James, Inc.

(703)771-1549
MailTo:fjames@levitjames.com
http://www.levitjames.com

> 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
[quoted text clipped - 8 lines]
> Hugh Gillespie
> Infoware
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.