Good whatever-part-of-the-day-it-is-where-you're-at,

I have a couple of frequently recurring data formats that I have to convert for human readable output in a LOT of fexes. That got me wondering, is there some method I could use so that I don't need to:

• Store display information in my hold files
  
• Have to repeat my data conversions for display in every fex
  

..and - important - which I can use in embedded procedures as they're created in the HTML Composer?

For example, a frequently recurring data type in our data is a calendar-week. That's a 5-digit number, where the first three digits represent the year since 1900 and the last 2 represent the week number. This week would be 11112.

To make that human readable in headings and such, I need to display that as "12/2011".
For launch-pages I usually need to split off options for a year drop-down with {value="111", text "2011"} and a (chained) week drop-down with {value="11112", text="12"}.

I tend to create these DEFINE's:

-* Raw year value for use in dropdown value-attribute
CALYR3/I3 = CALWEEK/100;

-* Printable year value for displaying in dropdown
CALYR4/I4 = 1900 + CALYR3;

-* Printable week value for displaying in dropdown
CALWK/I2 = IMOD(CALWEEK, 100, 'I2');

-* Print-version of CALWEEK for headings and such
CALPRN/A7 = EDIT(CALWK) || '/' || EDIT(CALYR);

It would really safe me a lot of trouble (and some disk space) if these conversions to human-readable formats could be defined somewhere central to our reports, so that I don't need to repeat the same bits of code over and over and so that I don't need to alter our report-caster reports to also store the human-readable versions of the data.

I can't really use a central TABLE FILE with all the existing calendar years and weeks, as the available selections differ per data-table (some data deals with past weeks, some are work planned for the future). Also, I can't really use joins in embedded procedures, so a conversion table won't help me either I think...

I thought of altering my masters by adding the above mentioned DEFINEs, but many of the masters I'd need to alter are the result of ON TABLE HOLD, so they'd get overwritten as soon as the report-caster runs again.

Any ideas?

This message has been edited. Last edited by: Kerry,

Would it be an option for you to create some DEFINE FUNCTIONs? Look up the doc on that. I find it very usefull is situations like this.

I would create MS SQL Server Views with these "virtual fields" as table columns...

quote:

Originally posted by GamP:
Would it be an option for you to create some DEFINE FUNCTIONs? Look up the doc on that. I find it very usefull is situations like this.

Oh, that does look really useful for formatting data for headings, thanks!
I guess for the dropdowns there's not much choice but to store years and weeks in a hold-file generated from the fex that includes the HTMLFORM for the launch-page.


I just found out that you can't directly coerce function results into expressions, the typecasting goes wrong... :facepalm:
It seems you can't put them directly in a HEADING either, you need to DEFINE a few fields for those values first? Really?

To elaborate on the first matter, I tried this:

DEFINE FUNCTION PIBYEAR(KALDAT/I11)
	YR3/I3 = KALDAT/100;
	PIBYEAR/I4 = 1900 + YR3;
END

DEFINE FUNCTION PIBWEEK(KALDAT/I11)
	PIBWEEK/I2 = IMOD(KALDAT, 100, 'I2');
END

-* Doesn't work, outputs '0000/00'
-*DEFINE FUNCTION PIBDATE(KALDAT/I11)
-*	PIBDATE/A7 = EDIT(PIBYEAR(KALDAT), '9999') || '/' ||
-*                     EDIT(PIBWEEK(KALDAT), '99');
-*END

DEFINE FUNCTION PIBDATE(KALDAT/I11)
-* This does work.
-* Apparently FOCUS forgot I declared those as I4 and I2 respectively?
	Y/I4 = PIBYEAR(KALDAT);
	W/I2 = PIBWEEK(KALDAT);
	PIBDATE/A7 = EDIT(Y, '9999') || '/' ||
                     EDIT(W, '99');
END

This message has been edited. Last edited by: Wep5622,

Remember that an integer in I11 internally, well I10 and a half.

I think this may be why you get 0000/00.

e.g.

DEFINE FUNCTION PIBYEAR(KALDAT/I11)
	YR3/I3 = KALDAT/100;
	PIBYEAR/I4 = 1900 + YR3;
END

DEFINE FUNCTION PIBWEEK(KALDAT/I11)
	PIBWEEK/I2 = IMOD(KALDAT, 100, 'I2');
END

-* Doesn't work, outputs '0000/00'
DEFINE FUNCTION PIBDATE(KALDAT/I11)
	PIBDATE/A23= EDIT(PIBYEAR(KALDAT), '99999999999') || '/' ||
                     EDIT(PIBWEEK(KALDAT), '99999999999');
END

-RUN

-SET &RES1 = PIBYEAR(9052) ;
-SET &RES2 = PIBWEEK(9052) ;
-SET &RES3 = PIBDATE(9052) ;

-TYPE &RES1
-TYPE &RES2
-TYPE &RES3

But it shouldn't be, those functions explicitly return integer types with less precision (I4 and I2 respectively).

There is always the difference between internal format and display format - the usage and actual. Same goes for master files. In this case, wihtin the define function the usage formats (I4 and I2) are being respected, but what comes out of the function is an integer. No display options. So when calling the function, you store the output in a defined format, which in this case should be an I4 or I2, that indicates the usage formats. You did not specify any format at first, which has always defaulted and will always default to ... D12.2. Hence the 0000/00, since EDIT can't very well handle D-type numbers.

quote:

Originally posted by GamP:
You did not specify any format at first, which has always defaulted and will always default to ... D12.2.

Could you explain what you mean there? I'm pretty sure I did specify a format.

-* Doesn't work, outputs '0000/00'
-*DEFINE FUNCTION PIBDATE(KALDAT/I11)
-*	PIBDATE/A7 = EDIT(PIBYEAR(KALDAT), '9999') || '/' ||
-*                     EDIT(PIBWEEK(KALDAT), '99');
-*END

No format defined for PIBYEAR(KALDAT) - to be honest, in this setup you can't. But the result of PIBYEAR and PIBWEEK will both default to D12.2 ...

Or maye indeed to I10 or I11, as Waz states, but I'm sure it is in internal (actual) format.