FNSnap

More advanced topics discussed.

Moderators: Susan Smith, admin, Gabriel

Post Reply
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

FNSnap

Post by gtisdale »

THis is a new topic started by Gordon's comment in Client Server thread regarding FNSnap.

My intention in building FNSnap is to create a library that is generically useful to anyone using Business Rules language. At the beginning of the effort I did include some functions that were specific to my software, however, I have been working on removing those pieces from the library. There are still a few "oboslete" functions that are in the library that are specific to me. I will remove those. They have to do with look-up routines for my spceific file structure. I have moved these to separate libraries, but not deleted the code in all cases from FNSNAP

In addition, there are a few, also obsolete functions that relate to my screen painter. Those are specific to a certain screen width, but are obsolete and should be removed. Those functios have been moved to my NEWSCRN.dll utility that a few people have been using.

The single ENV$ dependency that exists throughout the FNSNAP library is the ENV$("PD") variable. I use this consistenltly to point to the parent directory of "Vol002", the directory in which I keep FNSNAP.dll. In most cases the ENV$("PD") variable is exactly the same as the ":" starting point for BR, but not always, depending on how the program is entered. ENV$("PD") can be set in WBCONFIG.SYS or in a menu program or in some other way. Once set the FNSNAP libraries will use its location to find Vol002 an the FNSNAP.dll library within it.

There are some functions that call outside executables, such as David Blankenship's BRREGISTER2.exe registry reader. FNSNAP expects to find these in the ENV$("PD")&"vol002" directory. (ENV$("PD") ends with a backslash as in "C:\WB\").

If anyone finds an instance where I have limited the usefulness of FNSNAP by including parameters that do not work with your particular set up please shoot me an email and I will do my best to adjust FNSNAP so that it is more generic.

In addition to the ENV$ dependency noted above I do use a file that I call "TT" to load certain systemwide variables into programs using a "PROC *:TT" or "PROC "&env$("PD")&"TT". That file is loacted in the BRG directory of the FTP site. I also use a few fonts that I tend to prefer. Those are also loaded with a PROC statement, so in both cses you can change the files being PROCed to fit your own set up and not have them changed each tiome I issue an updated FNSNAP.

I always load FNSNAP as a resident library just before loading and running my menu. That way the rather large library does not need to take up time to load in every chain. It can be a significant time saver.

I hope you all find the functions useful and would welcome any constructive comments.

FNGeorge
Gabriel
Posts: 412
Joined: Sun Aug 10, 2008 7:37 am
Location: Arlington, TX
Contact:

Post by Gabriel »

Have you thought about making ENV$("PD") default to "." in any case where its not set? This may simplify the configuration for new people planning on adopting fnSnap. They would only have to mess with configuring it if they don't want to use it in the standard location.

Gabriel
gtisdale
Posts: 218
Joined: Sun Jun 07, 2009 7:54 am
Location: Concord, Massachusetts
Contact:

Post by gtisdale »

If ENV$("PD") is not set it defaults to blank, which is the same as ".". Since, when set, ENV$("PD") ends with a "\", or should, the path used is the current directory. Where ENV$("PD") comes in really handy is a situation like mine, where I keep books for a number of different entities - some where over 100 - and each has their own set of nested data directories, but the programs all reside in one WB tree on the server.

PD is my shorthand for Program Directory. My menu program allows access to the various clients with an EXECUTE CD to the client drive and then another execute CD to the respective diretory structure on the drive. (You can't CD to a new drive AND a different directory in BR with a single execute statement).

In client server this same structure will allow me to allow clients to view their books on line by giving them access to the menu structure, bit not giving them permission to any directories but their own. The client will remain in s single directory on their machine, and they can then change dorectories on the serer through menu selection.
Post Reply