Generate VBA code to reconstruct a document (Office 2000 SP 1A WinXP)

Topic

New Reply

I would find it really useful if there existed some application that would do the following:
Given any document in Word the application could automatically generate a module of VBA routines that, when triggered, would output the original document ‘on the fly’ including all formatting, text boxes, images, fonts etc. In other words you put the document in one end of this function/application and a set of routines comes out the other and these routines in turn will generate the original
document. It might sound silly but then with a little tweaking of the outputted code you could easily turn static documents into ones that varied their order and content according to data from the (possibly Access) database. This would enable the easy creation of reports and other data bound documents without the limitations of just putting simple merge fields in the document.
Anyone know if such a thing exists/can be done?

Reply | Quote

Replies

I don’t think this is feasible. If you want this to be applicable to arbitrary documents, you’d end up with completely unstructured information and code.

If you search Google for word document assembly, you’ll find many ready-made tools that allow you to create documents from building blocks.

Reply | Quote

Thanks Hans. The sort of things that come up with such a Google search are all to do with assembling documents, usually legal contracts, from boilerplate paragraphs and putting these in a specified order. I can already do this with code I have written, it is not hard at all.
I guess what I was after was the Word equivalent of the FrontPage WYSIWYG interface, and then some.
I could construct my document and use the macro recorder to put the code together but many of the documents I wish to treat in this fashion are fairly complex, already exist
and took quite some time to design and format. It just struck me that, in principle, all the instructions must already be there, albeit in some covert form, and there might be a routine
that “works backwards” deconstructing the document and “recording” the code in reverse from which the document might be re-generated at the click of a command button.
This would mean that I coud tweak the code at various points to insert database information or vary the order or even substitute pictures in place of existing ones, etc, etc.
Do you see exactly what I mean?

Reply | Quote

I understand what you mean, and I don’t think it’s feasible. Others may have a different opinion.

Reply | Quote

Even if you could do this, it could never be “perfect”.

For example the placement of text boxes and graphics would need to be fixed relative to a paragraph, or to the page, or the margin. Most people who construct word documents aren’t that careful about specifying this sort of thing, and although you might be able to reproduce the appearance of the original document, any change in content could lead to a really silly result.

StuartR

Reply | Quote

> Anyone know if such a thing exists/can be done?

The answer to your question is “yes” – someone does know.
A slightly deeper answer would be “yes – in principle”, since the specifications for the bit-by-bit layout and structure of a document are available (and are put to use by some companies who like living dangerously), it can be done, and is done.
After all, a program called “Word” manages to present a document on your monitor/printer, assembled from a serial stream of bits.

I suspect that you need a more practical basis for “yes”, and here it is:

If you are prepared to specify what you mean by “re-assemble a document”, then you can do it yourself.

At the simplest level, if you define a document as “a series of text paragraphs”, then a simple VBA loop emitting each paragraph to a text file will do the job; reassembly consists of reading the text file and loading each record to a new paragraph.

Of course, that would be unformatted text, so your specification should include some descriptors that (1) name the style associated with each paragraph and (2) define each named style at the level you define. That level would include at least font name and size, enhancement, paragraph indent and space, and so on, to whatever detail you feel is necessary.

You’d probably want to include descriptors for local formatting (non-styled) within each paragraph.

And yes, you’d want to define sections and the header-footer descriptors for each.

To this point it is not a lot of work, really. It does not transport a document as we know it, but it does transport a document to a specific standard, which may well be suitable for your purposes.

In effect, you would be making a parallel definition of Microsoft’s specifications for a document. Your device would have the advantage of being switchable; I can envisage a GUI form linked to an INI file, by which you nominate just which features are to be preserved in transporting a document.

This device would serve as a mechanism for standardising documents within an installation.

Other programs, such as those that generate PDF files, almost certainly go through a procedure like this; they have to interpret the serial bit stream of a document file and transform it into their target form.

I perform similar acts when I’m cleansing large batches of documents; the client specifies what text forms are to be identified and reformatted, and we do just that. One client specifies “any text that has NOT been recognised (and styled accordingly) should be styled as UnTreated”; in effect every paragraph of text in every document is re-styled to an installation standard.

(later) ooops. You didn’t want an appliaction that could accurately dis-embody a program to/from a text file; you wanted VBA code, right? That too could be done. Instead of outputing a stream of encoded text (Hey! It looks like RTF format!!!!!) you would need to go one step further and output the VBA code. Imagine one of my procedures that is handed a range of text and told to “output the local formatting specisifactiosn for this range of text”; instead of outputing a stream of characters that can be interpreted by my code, I’d output a code that looked like, and was, VBA instructions for formatting a range of text. Those instructions would then be read into modules and the main macro in each module would be executed.

I think I’d prefer a coded text method to a VBA code method; the latter is awkward to modify.

Reply | Quote

How about if you store RTF in your Access database and paste that into a Word document? I don’t know very much about RTF formatting, but I think it might work for normal inline objects like paragraphs of text, and pictures. Not sure about fields. Drawing layer probably not.

Reply | Quote

Just wondering on this point, which of RTF and HTML might give a more “faithful” rerendering in Word? I know I’ve encountered “Paste Special” situations (from Excel) where RTF is better, but this has been without the complication of graphics.

Alan

Reply | Quote

> which of RTF and HTML might give a more “faithful” rerendering in Word?

I suspect RTF, if the formatting is at all complicated. It also might be easier for you. Trying to specify, for example, a hanging indent in just a small snippet of a document, irrespective of the overall style sheet, is going to be messy.

Reply | Quote

Makes sense to me.

cheers
Alan

Reply | Quote