From a multiple selection drilldown from HTML, I get the following error..
(FOC3209) UNKNOWN KEYWORD IN STYLESHEET FILE AT LINE: 6
Stylesheet is..
TYPE=REPORT,
LABEL='VAT',
COLUMN=N1,
FOCEXEC=TBOBJECT1(LINE='VAT' CS='&CS..' BU='&BU..' LG='&LG..' YR=&CCYR \
PD=&PD OUTPUT='&OUTPUT..' TBRT='&TBRT..' CO=' &DRILLCO.. ' \
NUMCOS='&NUMCOS..' IBIC_user='&IBIC_user..'),

error isolated as being &drillco (if &drillco is taken out then the stylesheet 'works')

&drillco contains....
-TYPE DRILLCO= 00221 OR 00229 ;

Stylesheet works if &drillco is enclosed in quotes, but &co in
drilldown then contains double quotes, which WF interprets as...

&CO=%20&00221'%20OR%20'00229'%20%20'=&OUTPUT=HTML&TBRT=Y&NUMCOS=2


therefore first quote mark in &drillco is interpreted as the end quote
for &co variable (and & is default to a phantom next variable)

CATCH 22 !!

Anybody had a similar situation?

Thanks
Hakan

When you pass &variables in a stylesheet they should always be enclosed in single quotes. Otherwise the value of the &var is assumed to be a field name and not a literal. To better see what is happening here put -SET &ECHO=ALL; at the top of you fex, run it again and post the results.

1. Why are there elipses (..) after each quoted &varname (CS='&CS..' BU='&BU..' LG='&LG..')? -- If they are in your fex (rather than artifacts of the Forum software), remove them.

2. I'd remove the spaces surrounding &DRILLCO, although in your context they probably cause no harm.

3. The string
&CO=%20&00221'%20OR%20'00229'%20%20'=&OUTPUT=HTML&TBRT=Y&NUMCOS=2

unescaped, yields
&CO= &00221' OR '00229' '=&OUTPUT= etc

Something ate the leading quote after CO=, and inserted an "&", 3 unexpected quotes, and an "=". I suspect the contents of &DRILLCO. [I presume you meant -DEFAULT rather than -TYPE.] Throw in a
-? &
to ascertain just what the & vars contain at execution.

HTH

Guys, thanks for the input.
I think all of the suggestions have been attempted already.
-? & gives.....
&DRILLCO = '00225' OR '00231'
so, what happens is that (presumably) WF reads the first quote from the stylesheet command and then gets the closing quote as the first char of &DRILLCO
and then inserts a & as default.....
&CO=&00225'%20OR%20'00231'%20'=
Now, if I remove the quote marks from the &drillco value then I get back to the stylesheet error as first mentioned in the post.

[qb]-? & gives.....
&DRILLCO = '00225' OR '00231' [/qb]

Looks like you are placing &DRILLCO (in the drilled-to fex) in a Where clause, such as:

WHERE COMPANYCODE EQ &DRILLCO;

which is supposed to resolve to
WHERE COMPANYCODE EQ '00225' OR '00231' ;

If you omit the quote marks from &DRILLCO's value, and change the Where to an If --

IF COMPANYCODE EQ &DRILLCO (no closing ";"!)

-- it should work as desired.

For IF clauses, when the left-hand item is an alpha field, TABLE will treat the right-hand values as character strings, even w/o quote marks.

I would bail out and have multiple &vars, &DRILLCO1 and &DRILLCO2
I see what you mean by the stylesheet interpreting the doubled quote pairs. Is that where your error is happening? .. long before you even get to the second fex?
You could default some max number of &DRILLCO vars to 'xxx', and write some code in the 2nd fex
WHERE CO EQ &DRILLCO1 OR &DRILLCO2 OR ... etc.
so your filter wouldn't care if &DRILLCO9 was 'xxx'.
Inelegant, but it'll get you home for dinner.
And i second Jack's reminder that the ; at the end of filters is some thing i've begun seeing in people's code and i can't figure out where that comes from! its not a good habit.

Thanks Jack and Susannah, yes, the problem is that we don't get as far as the second fex as the stylesheet fails with the quotes removed. therefore I can't even get to use IF instead of WHERE.
I thought about splitting it up into multi variables, but the user wants to be able to select as many as possible (unless, of course, I enforce a limit).
At the moment, i'm working on a work-around of TABLE'ing off the CO values to a SAVE file and using that file to drive it in the drilled down fex, thus being able to remove the &DRILLCO from the stylesheet - a bit 'inelegant' but enables them to select as many as they want without forcing a selection limit.

