long variable error... a fix needed for 5.5.
GCC Consulting
gcc at optonline.net
Thu Oct 28 08:34:36 PDT 2004
> -----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
More information about the Filepro-list
mailing list