DECLARE (was Re: Filepro-list Digest, Vol 78, Issue 28)

Richard Kreiss rkreiss at verizon.net
Fri Jul 23 08:43:48 PDT 2010



> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Kenneth Brody
> Sent: Thursday, July 22, 2010 4:35 PM
> To: Boaz Bezborodko
> Cc: filepro-list at lists.celestial.com
> Subject: Re: DECLARE (was Re: Filepro-list Digest, Vol 78, Issue 28)
> 
> On 7/22/2010 4:20 PM, Boaz Bezborodko wrote:
> > On 7/22/2010 3:42 PM, Howard Wolowitz wrote:
> >> On 7/22/2010 3:40 PM, Boaz Bezborodko wrote:
> >>> On 7/22/2010 3:09 PM, Kenneth Brody wrote:
> >>>> On 7/22/2010 2:45 PM, Boaz Bezborodko wrote:
> >>>> [...]
> >>>>> Have you used Debug to go through it line by line?  Filepro won't
> >>>>> recognize a declared variable until it hits the DECLARE command on a
> >>>>> line.  If so then the logical conclusion is that it must have hit this
> >>>>> variable before the DECLAREs you are looking at.  Debug will let
> >>>>> you see
> >>>>> if it ever happens before getting to line 14.
> >>>> DECLARE generates no executable code, and need not be reached during
> >>>> execution.
> >>>>
> >>> I distinctly remember doing some debugging last week and trying to get
> >>> the value of a declared variable before debug hit the line where it was
> >>> declared.  It gave me an error.  Once I stepped through past the Declare
> >>> statement it gave me the value of the very same variable.
> 
> If you can duplicate that behavior, contact fpsupport.
> 
> >> You are wrong.  Dim (dimension) works that way but Declare doesn't
> >
> > It may be that I was looking at a DIMed variable.
> 
> DIM doesn't generate executable code, and need not be reached during execution.
> 
> [...]
> > P.S.  I just gloated to my brother that I got an e-mail from Howard
> > Wolowitz...We're both fans of The Big Bang Theory.
> 
> But, do you have an autographed Season 2 DVD box set?  (Along with a few Big
> Bang Theory luggage tags, for some reason.)
> 
> Or Bill Prady's e-mail address?  :-)
> 
> Our kids still act surprised at times when we remind them that we know the
> "real" Howard Wolowitz.
> 
> --
> Kenneth Brody

Ken,

I have run into the same issue with arrays.  I have found that the dim foobar() needs to occur prior to using the array. Never considered that this might be a "bug" if placed after

Dummy variables, declared variables can be placed anywhere in the processing table.  My preference, in most cases is at the top of the processing table.


Created the following: Windows, fp 5.6.10

keya  ◄ If: '*******************************************
      Then: '* test an array
 8  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
      ◄ If:
      Then: ming["1"]="harry"
 9  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
      ◄ If:
      Then: ming["2"]="sally"
10  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
      ◄ If:
      Then: sl(1,.0)=listbox(ming)
11  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
       ◄ If:
       Then: END
 12  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
       ◄ If:
       Then: dim ming(2)
 13  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -

Save, syntax check:



*** A filePro Error Has Occurred ***

Line Number: 8

ming["1"]="harry"
^
Process contains a syntax error at position indicated.

Move line 12 to line 8, no error


Richard Kreiss
GCC Consulting
rkreiss at gccconsulting.net
  








More information about the Filepro-list mailing list