i'm imagining that you are using a multi-select dropdown box in your launch fex, and then having to pass thru a bunch of values via your style sheet. if that's what you're doing, it is hairy, but doable.
When you have a multiselect for your variable named &DRILLCO, you generate (focus generates for you) vars named &DRILLCO1 &DRILLCO2... etc. AND you also generate this cool variable &DRILLCO0 (that's a zero at the end) that is an integer, telling you how many of these DRILLCO's your user has selected...
so..
in your style sheet, you interupt your code with some dialogue manager that loops from 1 to &DRILLCO0, writing a line of style sheet code for every loop, passing thru &DRILLCO1...etc
AND (and this is important)
you gotta pass thru &DRILLCO0 as well so you can know how to put this all back together in your receiving fex, how many IF...OR loops you gotta do.
&DRILLCO0 won't exist(i think), if there is no multiselect, so you have to default it to 1.
This is how i do it,anyway, but i try to avoid multiselects any way i can, because its so hard to code the pass thrus.
Your work around sounds interesting...i'm puzzled as to how you are passing a file to a second fex, unless you're filedefing it out of the agent dir and into some semi-permanent server space, which makes it hard for two users to be doing this at the same time..unless you're using some random variable filename...which is starting to make my head hurt.

Hi

Maybe you could try something like this. Use javascript to change the single quotes to something else like the @ symbol. So the value being passed becomes @xxx@ or @yyy@ and then in the next fex replace the @s with single quotes.

Does this help?

Let the launch page pass the selected values as is (not combined into a single string). CGI (the WebFocus Client component) will convert the duplicate parameter names into series form (as Susannah outlined).

Your fexes (original and drilldowns) will expect either a list of values distinguished by numeric suffix and their counter, or a single value. In their drilldowns, to pass the value(s), they should revert to the original form (duplicate parameter names).

Here's the code (untested). I've used "parm" and "field" to keep this general. I indented the generated Focus code, to distinguish it from the DM logic.



-*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-* To generate the screening condition:
WHERE field IN (
-IF &parm0.EXISTS THEN GOTO a.many;
-a.one
'&parm'
-GOTO a.done
-a.many
'&parm1'
-REPEAT a.done FOR &I FROM 2 TO &parm0
,'&parm.&I'
-a.done
);
-*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-* To generate the drilldown focexec arguments:

-IF &parm0.EXISTS THEN GOTO b.many;
-b.one
parm0='1' \
parm1='&parm' \
-GOTO b.done
-b.many
parm0='&parm0' \
parm1='&parm1' \
-REPEAT b.done FOR &I FROM 2 TO &parm0
parm&I='&parm.&I' \
-b.done
-*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Jack.

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

applause!

Susannah: Appreciated.

H�kan: Are you an steady ground now?

Yes nice answer Jack.

I'm assuming that you are using resource layout with the multi-select option. If you implement some of the above suggestions, then you will prevent the gui from opening the report. Also, some of the suggestions will not work! So, I might suggest a slightly less complicated way of handling this.

In the focexec with the drill down, add the following to the top using the "Other" icon:
-SET &OUTFIELD = 'A' | EDIT( &DRILLCO.LENGTH );
-SET &DRILLCO_PASS = CTRAN(&DRILLCO.LENGTH, &DRILLCO, 39, 94, &OUTFIELD.EVAL);

Change all DRILLCO references in the drilldown to DRILLCO_PASS:
PD=&PD OUTPUT='&OUTPUT..' TBRT='&TBRT..' CO_PASS=' &DRILLCO_PASS.. ' \

In the focexec your drilling to, add the following to the top:
-SET &OUTFIELD = 'A' | EDIT( &CO_PASS.LENGTH );
-SET &CO = CTRAN(&CO_PASS.LENGTH, &CO_PASS, 94, 39, &OUTFIELD.EVAL);

What this will do is change the single quotes in the built or expression to "hats". The parm can then be used without affecting the stylesheet. On the receiving report, convert the "hats" back to quotes, thereby allowing to fex to run as designed.

Hope this helps.

BTW, IBI is aware that this is an issue with the layout tool, and expect to have a sollution for it soon.

On behalf of Hakan.....

Thanks everyone for your help and suggestions .
Been away from prob for a couple of days.
Thought I'd try the simplest solution first(DHAGEN)....and this worked.
Although I'd attempted changing the quote using ctran before without success, the combination of forcing the field length must have had the desired effect.

Again, many thanks