filePro/menus/scripts/etc (was Re: [SOLVED] EXPORT ASCII won't - after action report)

[Richard Kreiss]

> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
> [mailto:filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com] On
> Behalf Of Kenneth Brody
> Sent: Tuesday, June 10, 2014 3:06 PM
> To: Nancy Palmquist; filepro-list at lists.celestial.com
> Subject: filePro/menus/scripts/etc (was Re: [SOLVED] EXPORT ASCII won't -
> after action report)
> 
> On 6/10/2014 2:17 PM, Nancy Palmquist wrote:
> [...]
> > Example, I work on one app that the developer wrote with Batch DOS
> > Scripts.  So instead of looking at the menu to see what happens, you
> > have to hunt up a Script and then see what will happen.  It even goes
> > to a filepro file and does IF THEN logic to decide which DOS script to
> > run in some cases.  I find this approach very difficult to document
> > and follow.  But it works.  I can see the beauty of a script to send
> > an email or translate a PCL to a PDF where you can use it from
> > anywhere, but filepro can run scripts right on the menus and it makes
> > it easier to follow.  One less step of tracing.
> [...]
> 
> I saw a system that had replaced all of the filePro menus with a filePro "menu"
> file, consisting of fields for the menu name, item keystroke, command to run,
> and comment.  (It looked as if all of the the filePro and user menus had been
> imported into this file.)  Then, there was a "permissions" table, which listed
> which users were allowed to run which choices on any given menu.  A master
> processing table was where everything started, which controlled access to all
> of the menus.
> 
> Elegant solution, but a pain initially to figure out what command line a
> particular user was running.

I had a client, now out of business, where the original developer used ms-dos match files, similar to both Nancy's & Ken's descriptions.  It was very difficult to figure out what was running as the script checked to see if specific files existed.  If it didn't it  branched to another part of the script and again checked for a file.  Only if the file it was looking for existed did a process run.  Talk about trying to track down a problem, there could be 3 or 4 possible process to select from to find out which one was having a problem.  Most of these scripts could have been replaced with select processing or an input process which would then system out to run the proper filepro command line.  They did not want to pay for the update.  This was an office of foreclosure attorneys.  This was before the bust.  That's what killed their business.  The banks did not pay until a house was foreclosed.  When they stopped foreclosing, the cash flow dried up.  20 attorneys out of work plus a 10 person support staff.  The interesting thing was the banks they were doing business with would not loan them money because their customers, the banks, were not foreclosing. 


Richard Kreiss
GCC Consulting

Office: 410-653-2813