Long Variable Name as Array Element

[Scott Walker]

> -----Original Message-----
> From: GCC Consulting [mailto:gcc at optonline.net] 
> Sent: Wednesday, August 18, 2004 10:38 AM
> To: 'Scott Walker'
> Subject: RE: Long Variable Name as Array Element
> 
> 
> > > > -----Original Message-----
> > > > From: filepro-list-bounces at lists.celestial.com
> > > > [mailto:filepro-list-bounces at lists.celestial.com]On
> > Behalf Of Scott
> > > > Walker
> > > > Sent: Tuesday, August 17, 2004 10:26 PM
> > > > To: 'Kenneth Brody'
> > > > Cc: fpsupport at fptech.com; Filepro List - No spam
> > > > Subject: Long Variable Name as Array Element
> > > >
> > > >
> > > > Ken,
> > > >
> > > > I've stripped this down to a simple example.  No sort select
> > > > processing. No automatic processing.  No dependence on any
> > > data from
> > > > any of the records actually being processed.  Only 7 lines
> > > of code in
> > > > output prc table.  Nothing on any "IF" lines.
> > > >
> > > > Filepro version 5.0.13 rreport.
> > > >
> > > >
> > > > 1	dim Category_Sell[7](12,,2)
> > > >
> > > > 2	declare local Counter(1,.0)
> > > >
> > > > 3	Counter="1"
> > > >
> > > > 4	cr(1,.0)="1"
> > > >
> > > > 5	Category_Sell[cr]=Category_Sell[cr]
> > > >
> > > > 6	Category_Sell[Counter]=Category_Sell[Counter]
> > > >
> > > > 7	end
> > > >
> > > >
> > > >
> > > > Hopefully we are all in agreement that line 5 and line 6
> > should be
> > > > functionally identical, right?
> > > >
> > > > When I run the above code, it works fine!
> > > >
> > > > Now what I think is causing the bug:
> > > >
> > > >
> > > > On line 1, map the array to some dummy variables, so the
> > > code becomes:
> > > >
> > > >
> > > >
> > > > 1	dim Category_Sell[7](12,,2):aa
> > > >
> > > > 2	declare local Counter(1,.0)
> > > >
> > > > 3	Counter="1"
> > > >
> > > > 4	cr(1,.0)="1"
> > > >
> > > > 5	Category_Sell[cr]=Category_Sell[cr]
> > > >
> > > > 6	Category_Sell[Counter]=Category_Sell[Counter]
> > > >
> > > > 7	end
> > > >
> > > >
> > > > When you run it you get this error:
> > > >
> > > > *** A filePro Error Has Occurred ***
> > > >
> > > > Array Index Out of Range:  dim category_sell(7) -- Index: 0
> > > >
> > > > Output Processing
> > > > Line Number: 6
> > > > Process contains a syntax error at position indicated.?
> > > >
> > > > How can this not be a bug if line 5 runs fine and line 6
> > > bombs if they
> > > > both are supposed to be functionally the same thing?
> > > >
> > > > Can anyone duplicate this error?
> > > >
> > > > Regards,
> > > >
> > > >
> > > > Scott
> > 
> > 
> > John,
> > 
> > Did you try it with the array mapped to dummy fields?
> > 
> > Are you running the code in rreport?
> > 
> > I changed the variable name from "Counter" to
> > "Incremeter"....same error.  It has nothing to do with the 
> > variable name or the array name.
> > The error DOES NOT happen when the array IS NOT mapped to 
> > dummy fields but it does happen, every time the array is 
> > mapped to dummy fields, regardless of the array name or the 
> > variable name.
> > 
> > Thanks for trying it.
> > 
> > 
> > Regards,
> > 
> > 
> > Scott
> I have a suggestion for you, a the hated work around suggestion
> 
> Dim a second array to the dummy fields
> 
> Fill your first array and then at the end copy the first 
> array to the second.
> 
> This, at least will allow your program to run and you can 
> submit the bug to fpsupport as an *report problem as this 
> seems to work in *clerk.
> 
> Richard Kreiss
> GCC Consulting 
> 
>

Richard,

I "worked around" this bug two days ago.  It took me (5) minutes.  I
immediately knew that it was the Long Variable name causing the problem,
I just did not know why.  So I just simply used a 2 character variable
instead of the Long_Variable, and away I went.  All of the rest of this
is just trying to get the bug confirmed by others and report to fptech
so it can be fixed and not bite someone else in the future.  

I love Long_Variable names but I've had several problems with them since
their introduction that have led me to not use them everywhere I would
like.  I'm very interested in seeing them approach total reliability so
I can make even greater use of them.

Regards,


Scott 
>