First of all, thanks to all of you who replied.
It transpires that there simply doesn't seem to be a way to do what I
wanted.
P Witte wrote:
> 1) Dimension the array to the max youre ever going to need right from the
> start. (This is analogous to your suggestion re the buffer problem we
> dis
On Wed, 9 Jul 2003 00:34:32 +0100, Roy wood <[EMAIL PROTECTED]>
wrote:
If any of our UK QLers are interested there is a seat on Peter Fox's
plane for the German show in October. If anyone fancies the trip drop me
a line and I will explain the cost and details.
If you never flown in a small win
If any of our UK QLers are interested there is a seat on Peter Fox's
plane for the German show in October. If anyone fancies the trip drop me
a line and I will explain the cost and details.
If you never flown in a small win engined plane it is well worth the
trip! The show is usually good too.
The real solution to this problem is a linked list. But, SuperBasic (and Basic
in general) does not support a linked list. I believe by definition DIMed arrays
are not able to change after allocation.
One could ask for some memory (ALLOC or something like that) and handle the
memory any way you
> Basically, what I would like is to be able to re-dimension an array
within
> a subroutine (proc/fn) BY PASSING THE SUBROUTINE THE ARRAY
> AS A PARAMETER.
>
> For example, I have an array f$ (10,10) and a variable 'mycount%'
> which contains the last element of the array that is filled in.
>
> Fr
Wolfgang writes:
> I wonder whether anybody out there has come across the same
> problem I have, (and has found a solution).
A few possible solutions, depending on how your program uses the arrays
between re-dimensioning, etc:
1) Dimension the array to the max youre ever going to need right fro
Damn shouldn't have swapped them variables around should I ??!!
In a message dated 08/07/2003 12:25:13 GMT Standard Time, [EMAIL PROTECTED] writes:
O(...)>
>SMSQ/e has an outstanding bug in this instance as well - take for example:
>
>10 DIM x(10)
>20 c=1:TEST c,x
>100 DEFine PROCedure TEST(a,b)
O(...)>
> SMSQ/e has an outstanding bug in this instance as well - take for example:
>
> 10 DIM x(10)
> 20 c=1:TEST c,x
> 100 DEFine PROCedure TEST(a,b)
> 110 DIM b(100)
> 120 END DEFine
>
> Running this program gives the error as described.
True.
> However, try entering as a direct command:
>
On Tue, 8 Jul 2003 05:25:25 EDT, <[EMAIL PROTECTED]> wrote:
In a message dated 08/07/2003 10:16:25 GMT Standard Time, [EMAIL PROTECTED]
writes:
Thanks.
However the temp array wouldn't survive the exit from the proc/fn and,
moreover, I would have to redim each array specifically instead of just
On 8 Jul 2003 at 4:09, [EMAIL PROTECTED] wrote:
> Solutions??
> =
> Only one I can think of is to use a different temporary array inside the
> PROCedure or FuNction, copy the calling array's contents to this temporary array
> and then re-define the original array on exit from the PROCed
In a message dated 08/07/2003 10:16:25 GMT Standard Time, [EMAIL PROTECTED] writes:
Thanks.
However the temp array wouldn't survive the exit from the proc/fn and, moreover,
I would have to redim each array specifically instead of just calling a general
function.
If you use a DIM statement (in
In a message dated 08/07/2003 07:43:47 GMT Standard Time, [EMAIL PROTECTED] writes:
I wonder whether anybody out there has come across the same
problem I have, (and has found a solution).
Basically, what I would like is to be able to re-dimension an array within
a subroutine (proc/fn) BY PASSI
12 matches
Mail list logo
