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

Re: Screen Garble



something wrong again, as you can see; eachy keystroke prints 2 (two)
characters.... what is going onnow, SysOp???? i didn't eve want to SEND A
MESSAGE; i asked to READ MESSAGES and thisis what i got. this is reidiculous
and i am paying for this????? mike tressler toledo, ohio 4198415739


To: ROBERT HEMENWAY
Robert:

 PMJI, but I've been thinking about your problem with superfluous MoDe statements. Even when they
don't get in the way of work, they're offensive. Messy theory and messy practice: a muddle. This
BBS has posted XyQuest documents strewn with them; it always made me wonder. Anyway... I see some
difficulties with SysOp's contention that "a program could be easily written to strip out
superfluous MODE commands". Strikes me as not easy! On the one hand, if you limit yourself to
III+ two-character MDNM, MDIT, MDRV, etc statements, you can do CIA's from TopFile and it's a piece
of cake; the schema you describe (kill the first of two adjacent MoDe commands) suffices. But
simplicity ends there. Consider some of the values on my system, as an example:
      Sig|Xy4 evaluate this as !
      Sig|Xy4 evaluate this as !
    All equivalent
   Now what?
   Ho ho!
 In short, you require a wee bit of programming. I've been thinking about how to approach it, and what tools to use, in idle moments. Here's a stab at the problem. I begin with some dumb CIAs from TOF to wipe out the easy stuff -- i.e., 75% of your problem. With the remaining MoDe statements, I begin at EOF (this could be more sophisticated, but it's a broad-brush attempt to get something that works, so it attacks whole files only). I examine the value of  after each MoDe statement (to figure out what mode we're in), and then convert that value (if a $tring like BO or BR) into a number using  and the like (if we're already in a numeric MoDe like , this step is unnecessary). I then compare the numeric result to the numeric MoDe value which pertained immediately *before* this MoDe statement. If they're identical, the second statement gets zapped. This works for an awful lot of it. It isn't perfect, though -- largely because Xy isn't perfect (not that I claim perfection either, but...). And, as a matter of taste, you might prefer different results in some cases. For example, if you take the sample statements above, and run my PM against them, you get:

 
 
 
 
 

 First, note that because two equivalent simple MD statements were contiguous (), the former of the two got zapped. You might prefer to have MDUL instead of MD9, but on the host Xy4 installation (mine), they're identical, so its no error. Second, note the absurdity of retaining  after  has wiped out any possibility that MDIT might be hanging around. But Xy generates different  numeric values before and after the , so what can I say?

 Note that the PM ain't the fastest, & it *looks* awful whilst running, but you'd better leave the screen on (don't DX), because recurrent JMPs|DeFines&Rubouts|CPs tend to get all messed up (Sig and Xy4 have gotten worse and worse in this respect). Better to do something else (true preemptive protected multitasking OS/2!). May work under NB too (remove the ">0>..." statement but retain "" right after ). No exhaustive testing! No warranty! Ciao