More tweaks to v1.71

I’ve been busy tweaking some of the more basic functions within the Toolbox GUI this morning.

A quick bit of code to check that a template does actually exist within the file opened has prevented an error message appearing when you try to change it … within a template file.

Also on the basic functionality is an extra label running along the bottom of the Toolbox GUI which shows if the current file is Read/Write (with a red background) or Read-Only (green background).

Removing more code

I decided to remove the Kill Old Styles function in its current form as it was a lot of hard-coded styles that would (probably) only appear in documents found within my workplace.

I’ll rethink the Custom Styles screen to include a few more functions that allow more tinkering with styles in bulk. For now there’s a large gap where the old function used to be. I have filled in some of the gap with a temporary function to toggle the ‘Automatically Update’ status of all styles in your document.  This will only be a temporary feature as there’s a lot more functionality I’d like to add re: styles but time is against me

Reworking old routines

One of the first options I put into my Document Properties Report function was to extract all the styles that we (as in our Documentation Team) were interested in looking at.  This enabled us to look at a document’s styles and work out what (if anything) we needed to fix.

So I’ve spent the morning replacing a set of really old (and extra long) commands I’d constructed into a much neater subroutine.

Each Heading, TOC or other styles now has a much easier (on the eye) format of: Font Name (Font Size) and then the letters B, I or U following it depending on if Bold, Italic or Underline attributes are present.  Previously it had either a 0 or a -1 for True or False as that’s how you inspect the values under Word VBA.

Not much point sending this version (1.66d) out for testing as it’s just a “ah.. that’s better” release for me only 🙂

Ooops!

I’ll call this one a ‘lesson learned’.  Whilst moving some of the code about that was linked to the CSV file reporting, I used a lot of ‘Debug.Print’ commands so that I could see that the output file was showing up as it should.

I spotted an error which would cause every CSV file to be ‘corrupt’ as each single line was being split across two lines.

After some pondering – and adding more Debug.Print commands here and there – I twigged the daft mistake that I had made.

I’d added a carriage return not to a Debug.Print command .. but the command above it! This caused the folder and file name to appear on one line, then all of that document’s properties on the next line.

Ah ..

A fixed version, and a sheepish apology, was sent out rather hurriedly to the TAs who I’d sent the preview of v1.66 to earlier on today.

Oops!