Hi all,

right i just need to check on how things are processed when the WF code is parsed...

what im trying to do is reference a variable (call it varI) in another variable (call it varII)....

the varI value gets passed by the preceeding FEX....

i want the -set &dummy command to read the value of the passed variable-

 SET &DUMMY = &TABLE2.(FIND field IN &varI).Enter Table 2.; 

now this doesn't work- i suspect it's due to the order in which things are processed but just need to get the official word- i can't seem to find in the documentation (i have) anything about how the elements of the code are parsed- so just point me in the right direction if i've missed it...

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

For a Dialogue Manager variable, you need to say -SET not just SET.

As for parsing, see this:

https://forums.informationbuilders.com/eve/forums/a/tpc/...131009592#1131009592

That post does not include the Dialogue Manager stuff which always happens first unless there is a -RUN to flush and execute FOCSTACK.

Hope this helps.

View it as as each line is encountered until a '-run' is seen. It's an interpretive language for the most part, this is why when you fix one error in code, the next error appears. I would also recommend you fully parenthesis any selection statements.

Ginny,

Thanks for the info

Leah,

Well this is it, the way i have my code i declare the first variable with a run at the end before declaring the one that references the first:

 -SET &DB = 'string';
-SET &TABSTRING= '_tables';
-SET &SOURCE= &DB || &TABSTRING;
-RUN

-SET &DUMMY = &TABLE1.(FIND FILENAME IN &SOURCE).; 

so it seems to process all the -set commands at the same time as the second element doesn't find any fields

You don't need a -RUN there; you have nothing in FOCSTACK.

I would verify that you can do that FIND syntax in Dialogue Manager. That is where your problem is.

WM,

Where did you get the find syntax you are using? It was driving me crazy so I looked around and the only thing I've found is a FIND subroutine but it is only valid in Modify and Maintain. There is a new DB_LOOKUP function but I think it can only be used in a TABLE request.

Maybe you should tell us what you are trying to do.

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

quote:

I would verify that you can do that FIND syntax in Dialogue Manager. That is where your problem is.

Ditto. FIND is part of TABLE syntax as it requires lookup in the data. Dialogue Manager does not handle any of that. All &vars needs to be previously resolved with -READ, -SET, -DEFAULT, or as input parameters.

Indeed, it all hinges on "Order of Parsing".

-SET &DB = 'string';
-SET &TABSTRING= '_tables';
-SET &SOURCE= &DB || &TABSTRING;

-SET &DUMMY = &TABLE1.(FIND FILENAME IN &SOURCE).; 

