silence readonly messages

[Craig Tooker]

On 8/25/2011 11:34, Joe Chasan wrote:
> On Thu, Aug 25, 2011 at 10:40:04AM -0400, Craig Tooker wrote:
>
>> I mean what I said.  In the @entsel processing you must use waitkey to
>> manage *all* keyboard interaction.  When one one of the keys is entered
>> that you do not want to run with locking, issue a "goto @key(x)" instead
>> of a "pushkey (x);end".  The first method avoids locking the record
>> during the @key(x) routine (in fact it's not been triggered at all, it's
>> just running in @entsel because you used the "goto").  The second method
>> gives the keystroke back to filePro and then lets fP trigger the @key(x)
>> routine (and normal locking of the record).  You must end a non-locked
>> routine (one you used "goto" to enter) with a matching "goto @entsel"
>> instead of "end".
> i see what you are getting at and it probably would work, however this
> process table has 23 @key labels already and I think putting waitkey
> in @entsel is going to be a messy way of trying to get around it in
> this case.
I never write a non-trivial *clerk processing table without an extensive 
@entsel routine.  You can significantly enrich the user experience and 
at the same time increase your control over the process.  The @entsel 
routine looks up into a database that is keyed by system (could be 
client or app. id) / database name / screen to get all the command keys 
for that system and presents them (properly formatted) for the user 
(also filtered by user and group to show only those commands that the 
user may run); waits for a command, and then either "pushkey" them back 
to filePro (for a locked routine) or "goto" the correct label for an 
unlocked command.  It's all standardized and I very rarely need to touch 
it.  It adds functionality for the right and left arrows and the page up 
and down keys.  The HOME key goes to the first record of the current 
index and the END key takes the user to the last record of the current 
index.  All find commands are implemented as progressive browses where 
the user can change index (if allowed).  None of that code needs to be 
changed when I set up a new database.  The end-user also gets a 
consistent experience where the application behaves identically in 
different files.

To create a new function, I just add a record to the commands database 
with the correct properties and write the @key routine in the process table.

I also save each @key routine into its own prc. file.  That way I can 
use a processing table to rebuild a database input processing table if I 
make changes to the templates.  It uses the command database file, 
begins with the template tables and then just tacks on the other @key 
routines that are unique to that database and then use *cabe to create 
the token tables.  In this way, if you add functionality to a base 
template (say the HOME and END keys or whatever), I can simply rebuild 
*all* of the processing tables for *all* of the applications for *all* 
of my clients with a simple command.

For a new database file, I just create the required command records and 
then load the template IUA process table with all the standard commands 
ready to go.

If you don't do this, it's well worth the time to create these templates 
because it will save you so much time in the long run.  If your filePro 
code ever allows a user to see the IUA menu (or deity forbid the filePro 
main menu) you are asking for trouble.
>
> --
> -Joe Chasan-                           Magnatech Business Systems, Inc.
> joe - at - magnatechonline -dot- com   Hicksville, NY - USA
> http://www.MagnatechOnline.com         Tel.(516) 931-4444/Fax.(516) 931-1264
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list