Good day,

I'm trying to create a fairly simple report template to use with new reports. The code is this:

TABLE FILE %s
	PRINT *
-INCLUDE General/GEN00005_rtvFooting.fex
ENDSTYLE
END

This file is set as Default Report Template in Dev Studio.

This doesn't work however; the include is left out altogether (not interpreted and not copied in the report), causing the ENDSTYLE to end up as a column name after PRINT *, after which Dev Studio stubbornly paints its own code (that we don't want) in between.

What we get is this:

TABLE FILE CAR
PRINT 
     'CAR.ORIGIN.COUNTRY'
     'CAR.COMP.CAR'
     'CAR.CARREC.MODEL'
     'CAR.WARANT.WARRANTY'
     'CAR.EQUIP.STANDARD'
     'CAR.BODY.BODYTYPE'
     'CAR.BODY.SEATS'
     'CAR.BODY.DEALER_COST'
     'CAR.BODY.RETAIL_COST'
     'CAR.BODY.SALES'
     'CAR.SPECS.LENGTH'
     'CAR.SPECS.WIDTH'
     'CAR.SPECS.HEIGHT'
     'CAR.SPECS.WEIGHT'
     'CAR.SPECS.WHEELBASE'
     'CAR.SPECS.FUEL_CAP'
     'CAR.SPECS.BHP'
     'CAR.SPECS.RPM'
     'CAR.SPECS.MPG'
     'CAR.SPECS.ACCEL'
     ENDSTYLE
ON TABLE SET PAGE-NUM OFF 
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT HTML
ON TABLE SET HTMLCSS ON
ON TABLE SET STYLE *
     UNITS=CM,
     SQUEEZE=ON,
     ORIENTATION=LANDSCAPE,
$
TYPE=REPORT,
     GRID=OFF,
     FONT='TIMES NEW ROMAN',
     SIZE=10,
     CLASS=WFreport,
$
TYPE=DATA,
     BACKCOLOR=( RGB(221 221 221) RGB(231 231 231) ),
     CLASS=DATA,
$
ENDSTYLE
END

As you can see, the include is gone and the ENDSTYLE tag ended up at the bottom of the PRINT-list. Also, Dev Studio inserted a lot of styling that we don't want (FONT='TIMES NEW ROMAN', for example).

So, my questions are:

• Is there some way to make Dev Studio keep the -INCLUDE line? It should just copy it verbatim into the report.
  
• Is there some way to stop Dev Studio from using "it's own template"?
  

I guess our only solution is to create a template fex that people use before creating reports, but that would cause some trouble when people put multiple tables in a report, for example.

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

TABLE FILE CAR
PRINT COUNTRY CAR MODEL
ON TABLE SET STYLE *
INCLUDE=stylefile.sty,$
ENDSTYLE
END

Note, included file is .sty not .fex.

quote:

Originally posted by dbeagan:
TABLE FILE CAR
PRINT COUNTRY CAR MODEL
ON TABLE SET STYLE *
INCLUDE=stylefile.sty,$
ENDSTYLE
END

Note, included file is .sty not .fex.

You can't execute DM-code in sty-files, so that's not a solution for us.

One of the things the included file contains is a reference to a .sty file. It also contains a standard FOOTING and code to format all the basics to ease creating a report in our standard style. It's not just styling, a sty-file just can't handle everything that our include does.

I guess the Default Report Template just won't cut it for us then?

Yea, INCLUDE=stylefile is only good as far as it goes.

I did try this (WF 7.7.01):

 
TABLE FILE CAR
PRINT *
-INCLUDE style2
ENDSTYLE
END

Report painter turned it into this:

 
TABLE FILE CAR
PRINT 
     COUNTRY
     CAR
...
     WARRANTY
     STANDARD
ON TABLE SET PAGE-NUM OFF 
ON TABLE NOTOTAL
ON TABLE PCHOLD FORMAT HTML
ON TABLE SET HTMLCSS ON
ON TABLE SET STYLE *
     UNITS=CM,
     SQUEEZE=ON,
     ORIENTATION=LANDSCAPE,
