How I got winSig+
to cough up
one xyWrite
xpl instrument
Sig had confiscated
Proceed
at your
own risk!!!
<LYNX ALERT: This piece uses guillemets,
« and »,
which your installation may not render.>
A kbd file full of recurrences of a sequence like JM,(,2,.,#,g,O,l,d,) is a mess. &[0-9/A-Z] ldpms can prevent that--custom.kbd &O instead--but each requires a file loaded to permanent memory. In xyWrite 3, &ldpms are effectively workarounds for Help file type 5 frames, which use less memory, can do the same things, when assigned a $[0-9/A-Z] designation also keep kbd files neat--custom.kbd $O--but when used without user interaction cause an annoying flash. Windows U2 type 5 frames don't flash, but Signature+ releases don't implement U2 $[0-9/A-Z] frames. Thus, for custom.kbd tidiness recurrent sequences require sacrificing chunks of permanent memory to load otherwise unnecessary &ldpm files.
Or do they? Without apparent ill effect, my NB.INI and XWSTART.INT load MY_NB.DLG and MY_XW.DLG, copies of *.DLG I edited to turn on designated U2 $[0-9/A-Z] frames, instead of NB.DLG and XW.DLG. Because of the xyW3 frame 5 flash, !xyWise and !OutBack use several &ldpms and >99 variables that in xyWin/nbWin are $[X] frames. I use two >99 vars in xyWin/nbWin--tiny databases for va$s Sig+ lack--and no &ldpms. Nor do I allow nbWin to load &ldpms--i.e., my installations load no *.AUX, but still load the NB overlay (more on this presently).
Understand that I'm simply sharing what I've done. I certainly do not suggest, emphatically do not recommend, that you do this. I am after all a xyWin/nbWin novice and one doesn't edit these files or change loading procedures casually. Further:
Unless one invests more effort than I'm willing to, the only way I know to edit NB.DLG, a crucial file, without destroying it destroys menu access to the character "i circumflex sm-794." That character's code contains a hex1A--a dread midfile dos EOF. Before opening a COPY of NB.DLG the first time (and only the first time) one must change the way Signature+ normally handle hex1A: i.e., must execute a d 1A=1 command, and after storing the COPY--which destroys i circumflex sm-794 access--must execute a d 1A=0 command. XW.DLG has no comparable gotcha.
Setting up U2 $[0-9/A-Z] is pointless for a frame that's assigned once to one key, but I use $O and a few other frames often in kbd macros. Enabling U2 $[X] couldn't be simpler. In each COPY of *.DLG I made a frame for each $[X] I wanted to use directing *.DLG to load a corresponding frame in my U2 file, e.g.:
-
{{5,$I}}
[ascii 2]JM (2.$I)«ex»[ascii 2]- {{5,$V}}
[ascii 2]JM (2.$V)«ex»[ascii 2]- {{5,$O}}
[ascii 2]JM (2.$O)«ex»[ascii 2] - {{5,$V}}
- {{5,#i,$I}}
- {{5,#vi,$V}}
- {{5,#gOld,$O}}
- {{5,#vi,$V}}
-
00=$VXPGTSI,<,+,*,+,UD,+,*,+,CI
BX,s,e,b, , ,<,+,*,+,Q2BX,s,e,b, , ,<,Q2CRXDDWCLXDDF
BX,s,e,b, , ,<,Q2CRDFBX,s,e, , ,<,Q2SI,/,CPXDCI,>,RCRCDF
BX,s,e, , ,+,*,+,Q2BDBDBDDFRD$GGT
-
00=JM,(,2,.,#,v,i,),XPGTSI,<,+,*,+,UD,+,*,+,CI
BX,s,e,b, , ,<,+,*,+,Q2BX,s,e,b, , ,<,Q2CRXDDWCLXDDF
BX,s,e,b, , ,<,Q2CRDFBX,s,e, , ,<,Q2SI,/,CPXDCI,>,RCRCDF
BX,s,e, , ,+,*,+,Q2BDBDBDDFRDJM,(,2,.,#,g,O,l,d,),GT
- After reading this, Signature+ xpl guru Carl Distefano commented that using this frame in *.DLG
- {{5$?}}
[ascii 2]«sxNN,«va$fr»» JM 2.«pvNN» Q2 [ascii 2]- enables any func $[X] definition in *.U2. I haven't tried it.
|
Coding Signature+ U2s with xyWrite 3 |
||
|---|---|---|
|
I zapped MY_NB.DLG's midfile eof with xyWin because I find,
alas, that !xyWise FizFix1A can't process files that big.
Otherwise, I use xyWrite 3 for all Sig+ U2 programming. That includes editing copies of *.DLG. Files nearly 2.5 times as large as *.DLG (the largest I've had occasion to edit) don't faze my xyW3 installations. But anyone who fails to conserve xyW3 memory rigorously should think twice about editing big files. |
A xyW3 ex-user devoted to an xpl-heavy v3 Help
file describes severe xyW3 instability while
editing files less than half the size of *.DLG.
My installations exhibit none of the
weirdnesses v3 Help xpl advocates report.
Loaded, my Help file is 9600 bytes. Except when printing hard copy I load a <1500-byte screen driver, not a print driver. At this moment, func ME under win95 reports that those files occupy 1mb of memory each. SPELL + 1522-byte MY.SP3 use 4mb. 429mb are free. |
Sig+ haven't the courtesy to respect the
programmer's choice of xpl case. When I was
trying (failing) to adjust to xyDos4, Sig+ all-caps
xpl drove me to such distraction I wrote
a kbd macro, now a !xyWise !O.LIB module,
that lowercases many operators. Every time
!xyWiz !!! opens an xpl file it invokes the
module in the event a Sig+ app has stored
it. In a PC that meets its unreasonable
demands on graphical hardware resources,
xyWin is rewarding enough to put up with Sig+
vexations, but I'd never program with a Sig+ app.
|
Funcs toward the end of the ascii 130 list are intriguing. The last that xyW3 and Sig+ render the same are SA, TB, and TC. xyW3 renders Sig+'s OV as TX, SG as LO, XH as TG, FT as SG, MN as TM, MK as NM, NM as MR, RX as XT, KF as OV, JC as HG. NN wildcard funcs that Sig+ render variously are all XX to xyW3. Sig+ ES and recent funcs get real ugly in xyW3 and are best pfunc'd in Sig+ or lifted from *.DLG. Forgetting to type BX and JM instead of CG and FT in Sig+ kbd files is counterproductive. | ||
Some nbWin
tech notes
-
[Startup]
load &root&mycustom.kb5=
uwf 3=
load &root&my_nb.u2=
load &root&my_nb.dlg=
load &user&my_nb.dfl=
load &user&my.sp3=
; load &user&main.hyp=
; ldlib &user&default.lib=
; ldpm &root&nbmain-c.aux,&c=
; ldpm &root&nbmain-d.aux,&d=
; ldpm &root&nbmain-i.aux,&i=
; ldpm &root&nbmain-e.aux,&e=
; ldpm &root&nbmain-x.aux,&x=
; ldpm &root&nbmain-g.aux,&g=
; run &root&nbmain-s.aux=
load &root&nb_aux.u1=
It may be that I haven't noticed because I don't use built-in session-to-session continuity; I'd guess that default.lib has something to do with continuity beyond stsgts. I question its implementation and, given its susceptibility to misadventure, the advisability of making it so inaccessible. Don't we have enough necessary evils without having to cope with one that's avoidable?
Here's how I replaced nbWin's intemperate &ldpm *.AUX overlay with a more conservative system.
|
In mycustom.kb5, where once were 64=&C,O 88=&D,D,N 59=BX,(,N,T, ,/,1,),&E 40=FF,&G,Q,1 35=&I,I,% 62=&X,O,R etc, etc |
are now 64=$N,C,O 88=$N,D,D,N 59=BX,(,N,T, ,/,1,),$N,E 40=FF,$N,G,Q,1 35=$N,I,I,% 62=$N,X,O,R etc. |
-
{{5,$N}}
[ascii 2]JM (1.argNB)«ex»[ascii 2]
-
{{5,argNB}}
[ascii 2]«sx90,«rc»»«sx90,"aux"+«is90»»JM (1.«pv90»)«ex»[ascii 2]
What the *.AUX &ldpm overlay does is extensive but as xpl is quite simple-minded and NB coding is admirably orderly, so converting &ldpm file «LB»'d sections to U1 frames subordinate to frames auxC, auxD, auxE, auxG, auxI, and auxX took less time than you might expect. Wonder if the developer had a good reason for not doing a similar conversion, or just unthinkingly stuck with a dos model. If dosNB is structured similarly, no wonder memory managers are such a critical issue.
Use of $C, $D, $E, $G, $I, and $X frames instead of the $N->argNB switchbox would result in a cleaner kbd file and would have no significant effect on NB_AUX.U1, but why needlessly expropriate $[X]s users might like to implement? Indeed, before I worked out how to implement $[X]s, $N was &N in order to free up &C, &D, &E, &G, &I, and &X. &[0-9/A-Z] are after all user instruments. While NotaBene may need to borrow xyWrite user tools, as a commercial enterprise the developer at least could be considerate. (Of course *.DLG repeatedly invade xpl user space. Tim Baehr, who helped write the original, commented that with IBM pressuring them to dump the CMline, etc, variable numbers were the least of the programmers' concerns.)
NB_AUX.U1 is complete but largely untested and, having no need for what the NB overlay and SmartWords do, I don't expect to do any more work on the file. Determining that the NB.DLG $N->U1 argNB concept is workable with the rather highstrung nbWin was a satisfying exercise. (And won't I be surprised if NB has done away with the &ldpms and default.lib since releasing the never-upgraded nbWin I use.)
This bears repeating: Proceed at your own risk!!!
Trying to make Signature's gui progeny, Windows releases of xyWrite and NotaBene, perform as much as possible like my xyWrite 3 interface involved converting some complex xyWrite xpl to U2 xpl, a job I'd abandoned in frustration in the past before reaching a point where I could use the app confidently for routine work (not synonymous with trusting the app). I load the same >127k U2 to both (SmartWords--nbWin--version laboriously corrected for ANSI and inflated by kludges that try and fail to compensate for SW's absolutely malevolent refusal to shell out gracefully from xpl).
If your xyW3 xpl is extensive, the porting barrier is formidable. Although some syntactical differences are documented and experts are eager to promote xyDos4 U2, nobody but you is going to debug your U2. xyWrite-Signature inconsistencies are inexplicable, unpredictable, undocumented, and unending. A manual that reportedly (I've never seen it) helped users port v3 xpl to Signature wasn't distributed with Sig's progeny. Since The Herb bailed after xyW3 (who could blame him?), if you hit a wall you have no Book to turn to, just a mailing list where you may get an answer or may be told to download and decipher someone else's code.
Just now, e.g., I can't persuade a subroutine to go to a Sig+ AlternateScreen to open the file listed at the cursor--a trivial xpl operation that can be coded in xyWrite 3 literally in about 10 seconds. No doubt it can be done in Sig+, but why waste more hours--and I mean hours--trying to work out how? !xyWise succeeded, and a !xyWiz module searches and replaces wildcards with wildcards, because I have unshakable faith that any programmer clever enough can make xyWrite 3 xpl do anything. I'm not all that clever, I just had more confidence in xyW3 than the xpl programmers who laid the foundation !xyWise is built on. Signature+ xpl doesn't inspire similar trust, thus a willingness to persist till the solution to a real problem emerges, since dealing with problems that shouldn't exist at all (like opening a file listed on another screen) consumes so much time.Lest you suspect that fooling around with the guts has made my nbWin installations misbehave, keep in mind that I started fooling around with the guts because nbWin was misbehaving. I modified the xpl overlay later. I see so many SmartWords "too many program calls or program loops" msgs from xpl that xyW3 and xyWin run uneventfully I have no choice but to consider SW a giant leap backward as a vehicle for xpl. I'd guess that SW optimization for VisualBasic is behind the trouble. Once NotaBene invited xyWrite users to buy nbWin, the developer had to expect adventurous xpl users. So don't tell me not to try to get SmartWords to perform at least as well as its predecessor, xyWrite 4--especially since I have no hope Signature and its offspring can perform as well overall as their predecessor.
- Later: Carl Distefano has volunteered that to open a file listed on the adjacent screen--which xyWrite 3 xpl does with
- AS BC ed XC
- --Signature+ require
- AS «sxNN,«va$dr»» BX ca «pvNN» Q2
- . . . Who'd've known? Entirely typical of the kind of inexplicable, unpredictable, undocumented, and unending inconsistencies to be expected when porting v3 xpl to Sig+.
| adpFisher nyc 17 october 2001 |