Help me out here...

Check this code:
################################################
-PROMPT &USELIMIT.( <NO>,<YES> ).Use limit?.;
-PROMPT &LIMIT.Type value(s).;

-SET &LIMIT = IF '&USELIMIT' EQ 'NO' THEN 'FOC_NONE' ELSE &LIMIT;

-TYPE &USELIMIT
-TYPE &LIMIT
#################################################

Run:
Auto-amper prompts:
"Use limit?" : choose : NO
"Type value(s)" : type : hello

output ( with display dm commands )
################################################
-PROMPT &USELIMIT.( <NO>,<YES> ).Use limit?.;
-PROMPT &LIMIT.Type value(s).;
-SET &LIMIT = IF 'NO' EQ 'NO' THEN 'FOC_NONE' ELSE hello;
-TYPE NO
NO
-TYPE hello
hello
################################################

IF 'NO' EQ 'NO' didn't SET &LIMIT to FOC_NONE??
'NO' is not eq to 'NO' ????

Now change the -SET line to: ( remove ' around &USELIMIT )
-SET &LIMIT = IF &USELIMIT EQ 'NO' THEN 'FOC_NONE' ELSE &LIMIT;

then it works like a charm.
output ( with display dm commands )
################################################
-PROMPT &USELIMIT.( <NO>,<YES> ).Use limit?.;
-PROMPT &LIMIT.Type value(s).;
-SET &LIMIT = IF NO EQ 'NO' THEN 'FOC_NONE' ELSE hello;
-TYPE NO
NO
-TYPE FOC_NONE
FOC_NONE
################################################

NO is eq to 'NO' ????

is this even allowed?? shouldn't the NO have quotes? it's a string! isn't it?
################################################

Now change the -SET line to: ( remove ' around NO )
-SET &LIMIT = IF &USELIMIT EQ NO THEN 'FOC_NONE' ELSE &LIMIT;

this also works...
NO is eq to NO

But this does give me the creeps ... using strings without ' can't be good...


Problem is, I'm missing the logic here. Especially: Why doesn't my orginal code work?
Why is 'NO' EQ 'NO' false?

any clues?

Greets,Dave

[ updated : replaced < and > with proper html-code to make it visible ]

Try using .EVAL with your DM variable enclosed in quotes:

-PROMPT &USELIMIT.( <NO>,<YES> ).Use limit?.;
-PROMPT &LIMIT.Type value(s).;
-SET &LIMIT = IF '&USELIMIT.EVAL' EQ 'NO' THEN 'FOC_NONE' ELSE &LIMIT;
-TYPE &USELIMIT
-TYPE &LIMIT

This message has been edited. Last edited by: Dan Satchell,

Dan,

I've added that as first line of the code...
It's doesn't show any extra info in the output..

Dave,

After placing my first post about -SET &ECHO=ALL;, I went and actually tested the code. I have since changed my earlier post to suggest using .EVAL.

This has always been a bit confusing to me because WF seems to process DM variables differently depending on whether they are used in DM statements or TABLE/MODIFY statements. I think what happens is the code is evaluated twice. The first pass looks for and processes DM statements (which begin with a dash). During the first pass, anything inside quotes apparently is left as is. For example, your statement is probably processed as "IF &USELIMIT EQ NO THEN FOC_NONE ELSE hello" (which evaluates to false). The second pass looks for and processes TABLE/MODIFY statements, AND evaluates any remaining unresolved variables. During the second pass, &USERLIMIT is changed to 'NO' (or 'YES') and your statement becomes "IF NO EQ NO THEN FOC_NONE ELSE hello". But since DM statements are evaluated during the first pass only, this correct statement is not evaluated during the second pass. By placing .EVAL after a variable, you force the variable to be evaluated during the first pass, even when inside quotes.

But if you use a text variable within TABLE/MODIFY, you MUST enclose it in quotes. For example, if you attempted the code below, you would receive an error message - probably about field XYZ not existing. But if you put quotes around &TESTVAL in the DEFINE, it works fine.

-SET &TESTVAL = 'XYZ';
-*
DEFINE FILE X
 TESTX/I1 = IF <text field> EQ &TESTVAL THEN 1 ELSE 0;
END

This message has been edited. Last edited by: Dan Satchell,

Dan is correct. DM is interpretive, however the output from &ECHO comes after the result has been processed through FOCSTACK. Therefore what is seen is what FOCSTACK sees, not what DM sees.

&LIMIT has to be used as a variable NOT a value within DM. Would you ever use WHERE 'COUNTRY' EQ 'ENGLAND' in a TABLE request?

Values are contained in single quotes, variables / fields are not.

mmm. ( there is not smiley available to match my current facial expression... )

Let me try to get this...

( I get the sample with the define. With or without quotes and what the difference is. I've bumped into the wall often enough. )

All my samplecode starts with a dash... so should all be done in one pass.
The fact the quoted stuff doesn't get interpretated does indeed explain why
-SET &LIMIT = IF &USELIMIT EQ NO THEN 'FOC_NONE' ELSE &LIMIT;
Also works...

But I guess the -SET &LIMIT is also -not- interpreted..
otherwise it ends up like:

-SET hello = IF ... ...

#############
So after the first pass it should be:

-SET &LIMIT = IF '&USELIMIT' EQ 'NO' THEN 'FOC_NONE' ELSE hello;

-TYPE NO
-TYPE hello

Which does explain the output 'no' and 'hello' since this is done by the first pass.
#############
And after the second pass it should be:

-SET &LIMIT = IF 'NO' EQ 'NO' THEN 'FOC_NONE' ELSE hello;

-TYPE NO
-TYPE hello

This -should- SET &LIMIT to 'FOC_NONE' ? which it doesn't...



Here is a full example of my procedure ( simplified and on 'CAR' ):
-* ----------------------------------------------------------------
-PROMPT &USELIMIT.( <NO>,<YES> ).Use limit?.;
-PROMPT &LIMIT.Number of seats(s).;

-SET &LIMIT = IF '&USELIMIT' EQ 'NO' THEN 'FOC_NONE' ELSE &LIMIT;

-TYPE &USELIMIT
-TYPE &LIMIT

TABLE FILE CAR
PRINT CAR SEATS
WHERE SEATS IN ( &LIMIT )
ON TABLE PCHOLD FORMAT HTML
END
-* ----------------------------------------------------------------

Which works if I add .EVAL to '&USELIMIT', but I don't see why it needs it.

( All: Thanks a lot so far ! )

quote:

Which works if I add .EVAL to '&USELIMIT', but I don't see why it needs it

It doesn't.
The code actually should be:

-PROMPT &USELIMIT.( <NO>,<YES> ).Use limit?.;
-PROMPT &LIMIT.Number of seats(s).;

-SET &LIMIT = IF &USELIMIT EQ 'NO' THEN 'FOC_NONE' ELSE &LIMIT;

-TYPE &USELIMIT
-TYPE &LIMIT

TABLE FILE CAR
PRINT CAR SEATS
WHERE SEATS IN ( &LIMIT )
ON TABLE PCHOLD FORMAT HTML
END

So without the quotes around the &uselimit, but with quotes around NO.
Explanation: &USELIMIT is a variable, 'NO' is a constant string.
The -SET &LIMIT does not get evaluated because it is on the left side of the equation. If you want an expression or variable on the left side to be evaluated before the statement gets executed, you have to use .EVAL. Same with strings that includes variable content (as with the '&USELIMIT' which is just that - a constant but with variable content) - if you want this variable content to be evaluated before it is executed, use .EVAL.

That does make sense...


The only strange thing then actually is when using "run + display DM commands" is shows:
-SET &LIMIT = IF NO EQ 'NO' THEN 'FOC_NONE' ELSE hello;

Which is, since &USELIMIT = 'NO', not actually correct. It should be:

-SET &LIMIT = IF 'NO' EQ 'NO' THEN 'FOC_NONE' ELSE hello;

Is this a bug in the 'display dialog manager commands' option?

Thanks all.

Actually it is correct and not a bug.
If you look at it this way:
- all dm stuff (at the right hand side of the = sign or with .EVAL) gets shown in a translated form, that does not mean it is executed as it is shown.
- It shows you exactly what's in the variable. And there are no quotes in the variable, so it does not show them.
- Display DM Commands is meant as aid for debugging in case of errors. And in that light it is quite nice to have all variables shown in a translated form.

well yes,

but I look at it as it's shown... ...and if

NO EQ 'NO' = true
and
'NO' EQ 'NO' = false

it's at least a bit confusing ;-)

Thanks,
Groeten uit brabant.
( greets from brabant )

Dave, I'm with you. I'd prefer to see the code as executed, and not some variation thereof when ECHOing the execution. This would make debugging much easier. And regardless of the variable vs. string theory, it is still confusing when DM requires

IF &VAR1 EQ &VAR2 THEN...

to compare the string in &VAR1 to the string in &VAR2, but DEFINES and COMPUTES require

IF '&VAR1' EQ '&VAR2' THEN...

to make the same comparison. If you put a variable in quotes in a DM statement, it evaluates to the variable name. If you put a variable in quotes in a DEFINE/COMPUTE it evaluates to the value inside the variable. Like any language, eventually you get used to the idiosyncracies. But it is certainly confusing until you get past the "WHAT?!!".

If you understand the model, the confusion disappears.

Fex code is parsed in two phases, by processors that "understand" different languages.

- The Dialog Manager pre-processor (phase 1) has no knowledge of the Focus reporting language (other than the ability to distinguish DM directive from lines of Focus code, based on the presence or absence of the leading dash).

- The Focus language processor (phase two, operating on the lines placed in FOCSTACK by phase one) understands Focus syntax and knows nothing of Dialog Manager's language. (For example, it treats "&", if you manage to get it into FOCSTACK, as just another character)

In the DEFINE statement

[1]  FIELD3/A4 = IF (FIELD1 EQ FIELD2) THEN 'SAME' ELSE 'DIFF';

there are no variables from the DM point of view; whereas in the analogous DM statement

[2]  -SET &PARAM3= IF (&PARAM1 EQ &PARAM2) THEN 'SAME' ELSE 'DIFF';

there are three references to DM variables.

The DM parser would append [1] as-is to FOCSTACK (where the second phase would apply it to each incoming recode); whereas [2] is interpreted by DM and executed immediately (not placed in FOCSTACK).

When DM encounters

[3]  FIELD3/A4 = IF (FIELD1 EQ &PARAM2) THEN 'a' ELSE 'b';

it recognizes that this is a Focus statement (no leading "-"), containg a reference to a DM variable, so it substitutes the variable's value and places the resuling string, say

[3*] FIELD3/A4 = IF (FIELD1 EQ foo) THEN 'a' ELSE 'b';

into FOCSTACK. In the second phase (triggered by -RUN, -EXIT, or end-of-fex), the Focus interpreter sees the line, and based on Focus syntax deems "foo" to be a reference to a Focus variable. (It has no clue that "foo" originated as a DM variable -- at this point it's just three consecutive letters.)

If you need to compare Focus variable FIELD1 to an alpha value contained in DM variable &PARAM2, you need to code

[4]  FIELD3/A4 = IF (FIELD1 EQ '&PARAM2') THEN 'a' ELSE 'b';

which the DM pre-processor will change to (say)

[4*] FIELD3/A4 = IF (FIELD1 EQ 'foo') THEN 'a' ELSE 'b';

and the the Focus code processor in turn will understand as involving the intended comparison of FIELD1 (for each incoming record) to the constant 'foo'.

On the other hand, if FIELD1 is numeric, and &PARAM2 contains a string representing a number, you would omit the quotes around &PARAM2:

[5]  FIELD3/A4 = IF (FIELD1 EQ &PARAM2) THEN 'a' ELSE 'b';

[5*] FIELD3/A4 = IF (FIELD1 EQ 123) THEN 'a' ELSE 'b';

So, in a Focus statement, whether or not to enclode a DM variable in quotes depends on both the value it contains, and the Focus syntax requirements for the statement after that substitution has taken place.

Jack,

If I understand your explanation correctly, when the Dialogue Manager processor encounters a DEFINE, like this:

FIELDY/Ax = IF FIELDX EQ '&VAR' THEN ... ELSE ... ;

it replaces &VAR with the value of &VAR and places the line in the FOCSTACK.


But if the DM processor encounters a DM statement, like this:

-SET &VAR2 = IF &VAR1 EQ '&VAR' THEN ... ELSE ... ;

it executes the line immediately, and makes no substitution for &VAR before doing so.

To me, that seems inconsistent. The DM processor seems to be treating variables differently, depending on whether they appear in a DM statement or a FOCUS language statement.

Finally, to further confuse the issue, if the user sets &ECHO=ALL before running the above statements, both will appear in the ECHO output with &VAR fully substituted.

No.
In a DM statement such as yours

-SET &VAR2 = IF &VAR1 EQ '&VAR' THEN ... ELSE ... ;

the Dialog Manager syntax rules for a -SET command call for substitution on &VAR1, but not on &VAR (because its reference is within a quote-delimited dialog manager character literal).

-- whereas in a Focus statement

FIELD3/A4 = IF (FIELD1 EQ '&PARAM2') THEN 'a' ELSE 'b';

it treats the quote characters as nothing special (remember, it knows naught of Focus statement syntax), and performs substitution on the reference to &PARAM2.

Jack,

Thanks, I finally got it. The DM processor may be able to recognize a single quote in a DM statement, but if a line doesn't start with a dash, it knows absolutely nothing - except how to recognize and substitute DM variables.

Nearly so. One detail of Focus syntax that DM takes into consideration, at least last time I looked: DM does not stack blank lines appearing in the fex. That's apparently based on an assumption that such lines make no difference in Focus. But sometimes they do matter: e.g., in the DATA stream of a Modify, or within the scope of "EX -LINES ..." (the line-count must match the number of lines following)

A work-around, if you ever need it, is to include in the "blank" line a reference to a DM variable whose value has been set to ' '. *After substitution* the line will be blank, but DM will stack it anyway. For example,

-SET &Nada=' ';
MODIFY ...
FIXFORM CODE/1 
 .
 .
 .
DATA
&Nada
A
B
C
END

will feed four transaction records to the FIXFORM, setting CODE to blank, then A, B and finally C. If the line after DATA were simply blank, only three records (A,B,C) would be read by the Modify

quote:

Originally posted by j.gross:
No.
In a DM statement such as yours

-SET &VAR2 = IF &VAR1 EQ '&VAR' THEN ... ELSE ... ;

the Dialog Manager syntax rules for a -SET command call for substitution on &VAR1, but not on &VAR (because its reference is within a quote-delimited dialog manager character literal).

-- whereas in a Focus statement

FIELD3/A4 = IF (FIELD1 EQ '&PARAM2') THEN 'a' ELSE 'b';

it treats the quote characters as nothing special (remember, it knows naught of Focus statement syntax), and performs substitution on the reference to &PARAM2.

Jack, I thought I followed what you said in the previous post, but confused all over again.

Here is the little example I ran, and all the amper variables are substituded everywhere, quoted or unquoted, by the DM processor at the SAME TIME(is it?), before field COUNTRY gets populated from CAR file.

-SET &ECHO=ALL;
-SET &PARM1 = IF &PARM2 EQ '&PARM3' THEN 'A' ELSE 'B';
DEFINE FILE CAR
FIELD1/A10 = IF COUNTRY EQ '&PARM5' THEN 'X' ELSE 'Y';
END
TABLE FILE CAR
PRINT 
     COUNTRY
     FIELD1
     FIELD2
HEADING
"&PARM1 "
"&PARM2 "
"&PARM3 "
"&PARM5 "
WHERE '&PARM2' EQ &PARM3;
END
  

values supplied at run-time: &PARM2 = YES, &PARM3 = yes, &PARM5 = ENGLAND

-SET &PARM1 = IF YES EQ 'yes' THEN 'A' ELSE 'B';
 DEFINE FILE CAR
 FIELD1/A10 = IF COUNTRY EQ 'ENGLAND' THEN 'X' ELSE 'Y';
 END
 TABLE FILE CAR
 PRINT
 COUNTRY
 FIELD1
 FIELD2
 HEADING
 "B "
 "YES "
 "yes "
 "ENGLAND "
 WHERE 'YES' EQ yes;
 END
 0 ERROR AT OR NEAR LINE     10  IN PROCEDURE ADHOCRQ FOCEXEC *
 (FOC003) THE FIELDNAME IS NOT RECOGNIZED: FIELD2
 BYPASSING TO END OF COMMAND
 (FOC009) INCOMPLETE REQUEST STATEMENT

  

Hua

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