John Small wrote:
> ** Reply to message from WD Loughman <wdloughman@xxxxxxxxxxxxx> on Mon, 08 May
> 2006 12:32:58 -0700
>
>
>
>>Sorry 'bout this tardy response.
>>
>>John Small wrote:
>>
>>>** Reply to message from WD Loughman <wdloughman@xxxxxxxxxxxxx> on Mon, 01
>>>May
>>>2006 12:34:15 -0700
>>>
>>>I'm not sure I understand this. Are you saying that when you use CTRL+C to
>>>terminate JBSWU, that one version of JBSWU closes the window and another does
>>>not?
>>
>>No, no. When I invoke the monitor by command-line *from within a
>>command-line window*:
>>1) The monitor opens (in a new[?] NON-resizable window), and
>>2) the original command-line window goes away.
>
>
> It is not a new window.
>
>
>>Perhaps it's resizing the original, then hi-jacking it. The *effect* is
>>as though it closed. What's left after closely the monitor isn't useful.
>
>
> This is correct.
>
> I, too, find this window generally unuseable. But I do use it on occasion to
> SET various environment variables (which are used by JBSWU to generate
> debugging info). Then I restart JBSWU with this new environment.
>
>
>>When I open almost any other application _via_ command-line, it opens in
>>its own window *and* the original CLI window remains open, pushed back
>>"below" the application's window.
>>
>>When I close the application (its window disappears), my original CLI
>>window is exactly where I left it, exactly *as* I left it.
>>
>>I do this, and see this, all the time with E.exe, EPM.exe, PMView.exe,
>>Mozilla.exe, Firefox.exe, etc ad infinitum.
>
>
> The key issue is that all the example you cite are PM programs. REXX
> programs,
> on the other hand, run in the same window in which they are initiated.
Hmm; of course! I guess that gives the *appearance* of not making the
CLI "go away"? Nothing at all happened to it. Completely forgot that.
>
> I will change my program so that it will allow you to resize the window back
> to
> its original dimensions. (This would be done through the MODE command, as
> Rodney has already suggested.) Unfortunately I do not know how to cause the
> window to be resized back to original dimensions. My new JBSWU will only make
> it possible to resize the window (Note the scroll bars you will see). You
> will
Scroll-bars are fine. With me, at any rate. I think -- see next.
> still have to resize the window manually.
I assume that means "grabbing" the edges with the cursor, and pulling??
>
> In summary, to deal with the too-small-to-be-useful window problem, the
> options
> are:
> 1) Have JBSWU use a full window for display (so there is no size issue).
> This would require some reprogramming and a consensus agreement for this
> change
> among JBSWU users.
No-o-o-o-o! (please).
> 2) Return the window back to its original size
> 2a) Enable a resize with an appropriate MODE command. (The next JBSWU
> will
> do this automatically.)
> 2b) Manually resize the window with the mouse or keyboard.
Acceptable.
> 3) Do not use the reduced-size window after JBSWU terminates.
> 3a) Start it in a way that causes the window to close automatically after
> the program exits. This involves using the /c parameter. For example, from a
> CLI window use:
So long as closing JBSWU doesn't close the CLI window from which it was
invoked.
> start /f /c jbswu_monitor <parameters>
> or, if you want to control the title bar text of the window,
> start "<put your title here>" /f /c jbswu_monitor <parameters>
> This is the closest way to simulate the behavior you see with the PM apps.
> The
> "start" leaves the existing window open (and normal-sized) and run JBSWU in
> another window of its own, the "/f" (which is optional) runs it in the
> foreground, and the /c cause the new JBSWU window to close when JBSWU exits.
Hmm. I'd want to see that - use it - to decide about it.
> 3b) If you forget or choose not to use 3a, then execute "start /f & exit"
> within the reduced size window after JBSWU has exited. This will cause a new,
> full-sized window to appear and the reduced size window to close. (Option 2
> is
> probably easier than this.)
>
>
>>>Then I moved the 4OS2 files into the path and just put 4OS2.EXE in the "Path
>>>and file name" setting. This worked well.
>>
>>I'd imagine it might seem to, if you've not enhanced 4OS2 with various
>>colors for characters and backgrounds.
>
>
> Does the latest JBSWU still have the display anomalies when run under 4OS2
> with
No. Is OK.
> your color customizations? If yes, could you explain how to set these colors
> under 4OS2? (I'd prefer not to have to learn this on my own just to fix this
> bug.)
It's done in two places...
..."4os2.ini". Mine:
_______________________________________
[4OS2]
WindowState = Standard
LocalAliases = No
History = 1024
EditMode = Overstrike
CursorOver = 10
CursorIns = 100
BatchEcho = Yes
UpperCase = No
LocalHistory = No
Colordir=bat btm cmd com exe jar prg:bri cya;clas class dll:bri
yel;rdonly hidden system:white on red;arc arj gz lha lzh rar rj rpm tgz
wpi zip:bri green
BrightBG=Yes
FuzzyCD=2
Printer=LPT1:
_______________________________________
...and "4start.btm". Mine:
_______________________________________
: 4START.BTM 6-07-2002/2-20-2001/5-07-2000/980711 -wdl
: ex FIX.CMD 980402
:
@echo off
ALIAS /R G:\4OS2\ALIAS2.LST
: display: white on med blue
prompt $i$e[44;37m[$p]
cls
: eof: 4START.BTM
_______________________________________
It's the "prompt" line that gives the background.
Thanks *so* much, for all your work for all of us!!
- Bill
--
WD "Bill" Loughman - Berkeley, California USA
http://home.earthlink.net/~wdloughman/wdl.htm
------------------------ Yahoo! Groups Sponsor --------------------~-->
You can search right from your browser? It's easy and it's free. See how.
http://us.click.yahoo.com/_7bhrC/NGxNAA/yQLSAA/9rHolB/TM
--------------------------------------------------------------------~->
|
