TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Macros and luck From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Sat, 6 Apr 1996 09:05:00 EST
At 01:08 PM 4/5/96 -0800, you wrote:
I just had to respond to this.
>>Macros and a macro recorder are in Frame now.
> I am using Frame 5.0. I have looked for such a feature
> and documentation of such a feature. Where should I be
> looking to find this miracle? :)
Macros don't exist in the Windows version of Frame. If you want something
like that, you have to get the FDK and hire a C programmer. You can program
some rudimentary ones on the Mac using AppleScript, but it's not nearly as
easy or as powerful as Word's. Ironically, Word doesn't have macro
capability on the Mac, but there's extensive macro capability in Windows.
>>"Support for incremental saves. Long docs take too long to save."
>>Not if you have a fast CPU.
> Not everyone is as lucky as you are...
Roger that. I've just completed four documents, each one over 4 meg because
they were overwhelmingly tabular. Tables in Frame are treated as graphics. I
could go get coffee while these things saved, and I'm running a 100 MHz
Pentium. I've had to cut way back on automatic saves while I was doing these
whales, making it all the more likely that I'd lose work.
Of course, now that I've slammed Frame to the mat, I'm forced to add that we
couldn't have done this project, a database publishing effort, in any other
comparable package. The whole document consists of 32 tables, listing shaft
sizes, part numbers, prices and weights for over 4,000 parts EACH ONE
indexed. (Go ahead, ask how long it took to put index markers on 4,000
parts. You'll be surprised by the answer.)
Each catalog will be around 42 to 45 pages when assembled. Once we got our
procedures humming, we could turn a database dump into a book within a
couple of days. We made extensive use of variables and markers, including
MML. Not only did it save us much time typing headings over and over again,
we now have the capability of making a single global change to a single
heading variable such as "Price" and have every such heading throughout the
book instantly change to correspond. That simplifies changes and updates, as
well as making the initial compilation go faster.