First off, this use of FIND is valid Focus syntax (almost) to trigger an autoprompt for the &var. (It's just hard to FIND it in a Tech Support search. ) The prompt stuff should be appended to the first reference to the &var, whether in a Focus command or a dialog manager command (e.g. the RHS of a -SET).

For example, run this:

-SET &ECHO=ON;
-SET &COUNTRY2=&COUNTRY.(FIND COUNTRY IN CAR).WHICH COUNTRY?.;
*********** &CAR.(FIND CAR IN CAR).WHICH CAR?.
-? &C
TABLE FILE CAR
WRITE SEATS BY COUNTRY BY CAR BY MODEL
WHERE (COUNTRY EQ '&COUNTRY2') OR (CAR EQ '&CAR');
END

The prompt for &COUNTRY appears in a DM command (-SET), and that for &CAR in a Focus command. /* Note: "*********** ..." is a valid Focus command (any line starting with "*" is a comment, when Focus is looking for a Focus command) */

Unless autoprompt is suppressed, this code will prompt for &COUNTRY and &CAR, and then will run from the top (this time with &CAR and &COUNTRY pre-SET, so no autoprompt is triggered) and will process the TABLE command after dialog manager performs the substitutions for the referenced &vars.

The echo from the second phase (I selected ENGLAND and ALFA ROMEO) is:

  
  CURRENTLY DEFINED & VARIABLES STARTING WITH 'C':
  &CAR          = ALFA ROMEO
  &CHNGD        =        0
  &COUNTRY      = ENGLAND
  &COUNTRY2     = ENGLAND
  TABLE FILE CAR
  WRITE SEATS BY COUNTRY BY CAR BY MODEL
  WHERE (COUNTRY EQ 'ENGLAND') OR (CAR EQ 'ALFA ROMEO');
  END
0 NUMBER OF RECORDS IN TABLE=        7  LINES=      7  (4 models of various cars under ENGLAND, and 3 ALPHA ROMEO models under ITALY)

(Note that -SET &COUNTRY2=&COUNTRY; sets &COUNTRY to 'ENGLAND', based on my selection for &COUNTRY)


As I noted, the filename after IN must be hard-coded.

Reason: the AUTOPROMPT pre-scan (to determine whether and how to issue an autoprompt screen) does not execute the -SET statements, it only does a static analysis, and will not (cannot) insert a value ("string_tables") in place of the &var reference (&SOURCE). Even .EVAL will not help here -- the filename after IN must be hard-coded.

As coded in nubi's post using &SOURCE, it does trigger an autoprompt -- but with an empty SELECT list, essentially because there is no master for '&SOURCE'.

Is it clear now?

This message has been edited. Last edited by: j.gross,

Clear to me. Thanks, Jack.

My only 'plaint is that, in a case like this, since there is nothing to SELECT, the autoprompt page's return call does not set the &variable, and you go right back to the autoprompt, endless-loopily.

If the autoprompt would send WFDESCRIBE=OFF on the return trip, at least you'd get a decent "variable not defined" error termination.

excellent info guys, will start working through it.

firstly find does work if its hardcoded- ie if references an existing data source (which i believe must be a focus or flat flie)- and Ginny i didn't get it from a manual i copeid it from an existing report we have here - ultimatley i want to learn this in Javascript as thats our preferred method of populating dropdowns and stuff but the WF method works just as well in some instances...

ive only ever used a reference to an existing data source when doing a 'FIND IN' statement but due to the fleixble nature of WF i thought i'd try referecing a variable instead- purely because it works so effectively elsewhere - other parts of my statement uses variables to write the TABLE request

my end result was basically a collection of three drop down downs- each referencing the same set of tables but i wanted to choose the set on the fly- to get round the parsing ive had to do it in two passes but was finding that the 'FIND' still wouldn't work yet would work if i hardcoded it...

so the problem does lie in how the variables are being read/written... the preceding fex sends the variable value i want so before the code runs it already has a value for the variable i then reference- but for some reason it doesn't recognise that value, if i replace the variable with a string of its value and it works....

I haven't worked through JG's post yet so ill be back but hopefully it explains my thinking

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

Nubi --

Autoprompt is a convenience for simple, static parameter-prompt requirements. For anything beyond that, I suggest you create a launch page for gathering your parameter values.

O whole-heartedly agree with Jack's last post. It seems that MANY people spend so much time trying to get things exactly right so autoprompting will work like they want and there's still always something that they would like it to do a little different/better. I found it to be not consistent enough for anything complex and have completely abandoned it for anything except the simplest input (basically ONLY text input boxes.) It is so easy to create a launch page that can do everything EXACTLY the way you want it and looks MUCH nicer with a common look and feel along with Javascript functionality. (Oh, and then there's the HTML painter as well )

im currently learning JavaScript so im really just finding out what and how i should do things- its become clear that really i need a dedicated html launch page but i needed to exhaust the WF options first as im also trying to learn WF

thanks again guys... as always- great forum!!

quote:

looks MUCH nicer with a common look and feel

which often helps end users feel happier in using an end product as well.

My current Client is heavily into Autoprompting and I have supplied them with a modular copy (almost exact) of the autoprompt result. The end users know no difference when they use the genuine article or my alternative as it even uses the autoprompt css and some of the JS etc. One further advantage is that you can add control chaining etc.

T