[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: Re Portable XyWrite



** Reply to message from "Patricia M. Godfrey"
 on Thu, 12 Jul 2007 19:13:39 -0400


> I finally got a little time to test this, and have one question:
> settings.dfl is nowhere mentioned or, apparently, referenced, and the
> resulting setup has no settings.dfl.

OK, a little background. "SETTINGS.DFL" is a reserved name in
Xy4, and it (together with STARTUP.INT) is unique in this
respect. If you rename it to VISIBLE.DFL (or any name other
than SETTINGS.DFL), and you explicitly LOAD VISIBLE.DFL in
STARTUP.INT, then VISIBLE will be read, the settings within it
will be absorbed and used, **but** VISIBLE.DFL will NOT be
"remembered" as the source file for your settings. In other
words, VA $DL will respond "(none)".

Now, I assume that everybody knows this. When PortableXy4 goes
about the business of constructing a portable installation, it
polls the various DeFault settings (like VA$DL, VA$PR, etc) to
find out which specific files you've used to initialize your
regular installation, so that Portable can use them too. If it
encounters a "(none)", it assumes that you didn't install that
file at all, and the fallback is XyWrite's built-in internal
settings, which must be what you're seeing.

In short, go back and rename VISIBLE.DFL to SETTINGS.DFL, then
rebuild PortableXy4. Within PortableXy4, it will be called
MY.DFL. You'll see all your familiar colors and et cetera. Why
do I break the rule I just mentioned? Because in fact once DFL
is read the first (and only) time during initialization, it is
never used again. It doesn't need to be "remembered" by XyWrite.

All of the initialization files in PortableXy4 are called MY.*
and you should have, in your Portable installation, a MY.PRN
which is the same as HP4-PLUS.PRN. If, before you ran
PORTBILD.PM, "VA/NV $PR" returned HP4-PLUS.PRN, then that
PRiNter file will be loaded by PortableXy4. If it wasn't, then
it won't.

> "2) A subdirectory immediately
> below Editor's directory, named .\PORTABLE,
>   is *RESERVED* to the use of PortableXy4."
>
> Does that mean one should create such a directory? Or that portbild.pm
> itself creates and then discards it?

Creates it, then discards it. The warning is intended to convey
that if you have a *pre-existing* subdirectory called
.\PORTABLE, it will be trashed. This warning applies to 1 in a
million, i.e. to nobody.

Oh, overlooked this:

> is it intended to avoid the use of settings.dfl altogether, given
> the tendency to hard code paths in that (which, I understand, is what
> must be avoided)

Well, hard-coded paths in DFL can be ignored, because the
PortableXy4 STARTUP.INT overrides them anyway after DFL is
LOADed. The main reason not to hard-coded paths in DFL is so
you don't get errors on startup. In any case, it is generally a
good idea to move those assignment from DFL to INT in your
regular daily installation, so that if you migrate to another
machine, you don't have to worry about changing DFL. You want
to concetrate all these assignments in INT, to maximum extent
possible (and ALL of them can be accomplished in INT -- notice
how INT writes its own PRiNter file called SETP.PRN, into which
the PP: stanza that is normally found in DFL is inserted -- this
file is then saved to disk and LOADed -- I know it's confusing,
but it's important to remember that SETTINGS.DFL is IN FACT a
PRiNter file! see that ";PR;" header up there on line 1 of DFL?
So I just write my own PRiNter file on-the-fly, within
STARTUP.INT, to manage a small portion of what DFL normally
manages, namely the PP: stanza that lets you use the SETP
command during the session to select your printer).

Try to build again... Then, when you have a PortableXy4.exe
that you like, make a Xy4Net.exe. That's the true
launch-anywhere run-anywhere file that you can put on a remote
machine or carry around on a memory key...

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------