long variable error... a fix needed for 5.5.

[John Esak]

I've been using the 5.0.14 and it looks really good. Haven't found anything
wrong yet.... except for one thing. Nancy was just in the FP Room and
mentioned a couple things with fpCGI and maybe something 5.0.14 but I'm not
sure.  In any case, there is one real gotcha in 5.0.14. I've discussed it
with Ken, and now I have the real lowdown. It is something which needs to be
discussed and then the community should agree (vote?) on the best fix and
_then_ just pass the information on to FP Tech. It absolutely needs to be
fixed for a million reasons.

Small history. I discussed this with Ken way back when the FP Room first
started, probably last November or so. He said he would look into it, and I
just naturally thought it would be incorporated into 5.0.14.  However, after
speaking with Ken yesterday, I see that it is not so easy.  One of those
"design-decisions" ... yech, you know... those things they made so many of
20 years ago which everybody likes to grouse about now. :-)  Let's all make
one that our grandkids can pick apart in 2050 when they're using filePro
16.0.0. (... ooh, that's funny a mobius loop in versioning? Back to the
beginning so to speak...)


Okay, I'll lay it out as simply as I can, then at the end of this message,
I'll put it out as a question... do this?  or this?  Even a straw poll would
help...


Nancy and I are talking in the room now... here is some of our written
conversation... sorry you can't hear us actually "talking" unless you join
us at www.tinyurl.com/yuag7 with your speakers on... want to talk, also,
have a mic hooked up as well. (Still only good for Microsoft Explorer...)


[J_Esak]

     then: declare start_date(8,mdy/),  end_date(8,mdy/)
     then: start_date="08/08/04";  end_date="08/08/05"
     then: wd(20,,g)=start_date < "-" < end_date
     then: print; end
@brk1: if:
     then: print;  wd="";  end


What would you expect this to print on a report for WD in the subtotal_1
break area?


Nancy says, "Well, since it's before you clear WD, it should show the start
date, a dash and the end date."

I say... "Yes, that is what should be there, but what prints instead is:"

        -


"Just the dash?"  Nancy gasps in horror... "That doesn't make sense!"

Then I tell her what Ken told me. "Yup, it's because there are not multiple
copies of declared variables as there are for 2 character variables.  When
WD is filled in the data area, it is filled with the data-area-copy of
start_date and end_date. At the same time, the Break-area-copies of WD are
filled with _their_ partner break-area-values of start_date and end_date and
a literal "-", but since break-partner-values for start_date and end_date
don't exist... the break1-copy of WD is filled with "" < "-" < "". Thus, you
get what seems like an impossible situation. You've filled WD, have not
changed it, yet when it prints in the subtotal area, it is wrong.


[J_Esak] the partner variables for star_date and end_date don't exist...

[nancyP] xx=xx+count needs to work properly for all areas.

J_Esak] I agree, but there are complications... a la Ken's explanation.

We then went on to talk about what Ken explained. All 2 character variables
have multiple copies, one for data, one for each subtotal are and one for
the grand total area.  UNLESS... (AND HERE IS THE BIG ITCH)... unless they
are defined on the automatic table, then they do NOT have muliple copies...
they only have one value.  Ahhhhhh!!!  That is one of those little-known
facts about filePro most developers tend to forget, or never knew.

But, think about it, we all know since the days of the -v table that if you
want to ask for some values on a -v table and then print these values on the
output format, the variables have to be declared global on the automatic
table. Such as the following will NOT work allow you to print BD on the
output format.  Whereas, defining BD on the automatic table, using it on
the -v table and then printing it on the output format _will_ work.

No good:
     if: bd ne ""
   then: goto sel
     if:
   then: input bd(8,mdy/,g) "What date? "
sel  if: 2 eq bd
   then: select
     if:
   then: end


Good:
Automatic table
    if:
   then: bd(mdy,,g)

-v table (scan/selection table)
     if: bd ne ""
   then: goto sel
     if:
   then: input bd "What date? "
sel  if: 2 eq bd
   then: select
     if:
   then: end


The key_factor to understand is that 2 character variables defined on the
automatic table do NOT carry multiple copies for reporting
subtotal/grand-total purposes.

So, this becomes a decision as to whether to treat long variables as the
kind that _have_ mutliple (up to 10) copies, like 2-character variables.  Or
treat them as if they were defined on the automatic table with only one
copy.  The rub is, of course, that they can be defined on the automatic
table as "globaL"... not (,g) but "global" so how should they work in that
instance, and others even more complicated... defined on CALLS, etc.

My personal feeling is that they should be _exactly_ like 2 character
variables with the multiple copies so you could do what Nancy (and all of us
need to do a hundred times a day....

     then: xx=xx + count

And, if declared on the automatic, they should NOT have the multiple
copies.... just like regular 2 character variables.

Would this break anyone programming?? NO, because it isn't working now, so
no one could have code depending on it.  Right now the code in filePro
itself is not working properly. It is trying to use multiple copies of the
variable and they don't exist.

I think having the variable work as one would expect 2 character variables
to work should be the goal... regardless of complications... The other mode
of only allowing them to carry one value might have some utility... if so,
let's hear it.

John Esak