macro in IF...THEN

[Larry Cohen via OfficeKB.com]

Does anyone know if it is possible to have an IF...THEN test on a mailmerge
mergefield, and if the result is positive, automatically run a macro?
For example, IF mergefield data_10 is blank, run macro "removerow"

 

[Graham Mayor]

That isn't the way to achieve the required result. Instead use the condition
to only include the field and line feed when the field has content. eg

{IF {Mergefield data_10} <> "" "
{Mergefield data_10}"}


--
<>>< ><<> ><<> <>>< ><<> <>>< <>><<>
Graham Mayor - Word MVP


<>>< ><<> ><<> <>>< ><<> <>>< <>><<>

 

[Larry Cohen via OfficeKB.com]

Graham
Yes I know how to do that. Sorry I should have explained better.
I am trying to delete a row in a table, if the field is blank.
That's why I want to run a macro to delete the blank row in the table.

 

[Peter Jamieson]

As far as I know there is only one reasonably reliable way to run a
user-defined macro during a merge and that's to use the mailmerge events,
which are only available in Word 2002 or later. If that's your scenario you
would typically put the comparison code directly in the
MaiMergeBeforeRecordMerge event code, but you could of course bookmark or
otherwise discover the result of the IF field in the event code and act on
it.

Peter Jamieson

 

[Larry Cohen via OfficeKB.com]

I know nothing about "mailmerge events" or "MaiMergeBeforeRecordMerge event
code"
Is there someplace that has documentation on how to use?

Thanks

 

[Peter Jamieson]

There used to be some sample code on how to use these events in the Word VBA
Help that you can get to using the VBA editor's Help menu. You may also find
some of my sample code if you search Google Groups for my name and (say)
MailMergeBeforeRecordMerge.

If you are going to go down this route, a few more things to be careful
about are:
a. these events are /Application/ events. If one document has set up an
event handler module to handle application events, when other documents fire
the events they will be handled by that event handler, as far as I know.
b. MailMergeBeforeMerge only fires if the merge is initiated from the mail
merge wizard. This actually makes the business of initialising anything
pre-merge - if you happen to need to do that - extremely difficult.
c. as far as I know the events only fire when you merge, not when you
preview, which might be confusing for the user
d. the events are not really the ones I would want, and in at least one
case the name is misleading in my view. But from what you say that probably
doesn't affect you.

Are you trying to delete table rows /in the data source/ (or perhaps a
related data source?) or table rows /in a Word table/ ? If the former, you
may fall foul of locking/concurrency issues.

Peter Jamieson

 

[Larry Cohen via OfficeKB.com]

I have a requirement to insert mergefields in a "form" that can have from 1
to about 100 rows. I created a table with 100 mergefields, but if the
mergefields from, lets say, 10-100 are blank, then 1-9 look fine, but 10-
100 are blank, and don't roll up.
I got around this by making my table only 2 rows deep, with the first row
having the "labels" and using IF...THEN...ELSE for all the 100 mergefields.
I insert two blank lines if the mergefield is not null, so a blank line
separates the non-blank entries, and all the blanks roll up.
While that looks ok, it does not look as good as a fully formed table in
the merge doc. It also means I can not merge other data on the same row
without potential problems with blank entries for the second field, and
possible wraping of data in a cell - which would look terrible in a two row
table.
So I wondered if there was any way to delete the unused rows in the table
in the merge doc if there was no data in any cell on the row.

Thanks

 

[Peter Jamieson]

I don't think you will be able to do this using fields for the reasons you
have already discovered.

I think your options include:
a. do the merge and postprocess the output to remove blank table rows. You
could probably do that with a relatively simple bit of VBA. However, if you
have to output directly to printer, e-mail or fax, it isn't an option.
b. use the "mailmerge events" I suggested. That also requires VBA and I can
tell you that it's likely to be a lot harder to get right than (a).
c. "roll your own" merge using (say) VBA. That's more work than either (a)
or (b) but in principle gives you a lot more control.
d. redesign your data source so that a field-based solution (or some other
solution) becomes feasible. In this case, it would need to be the kind of
solution where you have 100 rows per form, each one containing a single
field, rather than 100 fields per form, all in one row. One possible
approach is to have
- a merge data source that contained one record for each "form"
- a second data file of some kind that has as many rows as are required to
generate the table for that form.
- use a DATABASE field in your mail merge main document to get the data
from the second file.

It's difficult to tell which of these approaches, if any, would help you.
Personally I would prefer it if the "FIELD language" was more powerful and
let you do this kind of stuff more easily without having to resort to
procedural code, but it isn't.

Peter Jamieson