Re: Insert a future date
- From: "Graham Mayor" <gmayor@xxxxxxxx>
- Date: Sat, 14 Jan 2006 09:08:20 +0200
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 here:
>
> "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" <blinton.nospam@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> message news:uOMQomGGGHA.1424@xxxxxxxxxxxxxxxxxxxxxxx
>> 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" <gmayor@xxxxxxxx> wrote in message
>> news:O8RNhfBGGHA.2212@xxxxxxxxxxxxxxxxxxxxxxx
>>> 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>
.
- References:
- Re: Insert a future date
- From: Bryan L
- Re: Insert a future date
- From: Graham Mayor
- Re: Insert a future date
- From: Bryan L
- Re: Insert a future date
- From: Graham Mayor
- Re: Insert a future date
- From: Bryan L
- Re: Insert a future date
- From: Bryan L
- Re: Insert a future date
- Prev by Date: Re: IF then with merged date field from excel
- Next by Date: Re: How to Close original Document after executing MailMerge.
- Previous by thread: Re: Insert a future date
- Next by thread: Re: Insert a future date
- Index(es):
Relevant Pages
|
