Re: XPL: Things executing instead of displaying/printing

[Harry Binswanger hb@xxxxxxxx]

Carl,

Run frames IFEI and SYNTAX against
your code, in addition to giving it 

a thorough eyeballing.


IFEI did find an unmatched IF. It was almost at the very end of the code,
miles away from where the problem showed up. Could that still have been a
problem? SYNTAX didn't like a  nor an . The
underlying hex for the guilemets were AE and AF. I assume that that's
okay.


But IFEI's structured display may have solved the problem. Due to my not
having closed a quote, there was an extra hard return in the middle
here:

=="99">;*;


making it look like this:


=="99">
>;*;


That extra hard return could well account for things
displayed on the CM line executing, and maybe account for other
errors.


You may also have Save/Get clashes.


I doubt that's it, because XyBasic automatically increments S/G for each
new variable.


If you're making calls
to U2 

routines, make sure that your parent routine's S/Gs aren't
overwriting 

the child routine's S/Gs, and vice versa. Run CHKSEQ against any 


routine to identify the S/G sequences (ranges) used in that
routine.


I surround all JM 2 calls thus:


JM 2.HIDE:01-49,51-89Q2

JM 2.[FRAME]Q2

JM 2.UNHIDEQ2


wouldn't that make me safe in this regard?




I
also am sometimes getting ascii 01 in the text.


What you have there is a mismatch in variable types, viz, a value 


saved (SX) as a number but later handled as though it had been
saved 

(SV) as a string.



Not sure if I do that, but I know I do the reverse:



+1>

That does store 4 in 01, but is it not legal?


 For example, run
this against an open file:


GT 


What's written to screen is "9{Ascii-1}" instead of simply
"9"



AHA! That's it. I usually use  to print but with long strings,
since  is (it says) faster, I use it, and right before one of
them there's an  of a number! Is it proper practice to always
use  for integers? Fractions? And then there's no problem with
handling those S/Gs as numbers in subsequent s?


 (Editor 


internally flags numeric expressions by appending {Ascii-1} to the 


value's string representation). The solution is either:


GT  (save string [SV] instead of save
_expression_ [SX])


or


GT > (convert
_expression_ to string)


Yes, I do that sometimes, but maybe not always.




 And,
on occasion, the program stops and the XyWWWEB.INF help screen
appears.


Clearly a coding error of some kind. Can't diagnose further without 


seeing actual code.

You wouldn't want to see it. a) It's way too long (e.g.,
10k) and b) it would curl your hair, make teeth fall out, and set your
armpits on fire.


But you've solved the problems. Thanks everso!


--Harry



Harry Binswanger
hb@xxxxxxxx