$
TYPE=REPORT,
     GRID=OFF,
     FONT='ARIAL',
     SIZE=10,
     CLASS=WFreport,
$
TYPE=DATA,
     BACKCOLOR=( RGB(221 221 221) RGB(231 231 231) ),
     CLASS=DATA,
$
ENDSTYLE
END
 

No extra ENDSTYLE and no FONT='TIMES NEW ROMAN'. Does it work for you? Is it closer to your objective?

quote:

Originally posted by dbeagan:
Yea, INCLUDE=stylefile is only good as far as it goes.

I did try this (WF 7.7.01):

 
TABLE FILE CAR
PRINT *
-INCLUDE style2
ENDSTYLE
END

...

No extra ENDSTYLE and no FONT='TIMES NEW ROMAN'. Does it work for you? Is it closer to your objective?

Except for the difference in versions, how is this different from what I'm doing? Is it just leaving out the .fex extension? I don't understand what the difference is between what I do and what you do, could you elaborate a little?

Well, what do you know? Leaving out the application and extension changes the behaviour in such a way that it now at least attempts to include the specified procedure.

Trouble is, it now bails on the DM code in the include.
The first DM command it fails on is a -SET that preserves the old value of &ECHO - namely:

-SET &OLDECHO = &ECHO.EVAL;

There's plenty more DM code in that file though - I guess the Report Editor won't be able to parse that properly. And it should parse it, as the file defines large parts of the styling, but also different FOOTING templates and some properties that depend on the output format used (HTML, PDF, EXL2K).
It can't parse the report after I copy & paste the code from the ftp-file in the procedure either...
I guess I outsmarted the system.

Some good news, but first the back ground:
The difficulty you have stumbled into is that DM is a run time code Generator. It uses execution time variable values to generate code for the execution engine. The report painter is trying to parse your code and change the code - without knowing what the execution values are.
Think of this simple case.

-IF &USERTYPE EQ AAA GOTO -AAALIST
PRINT FLD1 FLD2 FLD3
-GOTO -OPTS
-AAALIST
PRINT FLD4 FLD5 FLD6
-OPTS

How should a GUI code modifier parse this. When in the painter, when you add a field to the report, where should it go?

Now the good news is that the 7702 painter is much more &VAR aware. There are lots of places where it will let you place an &VAR. Better yet, it can build a &VAR laden table request for you in what we have termed "guided adhoc mode" without having to use the TEXT editor. In this mode you build fexs and HTML request screens where the end user can pick his sort fields, measures, format options, page brakes, etc. This used to require handcoding in syntax. Now the GUI can do it for you.

quote:

Originally posted by Brian Suter:
Some good news, but first the back ground:
The difficulty you have stumbled into is that DM is a run time code Generator. It uses execution time variable values to generate code for the execution engine. The report painter is trying to parse your code and change the code - without knowing what the execution values are.

I feared as much. I kind of expected that the code generator would have been called before sending the report to the report painter. Wouldn't that make sense? There's probably some obvious reason it doesn't...

quote:

Originally posted by Brian Suter:
Now the good news is that the 7702 painter is much more &VAR aware. There are lots of places where it will let you place an &VAR. Better yet, it can build a &VAR laden table request for you in what we have termed "guided adhoc mode" without having to use the TEXT editor. In this mode you build fexs and HTML request screens where the end user can pick his sort fields, measures, format options, page brakes, etc. This used to require handcoding in syntax. Now the GUI can do it for you.

That certainly is an improvement, but I don't suppose it can also handle conditionals and such?

Basically I have "improved" our standard templates so much that you can specify a few standard options, like the output format (HTML, PDF, EXL2K), and it will apply all the formatting for our formatting standards, adding a standardised FOOTING block, including the right .sty file for the output format and a CSS-file if applicable.

The exception to that automation is when you override styles to include drilldowns and such of course, as the style engine apparently doesn't merge style definitions :/