Re: FILEMENU.PM [longish]

[cld@xxxxxxxx (Carl Distefano)]

Reply to note from "Yo Intl."  Sat, 20 Jan 2001
17:38:02 +0900

-> >from a list of filenames. The most important new
-> >feature is that the menu file can now be made
-> >"portable", i.e., usable on more than one system, even
-> >if the drive and path locations of the files listed in
-> >the menu vary from system to system. ...
->
-> I don't get this. How can you do that? Use the find command for
-> each file? Does that not cause an awful lot disk churning each
-> time?

No disk churning. What the new version does is to allow file
locations to be coded in the alternative (using XPL), instead of
hard-coded as a single D:\PATH\FILENAME. For example, suppose one
of your listed files is CDLIST.DOC. On one computer this file is
located on drive D: (say D:\MUSIC\CDLIST.DOC), but on another it's
located on drive H: (say H:\DATA\MYDATA\MUSIC\CDLIST.DOC). Under
the old version of FILEMENU.PM, you'd have to maintain two different
menu files on those computers, one with

My CD Collection[tab]D:\MUSIC\CDLIST.DOC

and the other with

My CD Collection[tab]H:\DATA\MYDATA\MUSIC\CDLIST.DOC

The new version of FILEMENU.PM (corrected 1/20/01) gives you the
option of coding these alternative file locations in the same menu
file. The filename has to be coded in Save/Get 56, and it's up to
the user to build in the appropriate branching. So, in the case
noted above you could have:

My CD Collection[tab]BX exist Q2
>

(In plain English, "check if D:\MUSIC\CDLIST.DOC exists; if it does,
fine; if not, then the file must be in the drive H: location".)

To avoid clutter in your menu, you can structure your code so that
only the filename is visible in No Markers view (which is how
FILEMENU.PM displays the menu). Push unsightly stuff down into
SUbroutines; use GoLabels-LaBels to reroute your code, etc. The
example above could be rewritten thus (ignore the internal carriage
returns; if this were real code, it would wrap automatically):

My CD Collection[tab]CDLIST.DOC
BX exist Q2 >
>

which, in No Markers view, would display as:

My CD Collection[tab]CDLIST.DOC

FILEMENU.PM will accommodate as many alternative locations as
necessary. If you have 10 computers with 10 different directory
structures -- no problem.

Admittedly, this is a somewhat geeky option, requiring familiarity
with XPL and the know-how to make the menu file branch
intelligently. Non-programmers still have the option of maintaining
a separate menu file for each computer.

All of this raises the question of how one goes about making XyWrite
or Nota Bene "aware" of which computer it's running on. My
technique is simple. On each computer, I have a read-only file
called MACHINE.ID which contains a plain-text identifying tag. My
home computers are called HM1, HM2, etc. and my office computers are
called OF1, OF2, etc.; use anthropomorphic names if you prefer. On
Startup this file is LDPM'd to a "permanent" (memory-resident)
Save/Get (303), making the ID tag available throughout the editing
session for use by any XPL program:

=="HM1">...;*;
=="HM2">...;*;
=="OF1">...;*;
=="OF2">...;*;

The uses are virtually unlimited. To pull one example out of the
air, you could instruct XyWrite to load a particular color scheme on
startup, depending on known lighting conditions for a given computer
at various times of day -- all with the same STARTUP.INT file.
Since I'm finicky about the interaction between screen colors and
ambient light, this is, in fact, what I do.

--
Carl Distefano
cld@xxxxxxxx
http://users.datarealm.com/xywwweb/