TH> Perhaps you jumped in this thread late. I only used "t as STRING*15"
TH> in the SUB, because someone suggested that I try it. I have a user
TH> defined record, and I want to pass a few of the elements to modify
TH> them.
I suggested you have the SUB accept a 15-byte string because that's what
you were trying to pass to it in the example you gave at the time.  You
should be able to compile this without errors, because t.str is a
15-byte string and the sub expects a 15-byte string:
'=======================================================
  TYPE xs
      str AS STRING * 15
  END TYPE
  DIM t AS xs
  t.str = "This is a test."
  SUB pout (x%, x$, y AS STRING * 15)
      PRINT x%, x$, y
   y = "vxvxvxv."
  END SUB
  DO
   INCR x%
      y$ = MID$(t.str, x%, 1)
      POUT x%, y$, t.str
  LOOP UNTIL y$ = "."
'=======================================================
TH> Well that is in the docs, but as you can see - "t.str" IS a string,
TH> and the SUB knows that. It's a fixed length string, and the SUB
TH> doesn't like that unless I pass BYVAL. For some reason it doesn't like
TH> it being passed by reference.
No, t.str is a 15-byte string and the SUB expects a variable-length
string.  A fixed-length string *is not* the same as a variable-length
string.  They are two different data types, in either PB and QB.
I took a look at the online help for QB 4.5, under the keyword SUB.  It
looks like QB is the cause of the confusion.  Normally you shouldn't
-expect- to do what you want; it just isn't logical to expect a variable
to be one data type going into a SUB and a different type within it.
But QB won't let a subroutine receive a fixed-length string at all.  I
have no idea why.  QB's workaround for that is to automatically copy a
fixed-length string to a variable-length when you pass it to a sub, and
copy it back when it exits the sub.  In other words, it is doing exactly
what you do when you write 'y$ = t.str ... t.str = y$'.  It's the same
Rube Goldberg business, but QB does it for you.
So QB's behavior can save you some typing in this particular case, but
it can cause more typing in other cases.  It's a symptom of a serious
limitation in QuickBasic.  (For instance, what if you need the
fixed-length form in the SUB?  Your QB program would convert from fixed
to variable automatically, but inside the SUB you would have to write
code to convert it back to fixed, use it, convert to variable for the
return, so QB could convert it yet again into fixed-length.)
All that converting must have an undesirable impact on the size and
speed of the program.  Since what QB does is both illogical and
inefficient, I suspect PowerBasic would tell you that they didn't flub
at all, they wrote the language the way it should be.  Dave Navarro may
be able to elaborate.
 * RM 1.31 1209 * Anton Monroe   70304.3663@compuserve.com
--- FidoPCB v1.4 [ff013/c]
---------------