Recorded macro Without a Sub <name>()

[BoatwrenchV8]

Hello all. I had recorded a macro for my use in the current project I am on. When I turned on macro recording, I assigned the macro a short cut key combination like I usually do. Ok fine. Then when I went to use the macro I just recorded, it threw an error and when I looked at the code, it was missing the Sub <> () line at the top of the procedure. I have had this problem a few times before and historically, if I try to fix the code, word will crash on me. I had thought this problem was related to having a lot of macros in my NewMacros folder (more than 60 or so) more macros in it, (post 5, http://www.vbaexpress.com/forum/showthread.php?t=41786), but it doesn't since I only have 5 macros in this folder now. Any suggestions?

The code is below and a picture of the code window with the arrow showing the line the error is attached.

Sub Macro3()
'
' Macro3 Macro
'
'
Selection.MoveDown Unit:=wdLine, Count:=2, Extend:=wdExtend
Options.DefaultHighlightColorIndex = wdYellow
Selection.Range.HighlightColorIndex = wdYellow
Selection.MoveDown Unit:=wdLine, Count:=1
Options.DefaultHighlightColorIndex
Selection.MoveRight Unit:=wdCharacter, Count:=2, Extend:=wdExtend
Application.Run MacroName:="Normal.HighlighterAppVer1.EditCopy"
End Sub
'
' Macro4 Macro
'
'
Selection.EndKey Unit:=wdStory
Selection.TypeParagraph
Selection.Paste
Selection.MoveUp Unit:=wdLine, Count:=1
Selection.Rows.ConvertToText Separator:=wdSeparateByCommas, NestedTables:= _
True
Selection.WholeStory
Application.Run MacroName:="Normal.HighlighterAppVer1.EditCopy"
Selection.MoveDown Unit:=wdLine, Count:=1
Selection.Find.ClearFormatting
Selection.Find.Replacement.ClearFormatting
With Selection.Find
.Text = "14.3.10.7.1.1"
.Replacement.Text = ""
.Forward = True
.Wrap = wdFindContinue
.Format = False
.MatchCase = False
.MatchWholeWord = False
.MatchWildcards = False
.MatchSoundsLike = False
.MatchAllWordForms = False
End With
End Sub

[BoatwrenchV8]

And yes it did just crash after I tried to modify the macro in the editor. Just the simple act of clicking in the editor caused Word 2010 to stop responding.

[Frosty]

Sounds like a bug. Nothing to really do. There are very few things you should be able to do as a fairly typical end-user which crashes Word. I could make a guess as to why it would happen (you hitting the delete key, or the enter key at somepoint during your process), but you've posted enough here to be able to get the following advice:

1. Use recorded macros as a temporary repository for your "real" macros. And to help you learn how to adjust and clean up those "real" macros. Often times you get a lot of garbage included in a recorded macro. Take that stuff out of the "real" macro (for example, your "macro3" above is doing stuff to the selection, but it's also setting application.Options (defaults) every time it is run. That's probably unnecessary for the purposes of that actual macro)

2. Don't assign shortcuts to recorded macros... assign them to "real" macros, with "real" names (not "Macro14") in a module named something other than "NewMacros"


Following those two practices (unless you're really really interested in documenting a microsoft bug) will probably remove your experience of this particular bug.

[BoatwrenchV8]

Thanks for your reply Frosty. I know that the recorded macroscontain a lot of unneeded code but for many of the documents I work on, theyare the fastest way to create a solution, run it 40 times with a keyboard shortcut and then move on to the next issue. The plan with this down-and-dirty macrowas to record it and then modify it a bit after I ran it the first time. Withthe bug though, it never even made it to its first time. Nothing out of theordinary was occurring in Word that I had noticed. When Word crashes with at350+ page document, it is not fun to say the least. I will be pondering adifferent approach when I create disposable and to-be-kept macros. Have youever seen an error like this?

[BoatwrenchV8]

Just tried recording another simple test macro and it did it again. Did not assign it a shortcut but kept the default name.

[BoatwrenchV8]

I deleted the test macro above and recorded another test macro. The default name in the box was "Macro5" instead of "Macro4". Thought that was odd since I deleted Macro4. As it turns out, Macro4 still exists and if you click on "Macro4" in the drop down box, it will put the cursor where the black arrow is pointing (the Sub BlargThis () line). Selecting the "BlargThis" in the drop down box will put the cursor where the orange arrow is. Bizzarre. Agree with Frosty it is a bug since it seems something is happening behind the scenes here that just isn't right. How do you submit a bug report to Microsoft?

[Frosty]

Submitting a bug to microsoft involves making sure it is a microsoft bug. You would need to be able to document the exact steps to recreate this bug in a "clean" winword process (i.e., Start > Run > Winword /a ... and then document exact steps to cause Word to crash).

I'm betting you can't do this with this "bug" -- since it could be
1. Corrupted normal.dotm (which wouldn't be loaded in a clean winword process)
2. One of the other addins you also load, and may not even know about-- also not opened by winword /a
3. A document you happen to be working on (which doesn't count-- you can't send a document to microsoft and say "something's wrong with this-- can you guys figure it out?").

I have more thoughts, which I'm composing, on how to approach your workflow better (and maybe avoid this kind of bug).

[Frosty]

I've never encountered that error, but I also haven't worked the way you're working for over 10 years (since Word 97). Each new version of Word has its own bugs and quirks... what's happening shouldn't be happening, but the reason it's happening could be a number of things, only one of which is an actual Microsoft Word bug.

Thinking about the best way to approach the "disposable macros" concept. There are only so many shortcut key combos... I'm assuming you use something like the numeric keypad for your "quick and dirty reformat x document" type functions, which start their life as a recorded macro.

I would probably approach it a fashion like this:
1. Create a module called "QuickAndDirty"
2. Create a number of empty procedures with names for the shortcut keys I would assign to them... things like

Public Sub QD_ALT_NUM1
'run this macro when ALT + Numeric Keypad 1 is pressed
End Sub
And then I would assign the appropriate keybindings in my template. For you, probably just do the 10 or so typical keybindings you use.

At that point, you'd have a template with macros that run from keybindings... and that would be relatively static. You can write code which would "refresh" your keybindings, here's a sample of that kind of code and how to use with the above macro...

Public Sub BindMyKeys
FirmKeyBind "QD_ALT_NUM1", wdKeyAlt + wdKeyNumeric1
End Sub
'----------------------------------------------------------------------------------------------
'simpler for adding a new key binding... be aware of CustomizationContext
'----------------------------------------------------------------------------------------------
Public Sub FirmKeyBind(Command As String, KeyCode As WdKey, _
Optional Category As WdKeyCategory = wdKeyCategoryCommand)
On Error GoTo l_err
'save in the same template running this code
CustomizationContext = ThisDocument.AttachedTemplate

'now do the keybinding
KeyBindings.Add Category, Command, KeyCode

l_exit:
Exit Sub
l_err:
MsgBox "Unable to set keybinding for macro: " & Command & vbCr _
& "Keys: " & KeyString(KeyCode) & vbCr & "Error description: " & Err.Description & vbCr & "Continuing...", vbInformation, "Binding Keys"

Resume l_exit
End Sub
From there, I would record macros, and then simply copy and paste the contents of those macros into whatever QD function I wanted to have the particular shortcut key run.

I think that would set you on to the path of beginning to recognize patterns in your QD functions, and you'd start to, rather than replacing wholesale, recognize that what you think are disposable functions specific to a document, are actually similar methodologies with fewer variances between documents than you think. And so you'd begin to modify the macro that started its life as a recording with a couple of tweaks... and suddenly what you think is efficient will become much more so.

In addition, if you use the above process, you will more easily be able to build your normal.dotm from scratch, rather than have to worry about bad keybindings (it happens) causing issues.

Hope this helps.

[fumei]

Wow, I have never heard of such a thing. While perhaps tempting, I would not bother trying to report this to Microsoft. Even recognized MVPs rarely get any satisfaction from reporting "bugs".

Take Frosty's advice and try to adjust your methodology.

Oh and never accept MacroX as a name. In fact, generally speaking, do not accept ANY default names from Microsoft.

[Frosty]

As someone who once spent the better part of a year documenting various Microsoft Word bugs (and I had a direct line to someone at Microsoft), I concur with Fumei.

Once you get past a certain amount of red-tape (and anyone can open a case with Microsoft-- I think it costs $250, which they refund if it is determined to actually be a Microsoft bug), if you're dealing with a "real" bug, the best you can hope for is either a) a hotfix (and that's only going to happen if you have a premium support contract, it's a bug which was already identified and being worked on by someone with a premium support contract, or you represent a big company ... I fell into 2 of those 3 categories when I was doing this work) or b) seeing your bug on the list of Known Issues with no resolution. :)

Mostly what you can get out of the labor-intensive process of identifying the "real" bug is a work-around to avoid it and still accomplish what you want to accomplish.

That's why I'm recommending skipping all that stuff, since the most likely scenario is to adjust your workflow anyway.

[Frosty]

Oh, and not to drink the microsoft koolaid... but make sure you are in fact running the latest service pack/update of whatever version of Office you're running. You might even find that your bug has already been fixed.

[BoatwrenchV8]

I planned on staying far, far away from thie kool-aid as I have heard stories about it. lol.

Latest updates are installed for Word and Win 7 64bit.

I have some planning to do in order to approach this differently and appreciate your input. Thinking and will post again soon.:think:

[fumei]

Just curious....are you using Office 64bit?

[macropod]

First thing I'd be doing is restarting Windows, then running a repair on Word, just to make minimize the possibility that the problem is particular to this PC. Then, before concluding it's a bug, confirm that it can be reproduced on both this PC and another one.

[BoatwrenchV8]

@Fumei - Office 32bit, Win 7 64bit, 8GB RAM, Dell Vostro 3700

@Macropod - Agree restarting windows is the best option to properly clear out my environment as just restarting Word didn't always work. How do you run a repair on Word 2010?

[macropod]

Office 2010 is repaired via a repair install under 'Programs & Features' in the Windows Control Panel.

[BoatwrenchV8]

Thanks Macropod. I ran the repair on Office and so far so good. The real test will be on Monday. Fingers are crossed.