TH> TYPE xs
 TH>     str AS STRING * 15
 TH> END TYPE
 TH> DIM t AS xs
 
 TH> t.str = "This is a test."
 
 TH> SUB pout (x%, x$, y AS xs)
 TH>     PRINT x%, x$, y
 TH>     y = "vxvxvxv."
 TH> END SUB
 
 TH> DO
 TH>  INCR x%
 TH>     y$ = MID$(t.str, x%, 1)
 
 TH>     POUT x%, y$, t.str
 
 TH> LOOP UNTIL y$ = "."
 TH> ==================================================================
 TH> I get a 481 error. What do you get?
BS> I also get that error. And yes, QB won't give an error. But it
  > can lead to sloppy programming. What if your 'xs' structure
  > contained more elements than the fixed-length string? If xs (and
  > also t) was of the following TYPE:
Indeed, the user structure I defined is mixed. And, I don't have any
problem with any of the other data types. Only the fixed-length
strings give me the error.
I have since posted some email from a PB support tech that clarifies
the issue. You may have read it, so I'll not repeat it here. It helped
a lot in understanding this key difference between QuickBASIC and
PowerBASIC, and now I can proceed.
BS> ...you can't very well pass t.str to your y variable then,
  > because the SUB will be expecting a user-defined variable
  > consisting of an integer and a fixed-length string.
True, I also think using a DECLARE will work.
BS> PB is forcing you to follow the rules of proper and consistent
  > programming by requiring you to tell your SUBs *exactly* what you
  > will be passing it, which may save you a few hours of debugging
  > hell in the future when you decide to add that integer to the
  > TYPEd variable and wonder why your program is suddenly giving you
  > the wrong results. Maybe you should be thanking Bob Zale for
  > that... ;-)
*I* don't see it as they're 'forcing' anything. PB just works
differently than QB. PB is a true compiler to machine code. QB
compiles to P-code. The conventions are different, because PB brings
the programmer closer to the heart of the machine. The plus is faster,
more compact code. The minus is that it is a bit more explicit. I've
hung the system like QB never did. It just goes with the territory.
There is no intention to force programmers to be more structured, it
is simply a by-product of being more explicit.
That my $.02... 
BS> Anyway, change the SUB declaration to match what you are really
  > sending it, i.e.,
BS> SUB pout (x%, x$, y AS STRING * 15)
Yes, I found that this works. If I don't need to modify the string,
using BYVAL works very well.
BS> ...then call it as in your example, or declare it as in your
  > example, i.e.,
BS> SUB pout (x%, x$, y AS xs)
I tried this, and the one time I did, it didn't work. But, I admit
that I may not have tested it properly.
 
--- Maximus/2 3.01
---------------