Text 2814, 130 rader
Skriven 2011-02-23 12:01:11 av MrG
Ärende: Re: OS2 CMD window positioning
======================================
ab2a7f9a
GMT)
posting-account=hzmWuAkAAAA2pnOSFxD-DG1p-Xq6IDrg
From: MrG <gw-ent@cox.net>

On Feb 22, 7:40 am, "James J. Weinkam" <j...@cs.sfu.ca> wrote:
> James J. Weinkam wrote:
> > MrG wrote:
> >> On Feb 20, 12:07 am, "James J. Weinkam"<j...@cs.sfu.ca> wrote:
> >>> MrG wrote:
> >>>> Once a VIO window has been resized, each subsequent invocation of the
> >>>> window is automatically put in the maximised state. Restoring down to
> >>>> non-maximised does absolutely nothing unless you re-maximise it, then
> >>>> it will shoot the window to the top left of the screen. Restore down
> >>>> again and the window returns to the position you put it with the shift
> >>>> +drag operation. Restore down from maximised, close the window then re-
> >>>> open it, it will open again in the maximised state. Restoring down
> >>>> each time you open a window is a bit tedious besides it does nothing
> >>>> for the position of the window when re-appearing from a PM app.
>
> >>> That's not what happens here.
>
> >>> For example if I open an eCS command prompt window, it opens in maximized
state at the position
> >>> where all initially maximized VIO windows open and its size is 80x25. If
I execute mode 100 50, the
> >>> upper left corner stays in place, the window grows to 100x50, and there
no scroll bars. If I then
> >>> click the restore button, the window cahges to restored state but the
size and location stay the
> >>> same. If I then execute e d:\config.sys, then exit from e, the command
window reappears where it was
> >>> before the command, is still in restored state and the size is 100x50
with no scroll bars.
>
> >> That's what is supposed to happen. Close that window in the restore
> >> state, re-open it and it should re-open in the maximised state.
>
> > Right.
>
> > Or,
> >> while that window is open, open another instance of cmd, and the 2nd
> >> cmd window should open in the maximised state while the 1st window
> >> stays in the restored state,
>
> > Right.
> > which is what I was saying.
>
> > That's what I missed in what you said.
>
> > What you are
> >> referring to is session specific and does not affect the default
> >> behavior of a VIO window.
>
> > Right. For better or worse, there is one system wide bahavior. I hesitate
to use the word default
> > because I know of no way to specify a different value for the nonce, i.e,
there is nothing that I
> > know of that you can put on the command line or in a program object, or
even it the parameters of a
> > start command that will cause a particular session activation to differ
from the system wide behavior.
>
> > You can of course change the system wide behavior by the shift drag method
or by editing the Shield
> > application.
>
> > Same with the mode cmd being session
> >> specific. I was referring to changing the default size of a VIO window
> >> which the values of are stored in os2.ini I think.
>
> > I thought I understood that but I think it's more complicated than I
thought. I'll have to do some
> > more experiments, but I don't have time to fool with it at the moment.
>
> I spent a couple of hours investigating this this afternoon and here is what
I came up with.
>
> The value of the sInitialShape keyword consists of 9 16 bit words. Four of
them always seem to have
> the same value. I have been able to identify the purpose and encoding of four
of the others. The
> remaining one has a different value each time the parameter is set, but I
haven't been able to
> figure out its purpose or encoding. Here are the details (little endian
notation throughout):
>
> word 1: always 8700
> word 2: height of window in pixels at time sInitialShape was set by shift
drag.
> word 3: width of window in pixels at time sInitialShape was set by shift
drag.
> word 4: vertical position in pixels of the bottom edge of window measured
from bottom edge of screen
> word 5: horizontal position in pixels of left edge of window measured from
left edge of screen
> word 6: always 0300
> word 7: always 0000
> word 8: ?
> word 9: always 0080
>
> If fMaximize is 0, sInitialShape is ignored and the position is chosen by the
system; if fMaximize
> is 1, the sInitialShape value only affects the position of the window. In
either case, the size is
> always 80x25 characters as specified by ~Font Size... On my system the width
is 80*character_width+8
> and the height is 25*character height+32. The 8 comes from the window borders
which are 4 pixels
> wide and the extra 24 in the height is for the title bar.
>
> The thing that misled me into thinking the the size was also affected was
that in my previous tests,
> I had been opening a ZTree program object, but I have ZTree configured to
immediately change the
> size of its window to 100x50.

Interesting. Now, what about changing font size? It is always 80x25
chars, but changing font sizes also changes the defaul window size.
Also what about a VIO windowed program such as Z! mp3 player, which
uses default window size and does not allow for window size change.
Could one revert back to original default window size, use mode on a
cmd prompt and have the app open in the moded (is that a word?) size.
As it is now, whether I use mode from a cmd prompt or in the
parameters field of properties, Z! comes up in the default window
size, not in the changed by mode size or shift+ drag method of
resizing.

--- Internet Rex 2.31
 * Origin: http://groups.google.com (1:261/20.999)