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

[Nancy Palmquist]

Ken,

On 6/10/2014 3:06 PM, Kenneth Brody wrote:
> 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 saw a project like that once - maybe the same one.  They opened Clerk 
and then executed SYSTEM commands to run menu options.  It gave them the 
control of access that is not otherwise afforded to filepro users.

At the time that took two licenses or seats to run since it had to 
execute Dclerk and then another dclerk/rclerk to actually run the option.

I am not sure if that still takes two licenses to run in the current 
version, but I recall it did so I avoided it as a model.  I do use it on 
occasion because it is nice to have a dclerk screen to collect report 
parameters nicely and then execute a report from there.  But I try not 
to make it a regular habit.

I have to say I learn tricks even from the most strangely set up 
system.  You can see that the programmer needed a solution to a problem 
and came up with one based on what they knew about filePro at the time 
and their thinking processes.  It can be enlightening.

Some of the most creative and well organized data processing code I have 
seen is by John Esak and Howard Wolowitz - back in the day. They both 
have very well organized minds. But usually get to see code written by a 
customer with no training in programming or logical thinking.  Those can 
be a bit of a mess.  I am still always amazed by what they can do when 
they have the drive to figure it out.

Nancy

-- 
Nancy Palmquist
Owner
Virtual Software Systems - www.vss3.com
(412) 835-9417