Re: Insert a future date
- From: "Bryan L" <blinton.nospam@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 13 Jan 2006 14:53:43 -0600
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>
.
- Follow-Ups:
- Re: Insert a future date
- From: Graham Mayor
- Re: Insert a future date
- 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
- Prev by Date: Re: Insert a future date
- Next by Date: Problem in mail merging in word 2003 with XP as OS and VB 6
- Previous by thread: Re: Insert a future date
- Next by thread: Re: Insert a future date
- Index(es):
Relevant Pages
|
