Re: Concatenating A Lone Ascii-13

[Robert Holmgren]

 JS >Robert: I think this is impossible, but ...
 JS >I'm trying to concatenate 3 lines of text from an existing
 JS >A-Z Save/Get into a string that will act like a block of
 JS >text defined with DC [DefineColumn] functions...
 JS >Please let me know what you think.

Joe: I've been travelling. I just saw your problem. (Took me a while to
figure out what you want to do. Why do you say "DC function_s_" -- is there
more than one DC DefineColumn?)

I think you're barking up the wrong tree. Ascii-13 has nothing to do with
your inability to modify the DefinedColumn block that you stored to a Save/Get.
Rather, the key to this problem lies in the *type* of Save/Get you create when
you use function DC. This is an undocumented aspect of XyWrite, but, in a
nutshell, it goes something like this:

When a Save/Get is created, it acquires a numeric *type* value. You can
determine this value using the undocumented command , , etc.,
where the alphanumeric following "!" is any Save/Get, such as "A",
"01",
whatever. In general, you poll S/G "type" info thus:

 string literal > S/G02 = 0
 SUbroutine   > S/G02 = 2
 numeric value > S/G02 = 4
 uninitialized S/G       > S/G02 = 255
 (in the final example above, S/G 01 isn't set, i.e. isn't initialized)

 There are some very esoteric applications of this VA! capability which might
actually be useful (believe it or not). For example, in the statement:
  
 S/G01 acquires no value whatsoever. That's an unexpected contrast to
 where of course the value of S/G01 is zero.
(Practically speaking, the only way you use the "{240}" unary operator is in
 type conditional statements.) However, you could test {240}
for validity using the  command, thus:
  > S/G02=24=TRUE
  > S/G02=16=FALSE
 Only thing is, I can't figure out why any user would want to do this, because
the direct {238} route is easier:
          S/G01= 0=TRUE
          S/G01=-1=FALSE

 Returning to your original problem: If we simply use DF (or any of the
ordinary Define functions like DW, DS, or DP), the VA! value of the S/G that
stores the block is 0. Why? Because the block is just another string literal.
There's nothing special about it. And if we concatenate it with another string
literal, the result string is still a literal. But if we use function DC, the
VA! value is **1**. And of course, a DC block *is* very special and very
different than anything else. As far as I know, VA!=1 is unique to DC.

 One last wrinkle. Consider this:
 numeric value > S/G02 = 4
 concatenation +"9">>...
                     ... S/G02 = 0

 The analogy suggests that if we take a DC block (VA!=1) and concatenate
something with it, we're gonna get a string literal (VA!=0). And we do. When
a Save/Get loses its VA!=1 value, it loses all the characteristics and
capabilities associated with DC, and becomes just another string literal.

 Note that TTG was either sloppy or simply didn't care about the thorough
translation of func DC from Xy3+ to Sig|Xy4. Whereas with any other type of
defined block you can write:
  DF ... DF XD ...
 with DC that doesn't work. In fact, I don't know of any way to directly save
a DefinedColumn to an extended numeric Save/Get 01-1999. You MUST use the
single-character alphanumerics 0-9|A-Z. Moreover, this doesn't work either:
  DC ... DC XD ...
 You MUST use the archaic function SV, thus:
  DC ... DC SV aXD ...
 It's ridiculous.

 Soooo... the bottom line is.... you're right, XPL concatenation of DC blocks
stored in Save/Gets cannot be done. H