# Thread: WordBasic to VBA: An odd question (Word VBA)

1. ## WordBasic to VBA: An odd question (Word VBA)

Since I am an odd person, guess I can ask an odd question.

ASSuME that you know everything there is to know about converting WB to VBA. Of course, no such person likely exists, but let's make believe.

Such a person would be able to look at each WB statement and almost instantly determine what needs to be done to replace the code with VBA.

My question is "How many statements per minute do you think such a person could manually convert?".

For we mere mortals, that number is likely less, so how many statements per minute could we mere mortals expect to manually convert?

2. ## Re: WordBasic to VBA: An odd question (Word VBA)

<hr>Since I am an odd person, guess I can ask an odd question.<hr>
<img src=/S/laugh.gif border=0 alt=laugh width=15 height=15> This has to be a rhetorical question, Howard. I doubt that you could ever get any agreement on the answer and to what purpose anyhow?

4

4. ## Re: WordBasic to VBA: An odd question (Word VBA)

So at 4 per minute, it would take 978 minutes to convert 3910 statements.]If a program did the conversion in 13 minutes, that program would be quite valuable, n'est-ce pas?

Using the above numbers the program is about 75 times faster than the manual method, so if the hourly rate for the manual effort is \$N, charging anything less than \$N * 1.25 per minute to use the program is a bargain.

5. ## Re: WordBasic to VBA: An odd question (Word VBA)

Pricing might be suppressed by the fact that a "good enough for most people" converter is built-in to Office 97-2000-XP at no additional charge. (Not sure about 2003 or future versions...)

6. ## Re: WordBasic to VBA: An odd question (Word VBA)

I calculated 42 ... but there again, that's the answer I come up with for everything. <img src=/S/grin.gif border=0 alt=grin width=15 height=15>

Alan

7. ## Re: WordBasic to VBA: An odd question (Word VBA)

The built-in importer does even make a stab at converting.
It's not a converter, rather it forces code tto run via the WordBasic object, which inadequate for any code thatis oft run, or has a long future.

8. ## Re: WordBasic to VBA: An odd question (Word VBA)

But... it is "good enough for most people." <img src=/S/grin.gif border=0 alt=grin width=15 height=15>

9. ## Re: WordBasic to VBA: An odd question (Word VBA)

Not really, they just don;t understand why it is not.

10. ## Re: WordBasic to VBA: An odd question (Word VBA)

<hr>It's not a converter, rather it forces code tto run via the WordBasic object<hr>
According to the Word 2000 Help file:
Word 2000 automatically converts the WordBasic macros in a Word 6.x or Word 95 template to Visual Basic for Applications the first time you perform any of the following actions:
. Open the template
. Create a new document based on the template
. Attach the template to a document by using the Templates and Add-Ins command on the Tools menu.
A message appears on the status bar while the macros are being converted. After the conversion is complete, you must save the template in order to save the converted macros. If you don't, Word converts the macros again the next time you use the template.
Note Once you have saved a converted WordBasic macro in Word 2000, you will not be able run it in Word 6.x or Word 95

11. ## Re: WordBasic to VBA: An odd question (Word VBA)

Running code via the WordBasic object does not fully convert code to VBA.

Indeed, working via the WordBasic object, some code produces incorrect results, or actually is a no-op, or produces different results than you would get converting the code to VBA. See http://www.standards.com/index.html?...sicBrokenInVBA.

Not to mention, code converted to use VBA instead of working via the WordBasic object:

1. In general, will execute faster.
2. Is easier to maintain.
3. Is easier to enhance.
4. Allows for much better design of the code.

MSFT states that what they do is a "conversion" because it is easier to say that rather than try to explain what they are really doing.

For example, much code cannot be automatically converted, so MSFT has to fake it by running via the WordBasic object. The most obvious example is a Word Basic Dialog box, especially those with underlying dynamic code.

