I'm trying to get a report to work that takes a start date and end date as parameters, but I want to add 14 days to the end date before comparing to the data set.

My date in the table is in HYYMDI format (I also have a MDYY version of the column).

My start date compares to this parameter as a straight comparison and works REGARDLESS of what format I type (MM/DD/YYYY or YYYY/MM/DD). I've used some other posts here to figure out how to accomplish the +14 days, but I can only get that to work if the input is in a consistent format because I'm using EDIT. For instance, 11/01/2013 works, but 11/1/2013 doesn't.

Basically, I want the user to not have to worry about what they are inputting. They shouldn't have to think about whether they need 2-digit months or days, it should work in either case.

-DEFAULT &EndDate = '11/1/2013';

-SET &S1 = EDIT(&EndDate, '99$99$9999');
-SET &S2 = DATECVT(&S1, 'I8MDYY','I8YYMD');
-SET &S3 = DATEADD(&S2,'D',14);
-SET &S4 = CHGDAT('YYMD','MDYY',&S3,'A10');
-SET &PPE_2WKS = EDIT(&S4,'99/99/9999');

-TYPE &EndDate
-TYPE &S1
-TYPE &S2
-TYPE &S3
-TYPE &S4
-TYPE &PPE_2WKS

Thanks!

Michael

This message has been edited. Last edited by: <Kathryn Henning>,

Mike, first use functions that work on &vars,
get your date into an A8YYMD format, ie 20131127
then use the AYMD function to add x days to your date.
-SET &twowksago = AYMD ( &YYMD.EVAL , -14, 'I8YYMD');
Do you have the Using FUnctions manual? if not, download it, its priceless. and/or get the WF Keysheet.

you'll have to put some restrictions on your input , otherwise you cant tell the difference between 11/1 and 1/11, eg.

quote:

Basically, I want the user to not have to worry about what they are inputting. They shouldn't have to think about whether they need 2-digit months or days, it should work in either case.

If that's what's required then you'll have to come up with your own "date parser" because no matter what function you write to calculate the offset it has to see the value as an actual DATE as pointed out by susannah and not as a free-form string.

Why not trying to make your and your users' lives easier and give them a nice calendar control they can use to enter the dates in the UI and let it take control of the internal representation? No parser to write You'll make sure the calendar always provides the date in an agreed format (YYYYMMDD or YYYY/MM/DD comes to mind) and you can use DATECVT function to turn the value into a DATE knowing that the entry pattern will always be.

HTML Composer provides a calendar control for that. Not the prettiest but gets the job done!

I haven't had a chance to give this a shot with the holiday, but I appreciate the input and will be trying for a solution today. I may have come up with something that avoids the 14 day calculation completely. I am definitely going to go find that function manual! Thanks for the tip!

njsden - What you're hitting on, to me, is a huge failure in this product. The user should not be constrained to choose between typing a date and using a calendar control. They should be able to use either one. I tried using the calendar control in HTML Composer for another report, but it puts YY/MM/DD format on the screen. The problem with that, to me, is that it's not the way people typically think about dates (at least in the US). The most common format is MM/DD/YYYY. Someone should be able to both enter it that way and see it that way if chosen in the control. If you have suggestions on making that happen, I would greatly appreciate the input. I will tinker some more on that front, though.

I have used many other reporting applications and have never seen anything remotely as complicated as date handling in WebFocus. Microsoft Reporting Services, for instance, allows you to type dates in any possible format and it will accept it and compare to any other format without an issue. Anyone know the rationale for having to jump through so many hoops?

calendar lets you pick whatever date format you want...

I don't see how to do that. No matter what I do, the format that is displayed back to the user is Y/M/D. I set the Date format in Data Source to YYMD (which I don't think my fex can handle at the moment), but it doesn't affect the front-end.

What's amazing to me is if I type in ANY of these formats, the report works just fine:
M/D/YY
YY/M/D
M-D-YY
YY-M-D
YYMD

If at any point it's a 2-digit year, the whole thing falls apart or if I do MDYY without any characters separating the fields.

After the Y2K stuff many of us had to endured back during the transition from 1999 to 2000 I think most of us were convinced that using 4-digit years is the way to go.

If I see a value such as 12/4/11 I have no idea what that means ... is it April 11, 2012? April 12, 2011? Dec 4, 2011? Nov 4, 2012?

I'd suggest to stick with a common format and make sure your application and users adhere to it.

As for the actual calendar control in HTML composer, what susannah suggested is done via the Properties and Settings of calendar controls in HTML composer:

I am definitely trying to use 4-digit years. By default, however, the calendar control is returning a value to the textbox in 2-digit format. I don't understand why that's the case and no matter what I do in the Properties/Settings it always come back to the user (the webpage) in that format.

For instance, if I put today's date it will come back to the page as 13/12/06.

Unfortunately that may be a bug (or "undocumented feature") in your specific version.

The format setting in HTML Composer works as expected in WebFOCUS 7.7.03 and 7.7.05.

Even though I'm using 7703, you may be right. I edited the HTML directly and changed the IBIFormat property to MDYY and it worked exactly as expected!

Thanks for the feedback!

quote:

Even though I'm using 7703

Oh! I didn't know you were already on 7.7 as your signature suggested otherwise. Glad this is working for you now, even if you had to do it behind the scenes as with many other "Composer" things .

Oops! Thanks for catching that. I updated my profile.

I so eagerly look forward to finding all the other things to modify by hand!