Thanks for that.

--

Graham Mayor - Word MVP

My web site www.gmayor.com
Word MVP web site http://word.mvps.org


Bryan L wrote:
I found the solution in one of MacroPod's posted replies to a
similarly-frustrated user on the Woody's Lounge forum. I'll repost
for the benefit of readers he

"The clue to your problem is in the output format you've specified in
[your post]. The fields in the document are region-dependent and are
coded to work on systems that are configured to display dates
formatted as d/MM/yyyy (short form) or dddd, d MMMM yyyy (long form).
Something I'll need to note in the next update. Your 'issue' relates
to a system that is configured to display dates formatted as
MM/d/yyyy (short form) or dddd, MMMM d yyyy (long form). To obtain
the correctly result is as simple as changing the expression
'dd*10^6+mm*10^4+yy' to 'mm*10^6+dd*10^4+yy'. Adding the appropriate
date switch will then display the result accordingly."
I changed my expression to the alternative he provided and it fixed my
problem; all positive and negative delay values now calculate to the
correct date. Many users in the USA may want to make a note of this.

Thanks again to MacroPod for excellent work and his continuing
assistance!!
Bryan

--------------------------------------------------
"Bryan L" wrote in
message ...
Ok, I've learned a bit more. *(Note that in all my examples, I'm
substituting my merge field "MemoDate" for his merge field
"MergeDate". MemoDate happens to always merge the current date. I'm
using it in my merge templates instead of Word's built-in Date
function because if I can get it to work properly I'll know I can
perform date calculations on any other dates pulled from our DB). Here's
what's happening: Using his unaltered* code produces the following result
in my
mailmerge document:

no later than 13/01/2006Friday, January 27, 2006:

I thought I'd found an "oops" in the code when I saw the two dates
side-by-side, which is why you saw in yesterday's post I had omitted
Line 3, {MERGEFIELD MergeDate \@ d/MM/yyyy}. Doing so corrected the
problem of the 13/01/2006 preceding the calculated date, and the
displayed calculated date still appeared to be correct:

no later than Friday, January 27, 2006:

I experimented with different positive delay values and they all
worked. I then experimented with negative delays and got strange
results. The list below shows my output with various negative delay
values (with Line 3 still omitted as mentioned above):

(various negative numbers)
-1: no later than Friday, December 1, 2006:
-2: no later than Wednesday, November 1, 2006:
-3: no later than Sunday, October 1, 2006:
-4: no later than Friday, September 1, 2006:
-5: no later than Tuesday, August 1, 2006:
-6: no later than Saturday, July 1, 2006
-7: no later than Thursday, June 1, 2006:
-10: no later than Wednesday, March 1, 2006:
-12: no later than Sunday, January 1, 2006:
-13: no later than Saturday, December 31, 2005:
-14: no later than Friday, December 30, 2005:
-15: no later than Thursday, December 29, 2005:
-16: no later than Wednesday, December 28, 2005:
-20: no later than Saturday, December 24, 2005:
-21: no later than Friday, December 23, 2005:
-22: no later than Thursday, December 22, 2005:
-23: no later than Wednesday, December 21, 2005
-24: no later than Tuesday, December 20, 2005:
-25: no later than Monday, December 19, 2005:
-26: no later than Sunday, December 18, 2005:
-27: no later than Saturday, December 17, 2005:
-28: no later than Friday, December 16, 2005:
-29: no later than Thursday, December 15, 2005:
-30: no later than Wednesday, December 14, 2005:
-31: no later than Tuesday, December 13, 2005:
-32: no later than Monday, December 12, 2005:
-33: no later than Saturday, November 12, 2005:
-34: no later than Wednesday, October 12, 2005:
-35: no later than Monday, September 12, 2005:
-36: no later than Friday, August 12, 2005:
-37: no later than Tuesday, July 12, 2005:
-38: no later than Sunday, June 12, 2005:
-42: no later than Saturday, February 12, 2005:
-49: no later than Friday, November 25, 2005:
-56: no later than Friday, November 18, 2005:
-63: no later than Friday, November 11, 2005:
-70: no later than Monday, April 11, 2005:
-77: no later than Friday, October 28, 2005:
-84: no later than Friday, October 21, 2005:

If I restore the MemoDate mergefield from Line 3 and try a sampling
of dates from the list above I get the following:

-1: no later than 13/01/2006Friday, December 1, 2006:
-2: no later than 13/01/2006Wednesday, November 1, 2006:
-15: no later than 13/01/2006Thursday, December 29, 2005:
-28: no later than 13/01/2006Friday, December 16, 2005:
-38: no later than 13/01/2006Sunday, June 12, 2005:

As you can see, there is no change in the correctness of the date
calculations. Good dates are still good and bad dates are still bad;
they are all simply prepended with the result of the MemoDate merge
field. In MacroPod's document beneath the example for Date Calculations
In A
Mailmerge, he includes the following note:

In the above example, the Mergedate wouldn't normally
display (it does here because this document doesn't use a true
mailmerge) and, if the delay was being imported as part of the
mailmerge, you could also replace {SET Delay nn} with {SET
Delay{MERGEFIELD MergeDelay \# 0}}.

I think the MergeDate (or in my case, the MemoDate) field isn't
intended to be diplayed, but is somehow to be used in the
calculations. Since in my document it's displaying for some reason,
it's probably NOT being used in the calculations as intended, and in
some cases this results in bad output when a negative delay is used.

To rule it out as an issue, I've changed my customized diplay mask
at the end of the last line to match his example. No change.

Since I don't have a datasource that uses MergeDate as a valid merge
field, how can I test his code completely unaltered? Would that
fact that I'm using merge fields from a SQL datasource change
anything? Should simply replacing his Mergefield with a valid one
for my datasource "break" the code?

Thanks again for all input and the time spent on this.

Bryan

___________________________________________
"Graham Mayor" wrote in message
...
Apart from the fact that it should be Mergefield MemoDate and not
MemoDate, I can't see anything wrong with that.
Does the unaltered code from Macropod's document work correctly? It
does here.

In case Macropod isn't watching this group, I'll copy your query to
him for comment.

snip