I recall concatenating &vars and strings with a '.'
ie. &Prefix.somestring, so if &prefix was 'pre' the the evaluated result would be 'presomestring'.

But I can't seem to find that method in my D.S 7.6.4 documentation. Just stuff like &var.eval, or &var.truncate.

So I wonder if my old method is deprecated, or still supported ?

If it is still 'legal', it would be helpful to me in constructing some path strings. Otherwise I have to create a mess of additional &vars

TIA

This message has been edited. Last edited by: Dave Ayers,

I cannot recall IB deprecating anything in the FOCUS language. Give it a go and see if it still works. I'm sure it is still "leagl" syntax.

As far as I know, the concatenation for anything (strings, &vars, etc.) has always been the | or || symbol. The dot is used for many different things of which . &var.eval and &var.length ar a couple. It is also used for identifying field formats (-READ &VAR.A20.)and prompt strings (WHERE FIELD='&VAR.ENTER A VALUE.;) but I have never seen it used for concatentation.

Of course, sometimes I don't know very "far."

Dave,

I use this technique a lot. It's one of the building blocks of Dialogue Manager so it won't go away (and we'll never have to pay extra for it either!).

You're right - there doesn't appear to be any documentation, though it is indirectly addressed here:

Developing Reporting Applications > Managing Flow of Control in an Application > Customizing a Procedure With Variables > Counting With an Indexed Variable.

I misread Dave's post. &VAR.VARTWO does work but is used for concatenating the value of VARTWO to the &VAR variable name, not actual value concatenation of both variables. TWO dots .. will concate to values.

-SET &VAR = PRE;
-SET &VARTWO = 1;
-SET &VAR1 = THREE;

-TYPE &VAR.&VARTWO

-TYPE &VAR..&VARTWO

&VAR.&VARTWO yields &VAR1 which yields THREE as a value.

&VAR..&VARTWO yields PRE1 as a value.

Thanks all !

I tried it out, and while it does still work, there is a caveat that prevents its use for this application.

I wanted to create dynamic paths specs for a USE list, like

&APPROOT.\myapp\car.foc AS CAR

BUT that evaluates to 'c:\ibi\appsfoc'

So, if DM encounters another '.' it truncates the string

Still, a useful technique, but not for everything, and not for what I wanted in this case.

In this case, use .EVAL:

USE 
&APPROOT.EVAL\myapp\car.foc AS CAR
END

... or the double dot as Mickey suggested above -

USE 
&APPROOT..\myapp\car.foc AS CAR
END

T

Yup, the double-dot will do it.

This seems to be the rulebook for the two delimiters, ".." and "|" recognized by dialog manager:

When dialog manager is composing a string (in any Focus statement, or in a -TYPE directive) ".." acts as a delimiter, if it immediately follows an amper variable reference. The delimiter gets eaten: The variable-name and its trailing delimiter are replaced by the variable's current value.

When dialog manager is evaluating an expression (as in a -SET or -IF directive), ".." does not function as a delimiter.



By contrast, "|" immediately following a &var reference always acts as a delimiter, in either context. For example,

-SET &Z3=&Z1|||&Z2;
-SET &Z4=&Z1||&Z2;

is equivalent to

-SET &Z3=&Z1 || &Z2;
-SET &Z4=&Z1 | &Z2;

-- a vertical abutting &Z1 gets eaten, and the remaining one or two verticals represent soft or hard catenation. Since the vertical touching the &var disappears, it is not counted toward the catenation operator, so || in the first code yields soft catenation (rather then hard) and ||| yields hard (rather than a syntax error).

In either context, once you insert a space after the &var, the vertical reverts to its normal dialog manager significance (as an operator in expressions, and as a literal [no special significance to dialog manager] when forming a string.

Of course, when a line of Focus code preprocessed by d.m. finally gets read from focstack and processed as Focus code, the vertical may have significance as an operator; but that's a different stage of the game.

Ah, great. The two delimiters '..' did the job just fine. And no ugly workarounds !

That's probably why I didn't remember it well, having used a single '.' in the past, which worked sometimes, but not all.

I hope I remember it the next time I need it, but the old memory isn't what it used to be...

But, now we have this nice little thread here, that I can find when memory fails