Solved: Help with Word 2003 macro to find text columns in Word

[janaboo13]

I use a CMS to publish data using a Word template. My CMS allows me to create an object specifying the page size, margins, etc. BUT, I can't specify the space between columns, which defaults to .5" in Word when published. My document has 1, 2, and 3 column layouts and I want to change only the 2 & 3 column layouts to incorporate a different "spacing" (gutter) between the columns (i.e. .25" instead of the default .5"). I've recorded a macro that changes the whole document and I can' figure out how to ignore the 1 column layouts. :banghead:

Ultimately, I'd like to select all the sections with 2 or 3 columns and change the spacing in all of them to .25".

Can anyone help me, please?
Thanks in advance, Jan

[Frosty]

How about something like this... (you don't necessarily need to use the oDoc variable, but it may help if this gets more complicated later)


Public Sub DocumentColumnAdjusting()
Dim oDoc As Document
Dim oSec As Section

Set oDoc = ActiveDocument

For Each oSec In oDoc.Sections
With oSec.PageSetup.TextColumns
If .Count > 1 Then
.Spacing = InchesToPoints(0.25)
End If
End With
Next
End Sub

[janaboo13]

Hey Frosty!
I knew this had to be simpler than I was making it...just couldn't figure it out! This has saved me SOOOOOO much time.
Many thanks! Jan

[Frosty]

Sure thing. If you're going to call this from the middle of a recorded macro (not sure how experienced you are), you can do something like the following:

Sub MyRecordedMacro
'do stuff
'do other stuff

'now do my column adjuster
DocumentColumnAdjusting ActiveDocument

'do other stuff
'do other stuff
End Sub
Public Sub DocumentColumnAdjusting(oDoc As Document)
Dim oSec As Section

For Each oSec In oDoc.Sections
With oSec.PageSetup.TextColumns
If .Count > 1 Then
.Spacing = InchesToPoints(0.25)
End If
End With
Next
End Sub


Just a quick example of how to separate out your code.

Hope that helps!
- Jason

[fumei]

"Just a quick example of how to separate out your code."

I am SO glad that you push this concept. Keep it up. It is something I stress repeatedly when teaching. After all the courses I have taught I am still surprised that so many people resist this idea, and want to make these loooooong thousand line procedures. I have demonstrated how much easier it is to debug (and maintain) well "chunked" code, but some people still write excessively long code.

In fact, in one lab I insert a deliberate error into a really long procedure and get them to try and find it. Guess what?

The students that take the time to work out how to chunk it into separate procedures and THEN debug it ALWAYS find the error faster than those who try and find the error just working with the long procedure.

And THAT says it all.

[Frosty]

Chunking is sort of a tough sell for a young CS student, I think. They have no problems with memory, and they rarely have to go back to the exact same code 6 months or a year later and try to figure out a) what the heck it was supposed to do and b) why it isn't doing it anymore, when it worked perfectly for all this time.

I was a word processor long before I was a programmer, but even there the same theory applies: if you format a document properly (styles, paragraph formatting), it always takes longer to set up than it does to treat Word like an electronic typewriter (hitting enter twice for paragraph spacing, all direct formatting, etc).

However, if you later come back to want to change something about the document (condense spacing a bit), it takes you just as long to "reformat" a poorly formatted document, and 2 seconds to reformat a
"properly" formatted document.

Coding is exactly the same way. It takes slightly longer to set up routines properly (and comment clearly)... but proper set up saves so much time in the long run (not just in the initial development, which is nice, but it's really about the 2nd or 3rd time you come back to that same code). And, of course, the real truth is that you come back to the code you set up well MUCH less often than the code you just had to get out the door.

For me, proper coding is never about spitting out something which works as quickly as possible. It's about coming back to it in 6 months and not remember anything about what the code is doing.

However, for a student... they generally need to get the assignment done, absorb what they could, and move on to the next assignment. I would think they rarely have to go back to the same exact code. They also probably have better memory than the typical 30,40,50,60-something programmer. Of course, I have a BFA, so what do I know about computer science studies? :)

[fumei]

"Of course, I have a BFA, so what do I know about computer science studies? "

LOL

In reality I have found that BFA people have some advantage in that they have some training in how to be flexible, in how to think.

I worked with SENIOR programmers setting up an OOP course. The instructor tore his hair out as the programmers told him that they were paid to code, not to plan or organize. In one exercise the students (the senior programmers) were asked how many objects there were in a given piece of code.

ALL of them got it wrong. The only one that got it correct was me, the non-programmer (I was auditing the course because I had organized it).

The answer was...one. There was one object.

One (again senior) programmer stated there were 56 objects. He considered properties as being objects.

BTW; I am an artist.

I agree with your comment vis-a-vis students. Time constraints are critical and "proper" best-practices can easily slide away. And your reasoning I think is correct. Assignments are rarely repeated. Still, I think it is a flaw in their instructors/teachers. I teach best-practices for the simple reason is that they ARE best-practices, and they ARE best in the long run.

Mind you, it is true that we are a long way from the common 100,000+ lines of code from the COBOL days. Objects and class modules change the game significantly. Still, even in our piddling VBA world, good format (indents), good comments (please), and good chunking do the one thing that is the bane of ALL coding.

Debugging. Making the darn thing work the way we want it to.

"proper set up saves so much time in the long run (not just in the initial development, which is nice, but it's really about the 2nd or 3rd time you come back to that same code)."

Exactly. It is also about using procedure tools like Functions. I have seen it many many times - even in the same project - that people write the same set of instructions repeatedly. I have seen it many times in the same procedure.