You can't do that

[John Esak]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com
> [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Jeff
> Harrison
> Sent: Tuesday, August 30, 2005 5:42 PM
> To: filepro-list at seaslug.org
> Subject: You can't do that
>
>
> Here are some things that I never found a good way to
> do using filepro.  Please prove me wrong if you can.
>
> Say that I have "remove unwanted blank lines" checked
> off on my output format, but I want to conditionally
> force a blank line based on some logic in my code.  I
> have a couple of ways that I have used to do this, but
> none of them are really "good" i.e. easy to use,
> generic, portable, and intrinsic to filepro.
>
> Here is what I have used for this in the past:
>
> A.  Use a dummy field that you populate with a
> character that does not print on the given printer.
> (Of course you can't use the space character for this
> because filepro assumes this would be an unwanted
> blank line.) - this solution is printer dependent.


Just populate it with a newline chr("13"). Why wouldn't that work on all
printers? filePro doesn't care if the variable holds this value or a
period... or a "j" or a "q"... I have done this for years without any
problems. In fact, it has become a staple of how I do complex forms or
reports... it is not merely a workaround.


>
> B.  Use a dummy field that is conditionally populated
> with a period.  - (ugly - You can place the field
> outside the print area, but this makes it printer
> dependent again.

I used to do this, too... and printed the period on the tear-off part of the
greenbar paper... but I stopped doing it when greenbar paper went out. :-)
See above.



>
> Another item that I found impossible in filepro was
> creating a good edit that would center text.  I once
> wrote an edit that would center some text, but it only
> worked if you did not have any spaces in the middle of
> the string to be centered.  I know this can be done in
> processing, but I had hoped for a edit solution for
> this one.


I hate edits... and I hate Ken...   :-)   Okay, seriously, I actually love
edits and I probably love Ken, too.  But, I never offer help on edits
because he will wait until I do and then put up something far more elegant
and simply "better". So, I'll just skip any attempt here. :-)


>
> Another item is referencing export fields with an
> array.  This was a big deal for me at one time - that
> is why I wrote JHExport - so it is not really a big
> deal for me anymore.
>
> Here are some other "would be nices":
>
> Functions and arguments would be nice.  I would like
> to pass arguments to a particular call (or chain) and
> have it return a value.

Now hold on... am I missing something. This is pretty much *excactly* what I
use CALL tables for in the first place. What do you mean???


>
> Code completion.  This is so nice in modern languages.
>  The IDE knows what the command arguments should be
> and automatically fills them in when it can.
>
> Rules for data integrity.  It would be nice to be able
> to set up certain rules in define processing that
> would prevent certain situations from being allowed.
> For example one could set up a rule to ensure that
> there would be no child data without a header record.
> Another rule could be that a certain field must be
> filled in and no duplicates allowed, etc.

I hear what you are saying... but it sounds like setting up some tight
library CALLS might do this. I'm not trying to say filePro can do everything
you're asking for in this regard, and this sounds like a neat idea, but then
again, even if you had these built-ins, wouldn't you change them once in a
while to do exactly what you want. So, therefore wouldn't good library
functions developed over the years do the same thing for you and be closer
to how you like things done anyway?  I'm sort of against filePro
pre-packaging anything... however, I do feel filePro should provide
full-complete templates for many basic programs... maybe we are more in
agreement than not. It's probably the same thing... except my concept was to
be able to buy various full-functioning templates for various things... not
just rules-type-snippets.


>
> Recursion would be nice, but I never found myself
> lacking this really.  However, I would like to be able
> to have a call within a call.

The financial functions have all the recursion I ever want to see... :-)
However, I could not agree more... I would love to see a CALL allowed on a
CALL table. Even more important if this ever gets addressed, I would love to
see a CALL allowd on a Print Form (from IUA) prc table.


>
> Filepro is so wired into me that I never found myself
> in need of an ELSE statement, but some people find
> this to be a problem.

I, like you, have never even considered needing an "else" statement. If-Then
covers it for me... but, I would like a completely new construct... for
filePro that is... like maybe "while-do" or even "do-while" I'm not picky.


> That is all that comes to mind at the moment.  Some of
> this may be fodder for the wish list, I know.
>
> Jeff Harrison
> jeffaharrison at yahoo.com
>
> Author of JHExport and JHImport.  The easiest and
> fastest ways to generate code for filePro exports and
> imports.
>