Not to mention, doing a conversion often, if not almost always, results in errors being exposed in the original WordBasic code. Note that syntactic conversion will often result in errors in the converted code at run time. The latter is likely the reason that MSFT does not automatically convert certain statements that I can automatically convert with my program. I am aware of some of those problems and know that I have to go back and manually adjust the code, depending on what the particualr WordBasic macro was trying to do. If MSFT automatically converted those statements to VBA, there would be serious problems for users not knowing how to fix things.

Macros in Word 97 files cannot run in Word 6 and Word 7 because Word 6 and Word 7 jusy do not use VBA.

12. ## Re: WordBasic to VBA: An odd question (Word VBA)

Howard,

I still question the purpose of this thread. Are you just sounding off, or did the original question have some significance? Are you trying to gauge the pricing for a product you're working on? If so, why not make that clear? <img src=/S/smile.gif border=0 alt=smile width=15 height=15>

13. ## Re: WordBasic to VBA: An odd question (Word VBA)

Surely, you'd want to do many, many things differently in VBA than they were customarily done in WordBasic...

Say, use ranges where the original macro used bookmarks.
Or use "For each object" where the original macro went from one object (say para, or table) to the next until it hit the end of the document.

It would seem a quite Herculean task to attempt a converter which does such things.
Whether you use<pre>
WordBasic.DrawArc
</pre>

with the proper arguments, or "real" VBA<pre>ActiveDocument.Shapes.AddShape(msoShapeArc , Left, Top, Width, Height, [Anchor]).Select
</pre>

doesn't seem so important to me in comparison.

<img src=/S/cheers.gif border=0 alt=cheers width=30 height=16> Klaus

14. ## Re: WordBasic to VBA: An odd question (Word VBA)

The first pass for a WB to VBA conversion is to let Word automatically do its thing.

The second pass is to convert the simple stuff, some of which I understand why Word won't automatically convert, but there's a lot that Word could automatically convert, I know not why it does not do so. Doing tis automatically saves a lot of time, not to mention reducing the tedium.

The 3rd pass is converting that things that cannot automatically be converted, in particular Dialogs with underlying code. Sometimes, it is best to put this pass off until (nearly) everything else is done.

Once the above is done, then the 4th pass would be converting to better techniques, such as using Range instead of Selection and WB drawing stuff to native VBA stuff.

The 5th pass is to make the code more efficient and more readable and more maintainable.

Steps 4 and 5 are of course optional as they greatly increase the cost of a conversion.

For an experienced WB to VBA perverter, ooops, I mean converter, a number of these steps can overlap.

Of course the WB object still has its uses for certain things that just do not have a VBA equivalent.
I am concerned that MSFT could drop WB support in a .NET-ized Office.

15. ## Re: WordBasic to VBA: An odd question (Word VBA)

> The second pass ...

I never did much WordBasic to VBA conversion, but I'm sure you are right and there's a lot of stuff that could be converted properly and isn't.

One reason why the converter may leave some WordBasic stuff may well be that it can't know what to translate the WordBasic command to.

Many WordBasic commands are highly versatile and do a lot of things, and different things, depending on the current selection, option settings, etc.

Say, WordBasic.CenterPara (Ctrl+E) centers the paragraph, but also deletes whitespace from both ends of the paragraph.
Should the converter put in code for trimming whitespace, just to be on the safe side?

EditClear (Del key) deletes the selection, or deletes the character to the right of the IP if nothing is selected.
VBA's Selection.Delete acts the same way in both cases, although this doesn't seem sensible when nothing is selected.

Already, you'll see lots of "If ... then... else ..." in "converted" WordBasic VBA code, and if the conversion was done "properly", there'd probably be many more.

> Steps 4 and 5 are of course optional as they greatly increase the cost of a conversion.

But that's where the benefits in moving from WordBasic to VBA are. If you leave those away, you could have left everything in WordBasic, IMO.

WordBasic is a language for remote-controlling the user interface (using built-in commands and dialogs).
VBA is a language putting you in the driver's seat, manipulating the document's objects directly.

If you leave away 4 and 5, you have a program for remote-controlling Word, written in a language that isn't made for that task.

<img src=/S/cheers.gif border=0 alt=cheers width=30 height=16> Klaus

Page 1 of 2 12 Last

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•