Just a quick tip to save some time debugging classes. Did you know that if you make changes to a class, the changes don’t take effect until you re-instantiate the class? That’s why you don’t see your changes taking effect, or your breakpoints being hit.

So, just re-run the AutoExec routine in the template you are editing (because that is usually where your class is initialised) and you should be in business.

If not, then possibly your class is not initialised in a separate routine, but is declared as a new instance of the class, like so:

Dim oMyClass As New MyClass

where MyClass is the name of your class. Just do a search through your code for the New keyword followed by the name of your class if you don’t know where it is.

If this is the case, then change the declaration to:

Dim oMyClass As MyClass

Then in your AutoExec (or other routine that is called before the class is required), add the following:

Set oMyClass = New MyClass

Now you can make changes to your class, rerun AutoExec (or the other macro that instantiates the class) and you can continue to debug. Saves restarting Word and having to setup all your breakpoints again.

In Word 2003, if you need to know if a document contains any VBA code/macros in it, you can use the following function.

Function ContainsCode(ByVal Doc As Document) As Boolean
ContainsCode = False
Dim comp As Object
For Each comp In Doc.VBProject.VBComponents
  If comp.CodeModule.CountOfLines > 0 Then
    ContainsCode = True
    Exit Function
  End If
  Next
End Function

To get the function to work correctly, you will need to change a security setting and enable the “Trust access to the VBA project object model” setting.

Once you’ve enabled that setting you can do lots of fun stuff within VBA – but I’ll cover that in some other posts one day.

Then just call the function with the document you want to check, such as:

If ContainsCode(ActiveDocument) then MsgBox “This document contains macros”

Life is much easier in Word 2007 and 2010. You can just use the HasVBProject property of the document. It returns TRUE if there is code in the document, otherwise it’s FALSE.

If ActiveDocument.HasVBProject then MsgBox “This document contains macros”

Too easy! Microsoft was even nice enough to add it to not only the Document object model, but also to the Workbook and Presentation objects, so it is also available in Excel and PowerPoint. Nice one – it’s about time there were some more consistencies between the object models in Office.

I like it when my code becomes redundant for a good reason. Smile

I spend lots of time developing for different clients, and the problem is most clients have their own drive mappings pointing to specific network locations. In a lot of cases, I need to replicate these drive mappings as it’s usually where they store their Workgroup templates for Word, Excel and PowerPoint.

So instead of setting up all these drive mappings that point to network locations, I use the old SUBST command from a command prompt  to create a “fake” drive mapping that points to a local directory.

Generally I setup a single “Clients” directory on my C: drive, and then create a subdirectory for each client in there.

Then, I use the subst command to map the drive:

subst t: “C:\Clients\Client 1”

Now you have a new T: drive mapping that you can use like any other drive mapping.

Once you’re finished with the mapping, you can remove it with the following command:

subst t: /d

If you want more info on using SUBST, just check out the Wikipedia article which contains some good additional information.

So who says men can’t fake it? They can now! Winking smile

Now all we need is a utility to change all of the Word File Locations and to set these drive mappings, then we could easily switch between different Word environments for clients or testing.

Well as it turns out, I’ve already written one (Ah, nothing like a bit of self promotion) If you’re interested in trying it out, let me know – it’s very handy if you’re a Word coder, developer or tester, and best of all it’s free. I’ll get around to putting it on the site one day!

In the meantime, here’s a screenshot of the latest build of WordConfig…

 

Do you have lots of custom toolbars in Word 2003 and can’t work out where they are coming from? I’ve had this problem so many times, especially when preparing lots of templates to move to 2010.

Well, turns out it’s really simple – just run the following command in the immediate window in the VBA Editor (obviously change toolbarname with the name of the toolbar your after):

? Commandbars(“Toolbarname”).Context

and then you’ll get the full path to file that contains the toolbar. And yes, include the ‘?’ at the start – it means “print” so it will return the value onscreen.

© Copyright - DocAssist 2019