Any response to my DECLARE question

[Jeff Harrison]

John Esak wrote:
[snip]
 
> No, I totally disagree with this, Jeff.  You are not telling 
> filePro that
> there is some variable but you are not sure at this point how 
> it is going to
> be defined... Quite exactly the opposite. You are telling 
> filePro with the
> DECLARE EXTERN that there _is_ a variable in existence on a 
> table that _will
> be_ "calling" this table and that it (filePro) should get the 
> length and
> edit of this variable - and possibly an actual value being 
> passed - from
> that other GLOBAL variable. It is not just to throw 
> undefined, unreferenced
> variables in the table... There is NO reason to use DECLARE 
> EXTERN in the
> way you suggest...

[snip]

Well, you don't TOTALLY disagree with me - I did say that I was not sure :-)

You mentioned that the purpose of declare extern is to tell filePro that
there is a variable in existence on another table that will be calling this
one... While that will usually be true, it does not have to be.  You could
take advantage this feature as a way of using long variable names without
explicitly casting them.  I have actually done this on occasion.

For example I have a processing table that I use to send emails.  I can use
it as a called table or I can call it directly from the command line by
using rclerk with the -z flag (I also use -r raw to let the process know how
it was called).  When it is a called table I use declare globals in the
calling routines - and I of course have declare externs in my prc.mailer
table.  

When it is run from the command line it still uses the same long variable
names. (I use getenv to populate them if @pm eq "raw").  A big advantage of
this is that these variables can get quite large, and I don't have to
pre-define how big they can get when it is used in this way.

BTW - I was saying that filePro should be consistent in its handling of the
errors between dummy fields and long variable names - If a reference to an
uncast aa on the if line gives an error then a reference to an un-cast aaaaa
should also give an error.  However, I just discovered that a reference to
an uncast aa will not necessarily give an error if you just mention them
field somewhere on the then line in your table.  For example:

If: aa eq ""
Then: aa; msgbox "I didn't get an error!"

One thing you can't without a declare, however is:

Then:  aaaaa="something"

And of course you can do that with a dummy.  I can't really argue that this
should be allowed though - it would give too much opportunity for typos
causing undesirable results.

Jeff Harrison
jeff.harrison at epixweb.com

Author of JHExport and JHImport - The fastest and easiest ways to generate
code for filepro exports and imports.  Demos available upon request.