I'm in the middle of crafting some include files to make handling compound (PDF) layouts a little easier. We use those for templating by adding a few logo's in the heading and positioning a standard footer and such.

Some of the things I have to deal with are paper size and page orientation, which I tried to parametrise.
Typically, page sizes aren't rounded numbers. For example, the A4 page size in landscape is 27.7 x 21 cm.
I ended up with this:

-DEFAULTH &CP_PAPERSIZE = A4
-DEFAULTH &CP_PAPERORIENTATION = LANDSCAPE

-SET &CP_PAPERDIM1 = DECODE &CP_PAPERSIZE('A3' 42.0, 'A4' 27.7, 'A5' 10.5);
-SET &CP_PAPERDIM2 = DECODE &CP_PAPERSIZE('A3' 27.7, 'A4' 21.0, 'A5' 13.8);

-SET &CP_PAPERWIDTH	= IF &CP_PAPERORIENTATION EQ 'LANDSCAPE' THEN &CP_PAPERDIM1 ELSE &CP_PAPERDIM2;
-SET &CP_PAPERHEIGHT = IF &CP_PAPERORIENTATION EQ 'LANDSCAPE' THEN &CP_PAPERDIM2 ELSE &CP_PAPERDIM1;

SET HTMLARCHIVE=ON
COMPOUND LAYOUT PCHOLD FORMAT PDF
UNITS=CM, $
SECTION=section1,
 LAYOUT=ON, METADATA='0.5^0.5^0.5^0.5^1',
 MERGE=OFF,
 ORIENTATION=&CP_PAPERORIENTATION, PAGESIZE=&CP_PAPERSIZE,
$
...etc.

These parameters are then used in calculations to determine at which position and with what dimensions an element/component on the page needs to be rendered.

Sounds easy enough, right? Wrong...

The problem is that these calculations need be done using dialog manager, and that language cannot properly deal with fractions! It's going to round every number down...

For example, if some component of a page is offset from the right, I'll have to determine its position by subtracting its width from the page width (minus margins), for example: -SET &COMPONENT_LEFT = 27.7 - 0.5 - 11;

Here's an example of how different reports end up in the compound layout, each report in its own COMPONENT:

-SET &CP_FOOTER_TOP = &CP_PAPERHEIGHT - 4.3;

-REPEAT :CP_NEXT_REP FOR &CP_REPNR FROM 1 TO 4
-SET &COMPONENTID = 'Report'||&CP_REPNR;

PAGELAYOUT=&CP_REPNR, NAME='Page layout &CP_REPNR',
 text='&CP_REPORT_TITLE.&CP_REPNR',
 TOC-LEVEL=1,
 BOTTOMMARGIN=0.5, TOPMARGIN=2.5,
 METADATA='BOTTOMMARGIN=0.5,TOPMARGIN=2.5,LEFTMARGIN=0,RIGHTMARGIN=0,',
$
-SET &HEIGHT = &CP_PAPERHEIGHT - 3.5;
COMPONENT='&COMPONENTID', POSITION=(1 1.5), DIMENSION=(&CP_PAPERWIDTH &HEIGHT),$
COMPONENT='Footer&CP_REPNR', POSITION=(1 &CP_FOOTER_TOP), DIMENSION=(&CP_PAPERWIDTH 3),$
-:CP_NEXT_REP

There wouldn't be much of a problem if I could specify positions and sizes in MM's, but WF only supports CM's and INCHes and with those I'm going to end up with numbers with fractions.

I know I can use PTOA() to wrap the calculations so that DM doesn't "round them down", but I'm going to have to do that a LOT.
Besides, I do expect users to be able to create simple page-layouts themselves (wrapped inside my code), and I don't think they'll be able to fathom that decimal numbers aren't going to be interpreted as such, let alone how to use PTOA...

Is there a different way perhaps? Something that's a little more workable?

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

Look at DMPRECISION.

... alas, it is not apparent in DS ...

quote:

Originally posted by Alan B:
Look at DMPRECISION.

Thanks, that solves it.

Such a long question, and yet a simple answer.

Is that WebFOCUS embodied ?

...and you don't find it peculiar

• that dialog manager doesn't pick the correct internal data format for decimal numbers or
• that the behaviour of dialog manager code is set with a focus command or
• that that setting is global to the script?

I'm glad I know about this setting, but in my opinion WebFOCUS could do with a thorough redesign and rewrite.

This interesting article on the use of FUNCTIONs in dialog manager might give you some ideas.

newsletter

quote:

but in my opinion WebFOCUS could do with a thorough redesign and rewrite.

Could be. But, the ramifications of backwards-compatibility are mind-boggling... (imho)

DM uses varient variables. So, there are what they are. DM does know if they are Alphanumeric or Numeric. But not precision unless directed to do so using "DMPRECISION".

quote:

...and you don't find it peculiar
that dialog manager doesn't pick the correct internal data format for decimal numbers or
that the behaviour of dialog manager code is set with a focus command or
that that setting is global to the script?

No, not at all. First, DM is a scripting language. I prefer to think of it as a lanugage the control the flow of a job. Second, DM variables are and have always been alpha strings. They are not ever stored internally as a number. A variable, &CP_PAPERDIM1 with a value of 27.7 is just an alpha string that happens to contains numbers. They may get converted to a number to do calculations, the variables are always alpha strings.

As for DMPRECISION, it is a relatively new feature for DM. To maintain backward compatibility it defaults to 0. As for it being global to the script, are you saying if it is set in edasprof it is ignored? If so, I'd open a problem report with IBI and see if they will change that. I know HOLDLIST is that way but I have been too lazy to open a report for that.