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

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com 
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf 
> Of John Esak
> Sent: Wednesday, October 27, 2004 6:09 PM
> To: filePro mailing list
> Subject: long variable error... a fix needed for 5.5.
> 
> 
> 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 multiple 
> 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_ multiple (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
> 
-----------------------------------
John,

I follow your logic.  However, I would I would have made the start_date and
end_date as (8,mdy/,g) so the values remain throughout the processing.

I would then 

@wbrk1 :
	 :wd(20,*) begin_date<"-"<end_date
	 : 
	 :print;END

This logic works.  If the dates change for some reason at the break, the values
can be cleared and the new dates gotten.

This logic also works with -v processing as the date renage can be declared
global and passed to the main processing table when run.

Now granted some may say my solution is a "work around". I don't think so, it
just seems a logical way to code this.  As we all know, coding is as much an
"art" as a science.  But 12 of us in a room and give us a programming problem
and we will come up with 36 ways to do it.

Since this really isn't broken, I would rather see Ken spend his time adding
some new useful features, per the wish list, then changing something that really
isn't broken.

Richard Kreiss
GCC Consulting