OS2 CMD window positioning

[Dariusz Piatkowski]

I have my CMD windows set to a certain size, and way back when there was a
process I went through to set to open in a certain spot on the Desktop.

As I recently converted over to the new hardware I noticed that I now also have
a side-effect which my old system did not have, namely: when a CMD window is
opened and I do somthing like 'e config.sys' from within it...E editor opens up,
I finish my work there and as I shut down E the CMD window itself is always
re-positioned to the top LEFT corner of my Desktop, right below the WarpCenter
bar.

In comparison, my old configuration, which I still have up and running on the
old hardware has the CMD window returning to it's original position, where ever
I had it when I executed the 'e config.sys' command from within it.

So...what's the secret? I'm missing something...

[MrG]

Post by Dariusz Piatkowski
I have my CMD windows set to a certain size, and way back when there was a
process I went through to set to open in a certain spot on the Desktop.
As I recently converted over to the new hardware I noticed that I now also have
a side-effect which my old system did not have, namely: when a CMD window is
opened and I do somthing like 'e config.sys' from within it...E editor opens up,
I finish my work there and as I shut down E the CMD window itself is always
re-positioned to the top LEFT corner of my Desktop, right below the WarpCenter
bar.
In comparison, my old configuration, which I still have up and running on the
old hardware has the CMD window returning to it's original position, where ever
I had it when I executed the 'e config.sys' command from within it.
So...what's the secret? I'm missing something...

It's been a looong time but I think its open cmd window, drag to
desired position, then while holding down shift key, close cmd window.
position should be remembered.

[Dariusz Piatkowski]

Post by MrG

Post by Dariusz Piatkowski
I have my CMD windows set to a certain size, and way back when there was a
process I went through to set to open in a certain spot on the Desktop.
As I recently converted over to the new hardware I noticed that I now also have
a side-effect which my old system did not have, namely: when a CMD window is
opened and I do somthing like 'e config.sys' from within it...E editor opens up,
I finish my work there and as I shut down E the CMD window itself is always
re-positioned to the top LEFT corner of my Desktop, right below the WarpCenter
bar.
In comparison, my old configuration, which I still have up and running on the
old hardware has the CMD window returning to it's original position, where ever
I had it when I executed the 'e config.sys' command from within it.
So...what's the secret? I'm missing something...

It's been a looong time but I think its open cmd window, drag to
desired position, then while holding down shift key, close cmd window.
position should be remembered.

Just tried it...no luck...but this does ring a bell...may have been the process
I went through to originally...and if that's really the case then for some
reason it's not 'sticking' this time...LOL!

Thanks for the suggestion...any other ideas?

[MrG]

Post by Dariusz Piatkowski

Post by MrG

Post by Dariusz Piatkowski
I have my CMD windows set to a certain size, and way back when there was a
process I went through to set to open in a certain spot on the Desktop.
As I recently converted over to the new hardware I noticed that I now also have
a side-effect which my old system did not have, namely: when a CMD window is
opened and I do somthing like 'e config.sys' from within it...E editor opens up,
I finish my work there and as I shut down E the CMD window itself is always
re-positioned to the top LEFT corner of my Desktop, right below the WarpCenter
bar.
In comparison, my old configuration, which I still have up and running on the
old hardware has the CMD window returning to it's original position, where ever
I had it when I executed the 'e config.sys' command from within it.
So...what's the secret? I'm missing something...

It's been a looong time but I think its open cmd window, drag to
desired position, then while holding down shift key, close cmd window.
position should be remembered.

Just tried it...no luck...but this does ring a bell...may have been the process
I went through to originally...and if that's really the case then for some
reason it's not 'sticking' this time...LOL!
Thanks for the suggestion...any other ideas?

Had it a bit off....open cmd window, then while holding down shift
key, drag to desired position, close window. re-open window and
hopefully voila!

[Andreas Ludwig]

Post by MrG
Had it a bit off....open cmd window, then while holding down shift
key, drag to desired position, close window. re-open window and
hopefully voila!

Works fine here. :-)

[Jonathan de Boyne Pollard]

Post by Dariusz Piatkowski
So...what's the secret? I'm missing something...

Is it maximized?

[Don Hills]

Post by Jonathan de Boyne Pollard
Is it maximized?

I think that's it... the default changed from Warp 3 to Warp 4.
The Warp 3 behaviour was to open "restored", the Warp 4 default was to open
maximised. To change the system-wide default, shift-click the "maximise"
button on the window.

[Dariusz Piatkowski]

Post by Don Hills

Post by Jonathan de Boyne Pollard
Is it maximized?

I think that's it... the default changed from Warp 3 to Warp 4.
The Warp 3 behaviour was to open "restored", the Warp 4 default was to open
maximised. To change the system-wide default, shift-click the "maximise"
button on the window.

Yup...that gets me further...the window is currently maximized...sure enough, if
I un-maximize it and then go through the 'e config.sys' type command when the
editor is closed the CMD window does in fact remain in the same spot I had it
originally. Now comes the '...BUT...' part of it...lol...if I do set the window
to open up in un-maximized mode, the size of the window is the default 80x25,
whereas I have the window set to show 80x40...therefore the window gets created
with a scroll bar and I have to re-size it to get the full 40
lines....grrh...which sucks.

Again, comparing this to my old system, I have the same window opening up in
maximized view, and it does NOT get re-positioned...

So I'm wondering, how can I get to set the size of the window if I open it up in
un-maximized mode? The 'SHIFT+click' method does not remember the size of the
window...

[MrG]

Post by Dariusz Piatkowski

Post by Don Hills

Post by Jonathan de Boyne Pollard
Is it maximized?

I think that's it... the default changed from Warp 3 to Warp 4.
The Warp 3 behaviour was to open "restored", the Warp 4 default was to open
maximised. To change the system-wide default, shift-click the "maximise"
button on the window.

Yup...that gets me further...the window is currently maximized...sure enough, if
I un-maximize it and then go through the 'e config.sys' type command when the
editor is closed the CMD window does in fact remain in the same spot I had it
originally. Now comes the '...BUT...' part of it...lol...if I do set the window
to open up in un-maximized mode, the size of the window is the default 80x25,
whereas I have the window set to show 80x40...therefore the window gets created
with a scroll bar and I have to re-size it to get the full 40
lines....grrh...which sucks.
Again, comparing this to my old system, I have the same window opening up in
maximized view, and it does NOT get re-positioned...
So I'm wondering, how can I get to set the size of the window if I open it up in
un-maximized mode? The 'SHIFT+click' method does not remember the size of the
window...

Re-read my 2nd reply....drag window to desired position while holding
down shift key, done. It doesn't matter if the window is maximised or
not.

[Doug Bissett]

Post by MrG

Post by Dariusz Piatkowski

Post by Don Hills

Post by Jonathan de Boyne Pollard
Is it maximized?

I think that's it... the default changed from Warp 3 to Warp 4.
The Warp 3 behaviour was to open "restored", the Warp 4 default was to open
maximised. To change the system-wide default, shift-click the "maximise"
button on the window.

Yup...that gets me further...the window is currently maximized...sure enough, if
I un-maximize it and then go through the 'e config.sys' type command when the
editor is closed the CMD window does in fact remain in the same spot I had it
originally. Now comes the '...BUT...' part of it...lol...if I do set the window
to open up in un-maximized mode, the size of the window is the default 80x25,
whereas I have the window set to show 80x40...therefore the window gets created
with a scroll bar and I have to re-size it to get the full 40
lines....grrh...which sucks.
Again, comparing this to my old system, I have the same window opening up in
maximized view, and it does NOT get re-positioned...
So I'm wondering, how can I get to set the size of the window if I open it up in
un-maximized mode? The 'SHIFT+click' method does not remember the size of the
window...

Re-read my 2nd reply....drag window to desired position while holding
down shift key, done. It doesn't matter if the window is maximised or
not.

That works, but there is a side effect, that may not be desirable.
That is that moving one window to a specific location, will cause all
windows to move to the same location, stacking them all, exactly, on
top of each other. To be complete, do you know how to revert to the
previous action, where windows open staggered?

[James J. Weinkam]

Post by Doug Bissett
That works, but there is a side effect, that may not be desirable.
That is that moving one window to a specific location, will cause all
windows to move to the same location, stacking them all, exactly, on
top of each other. To be complete, do you know how to revert to the
previous action, where windows open staggered?

As far as I have been able to figure out, the opening behavior of all VIO windows is controlled by
the Shield application in the User Ini file. This can be inspected using the registry editor. Here
is an exported version of the Shield application on my system:

ACShield
KC~Font Size...
VX0A12
KCfMaximize
VX0100
KCsInitialShape
VX8700A403F0035A0094000300000073010080

There are three keywords: ~Font Size..., fMaximize, and sInitialShape along with their corresponding
values.

~Font Size... is self explanatory.

If fMaximize=1 the window opens in maximized state at at the location specified in sInitialShape. If
a program is run in a maximized cmmand window or if any maximized VIO window is minimized and
redisplayed, the window reappears at the upper left corner of the screen. If the mouse cursor is
moved into the title bar area too rapidly, the eCenter appers on top and another object must be
given focus before the window will display on top of eCenter again. If the window is changed to
restored state at any time, it will return to its initial location and size immediately and after
any subsequent program execution or other minimization.

If fMaximize =0 the window will open in restored state at a location chosen by the system by a
method I have not been able to figure out. The size will be 80x25 and there will be scroll bars if
the size specified in sInitialShape is larger. Maximizing the window will cause it to go to the
upper left hand corner and assume the specified shape. The window can also be changed to its maximum
shape by dragging the borders. After running a program or minimizing and redisplaying the window
goes back to the upper left corner if in maximized state or to its location at the time of
minimization if in restored state.

I have no idea what the rationale of this design is. It seems pretty goofy to me.

[Jonathan de Boyne Pollard]

Post by James J. Weinkam
I have no idea what the rationale of this design is. It seems pretty goofy to me.

The whole one-saved-position-for-every-window-of-this-kind is a bodge,
certainly. But M. Walsh, elsewhere in this thread, has explained the
maximization behaviour, which is quite logical. It's the result of
maximising a window that refuses to be re-sized beyond a certain fixed
size. (That behaviour, of course, is in turn down to the way that AVIO
presentation spaces work.)

It happens in all GUI systems that have this sort of mechanism.
Maximise a console window in Windows NT, for example, and it will cling
to the top-left corner and refuse to expand beyond the fixed size of the
screen buffer that it is displaying, in exactly the same way. It's a
simple combination of the maximize action, trying to make the window
occupy the entire desktop by moving its origin to a corner and resizing
it to fill the entire available space, and a window that refuses to
expand beyond a certain fixed size, because its client area is a fixed
N-by-M matrix of fixed-size character cells and their size and font
governs the window rather than vice versa.

[MrG]

Post by Doug Bissett

Post by MrG

Post by Dariusz Piatkowski

Post by Don Hills

Post by Jonathan de Boyne Pollard
Is it maximized?

I think that's it... the default changed from Warp 3 to Warp 4.
The Warp 3 behaviour was to open "restored", the Warp 4 default was to open
maximised. To change the system-wide default, shift-click the "maximise"
button on the window.

Yup...that gets me further...the window is currently maximized...sure enough, if
I un-maximize it and then go through the 'e config.sys' type command when the
editor is closed the CMD window does in fact remain in the same spot I had it
originally. Now comes the '...BUT...' part of it...lol...if I do set the window
to open up in un-maximized mode, the size of the window is the default 80x25,
whereas I have the window set to show 80x40...therefore the window gets created
with a scroll bar and I have to re-size it to get the full 40
lines....grrh...which sucks.
Again, comparing this to my old system, I have the same window opening up in
maximized view, and it does NOT get re-positioned...
So I'm wondering, how can I get to set the size of the window if I open it up in
un-maximized mode? The 'SHIFT+click' method does not remember the size of the
window...

Re-read my 2nd reply....drag window to desired position while holding
down shift key, done. It doesn't matter if the window is maximised or
not.

That works, but there is a side effect, that may not be desirable.
That is that moving one window to a specific location, will cause all
windows to move to the same location, stacking them all, exactly, on
top of each other. To be complete, do you know how to revert to the
previous action, where windows open staggered?
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

True on the side effect, but only for the same type of window. Is
there another way without the side effect? I had thought that
reverting back was as simple as cascading from the window list, but
found out that was good only for the current session. Thought I had
that info stored away somewhere but can't find it, so I'm clueless. I
experimented with different ctrl, alt, shift key combos, and couldn't
come up with it. Please enlighten me to the procedure so I could once
again lose the info down the road :) No, I really do wish to know.
Thanks

[Dariusz Piatkowski]

Post by MrG

Post by Dariusz Piatkowski

Post by Don Hills

Post by Jonathan de Boyne Pollard
Is it maximized?

I think that's it... the default changed from Warp 3 to Warp 4.
The Warp 3 behaviour was to open "restored", the Warp 4 default was to open
maximised. To change the system-wide default, shift-click the "maximise"
button on the window.

Yup...that gets me further...the window is currently maximized...sure enough, if
I un-maximize it and then go through the 'e config.sys' type command when the
editor is closed the CMD window does in fact remain in the same spot I had it
originally. Now comes the '...BUT...' part of it...lol...if I do set the window
to open up in un-maximized mode, the size of the window is the default 80x25,
whereas I have the window set to show 80x40...therefore the window gets created
with a scroll bar and I have to re-size it to get the full 40
lines....grrh...which sucks.
Again, comparing this to my old system, I have the same window opening up in
maximized view, and it does NOT get re-positioned...
So I'm wondering, how can I get to set the size of the window if I open it up in
un-maximized mode? The 'SHIFT+click' method does not remember the size of the
window...

Re-read my 2nd reply....drag window to desired position while holding
down shift key, done. It doesn't matter if the window is maximised or
not.

That process works to correctly position the window...and indeed I have done
this on my new machine and it works fine. The problem I am really talking about
is that the window gets re-positioned to the top left corner when it's
re-displayed after invoking PM window from within it's session first.

Your directions do nothing to alleviate that problem.

[MrG]

Post by Dariusz Piatkowski

Post by MrG

Post by Dariusz Piatkowski

Post by Don Hills

Post by Jonathan de Boyne Pollard
Is it maximized?

I think that's it... the default changed from Warp 3 to Warp 4.
The Warp 3 behaviour was to open "restored", the Warp 4 default was to open
maximised. To change the system-wide default, shift-click the "maximise"
button on the window.

Yup...that gets me further...the window is currently maximized...sure enough, if
I un-maximize it and then go through the 'e config.sys' type command when the
editor is closed the CMD window does in fact remain in the same spot I had it
originally. Now comes the '...BUT...' part of it...lol...if I do set the window
to open up in un-maximized mode, the size of the window is the default 80x25,
whereas I have the window set to show 80x40...therefore the window gets created
with a scroll bar and I have to re-size it to get the full 40
lines....grrh...which sucks.
Again, comparing this to my old system, I have the same window opening up in
maximized view, and it does NOT get re-positioned...
So I'm wondering, how can I get to set the size of the window if I open it up in
un-maximized mode? The 'SHIFT+click' method does not remember the size of the
window...

Re-read my 2nd reply....drag window to desired position while holding
down shift key, done. It doesn't matter if the window is maximised or
not.

That process works to correctly position the window...and indeed I have done
this on my new machine and it works fine. The problem I am really talking about
is that the window gets re-positioned to the top left corner when it's
re-displayed after invoking PM window from within it's session first.
Your directions do nothing to alleviate that problem.

Sorry, I don't know what to tell you. It works as advertised on both
of my machines and every other OS2 machine I've had, even under the
conditions that are not working for you.

[Rich Walsh]

The problem I am really talking about is that the window gets re-positioned
to the top left corner when it's re-displayed after invoking PM window from
within it's session first.

There's nothing you can do about it. While there may be special code that opens
the window in a designated position, the window manager restores it the same way
it would for any other maximized window: its upper-left corner is aligned with
the top left corner of the screen and the window is resized to its maximum permitted
size.

You can demonstrate this with any other window: maximize it, move it, minimize
it, then restore it. It will always end up in the top-left corner, no matter
where it was when you minimized it.

[Dariusz Piatkowski]

Post by Rich Walsh

The problem I am really talking about is that the window gets re-positioned
to the top left corner when it's re-displayed after invoking PM window from
within it's session first.

There's nothing you can do about it. While there may be special code that opens
the window in a designated position, the window manager restores it the same way
it would for any other maximized window: its upper-left corner is aligned with
the top left corner of the screen and the window is resized to its maximum permitted
size.
You can demonstrate this with any other window: maximize it, move it, minimize
it, then restore it. It will always end up in the top-left corner, no matter
where it was when you minimized it.

I do not doubt what you are saying...however my old setup (which is sitting
right next to me) does in fact allow me to do what should be impossible...the
window is restored back (maximized) to the position it was in before invoking
the PM program from within it.

Granted, I am running a number of add-ons, such as XWorkplace for example.
So...somewhere in there, who knows how deep in the bowels of the beast, lies the
answer..LOL.

Anyways, thanks for the hints guys, much appreciated, if I figure this out I'll
be sure to follow-up with a post!

[Dave Saville]

On Thu, 17 Feb 2011 02:14:03 UTC, "Dariusz Piatkowski"

Post by Dariusz Piatkowski
I have my CMD windows set to a certain size, and way back when there was a
process I went through to set to open in a certain spot on the Desktop.
As I recently converted over to the new hardware I noticed that I now also have
a side-effect which my old system did not have, namely: when a CMD window is
opened and I do somthing like 'e config.sys' from within it...E editor opens up,
I finish my work there and as I shut down E the CMD window itself is always
re-positioned to the top LEFT corner of my Desktop, right below the WarpCenter
bar.

Absolutely no help but I see the same thing sometimes with simple copy
paste. The cmd window copied from relocates itself as above.

[Lars Erdmann]

Post by Dariusz Piatkowski
I have my CMD windows set to a certain size, and way back when there was a
process I went through to set to open in a certain spot on the Desktop.
As I recently converted over to the new hardware I noticed that I now also have
a side-effect which my old system did not have, namely: when a CMD window is
opened and I do somthing like 'e config.sys' from within it...E editor opens up,
I finish my work there and as I shut down E the CMD window itself is always
re-positioned to the top LEFT corner of my Desktop, right below the WarpCenter
bar.
In comparison, my old configuration, which I still have up and running on the
old hardware has the CMD window returning to it's original position, where ever
I had it when I executed the 'e config.sys' command from within it.
So...what's the secret? I'm missing something...

Make sure the VIO window is not maximized. It's difficult to tell for a VIO window as the non-maximized
and the maximized window can easily have the exact same size.
You can only tell from the MIN/MAX button bitmap.


Lars

[MrG]

Post by Lars Erdmann

Post by Dariusz Piatkowski
I have my CMD windows set to a certain size, and way back when there was a
process I went through to set to open in a certain spot on the Desktop.
As I recently converted over to the new hardware I noticed that I now also have
a side-effect which my old system did not have, namely: when a CMD window is
opened and I do somthing like 'e config.sys' from within it...E editor opens up,
I finish my work there and as I shut down E the CMD window itself is always
re-positioned to the top LEFT corner of my Desktop, right below the WarpCenter
bar.
In comparison, my old configuration, which I still have up and running on the
old hardware has the CMD window returning to it's original position, where ever
I had it when I executed the 'e config.sys' command from within it.
So...what's the secret? I'm missing something...

Make sure the VIO window is not maximized. It's difficult to tell for a VIO window as the non-maximized
and the maximized window can easily have the exact same size.
You can only tell from the MIN/MAX button bitmap.
Lars

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.

[James J. Weinkam]

Post by MrG
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.

[MrG]

Post by James J. Weinkam

Post by MrG
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. 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, which is what I was saying. What you are
referring to is session specific and does not affect the default
behavior of a VIO window. 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. Mode does not
change the default size of a VIO window.
Sorry for any confusion.

[t***@antispam.ham]

One problem with OS/2 is the inconsistency in behavior. After a
reboot, I resize and position my VIO windows where I want them on
my desktop, and usually when I invoke an editor that causes that
command window to disppear for the duration of the editing session,
the window will reappear in the same place it was when the editor
was invoked, after the editing session is over. But every now and
then, the window will instead reappear in the upper left corner.
Most annoying. It seems most likely to misbehave like that when I
switch away from the editor to do other things while the editor is
active, and least likely to misbehave if I get in and out of the
editor without switching away from it, but I pretty sure that I've
seen exceptions to that rule. Sure wish I knew what causes OS/2
to forget where the window was.

[martinot]

Post by t***@antispam.ham
One problem with OS/2 is the inconsistency in behavior.

Stranger things has been said, too.

[James J. Weinkam]

Post by MrG

Post by James J. Weinkam

Post by MrG
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,

Post by MrG
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

Post by MrG
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

Post by MrG
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.


Mode does not

Post by MrG
change the default size of a VIO window.
Sorry for any confusion.

[James J. Weinkam]

Post by James J. Weinkam

Post by MrG

Post by James J. Weinkam

Post by MrG
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,

Post by MrG
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

Post by MrG
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

Post by MrG
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.

[Doug Bissett]

Post by James J. Weinkam
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.

All good information, but on my system, setting fMaximize to "0"
doesn't change the window position, at all. All of my VIO windows are
still opening in the same place, one on top of all the others. This is
not a real "problem", but sometimes, something will open up behind
other windows, and I have no idea that it has happened. At least when
they open in different places, I usually notice that something is
behind, and I can open it to see what it is. I remember, from playing
with this, many years ago, that there is an easy way to restore the
operation to the default, but I can't find the information about how
to do it.

[Doug Bissett]

On Tue, 22 Feb 2011 18:50:42 UTC, "Doug Bissett"

Post by Doug Bissett

Post by James J. Weinkam
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.

All good information, but on my system, setting fMaximize to "0"
doesn't change the window position, at all. All of my VIO windows are
still opening in the same place, one on top of all the others. This is
not a real "problem", but sometimes, something will open up behind
other windows, and I have no idea that it has happened. At least when
they open in different places, I usually notice that something is
behind, and I can open it to see what it is. I remember, from playing
with this, many years ago, that there is an easy way to restore the
operation to the default, but I can't find the information about how
to do it.

HAH!, I found the secret. Just DELETE the sInitialShape entry, and the
system goes back to the default operation. It doesn't seem to matter
what fMaximize is set to. It does look like the default for fMaximize
is "1".

I got that information by looking at a newly installed system, where
it had never been changed. My problem is solved, I hope this helps
someone else.

[Peter Brown]

Hi Doug

Post by Doug Bissett
On Tue, 22 Feb 2011 18:50:42 UTC, "Doug Bissett"

Post by Doug Bissett

Post by James J. Weinkam
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.

All good information, but on my system, setting fMaximize to "0"
doesn't change the window position, at all. All of my VIO windows are
still opening in the same place, one on top of all the others. This is
not a real "problem", but sometimes, something will open up behind
other windows, and I have no idea that it has happened. At least when
they open in different places, I usually notice that something is
behind, and I can open it to see what it is. I remember, from playing
with this, many years ago, that there is an easy way to restore the
operation to the default, but I can't find the information about how
to do it.

HAH!, I found the secret. Just DELETE the sInitialShape entry, and the
system goes back to the default operation. It doesn't seem to matter
what fMaximize is set to. It does look like the default for fMaximize
is "1".
I got that information by looking at a newly installed system, where
it had never been changed. My problem is solved, I hope this helps
someone else.

Where does 1 find the sInitialShape entry exactly?

Regards

Pete

[Doug Bissett]

On Wed, 23 Feb 2011 22:37:56 UTC, Peter Brown

Post by Peter Brown
Where does 1 find the sInitialShape entry exactly?
Regards
Pete

Open the registry editor (System Setup-> Registry Editor). Select
Edit-> Find and type "sInitialShape" (without the quotes), then click
Find Next. If it is there, it will find it. If it is not there, it is
likely that you never went through the procedure of shift drag drop
unshift.

Anyway, it will be in:
HINI_USER_PROFILE\Shield
if it is there.

[MrG]

Post by Doug Bissett
On Wed, 23 Feb 2011 22:37:56 UTC, Peter Brown

Post by Peter Brown
Where does 1 find the sInitialShape entry exactly?
Regards
Pete

Open the registry editor (System Setup-> Registry Editor).  Select
Edit-> Find and type "sInitialShape" (without the quotes), then click
Find Next. If it is there, it will find it. If it is not there, it is
likely that you never went through the procedure of shift drag drop
unshift.
HINI_USER_PROFILE\Shield
if it is there.
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

Thanks, Doug. Good info to have around.

[Peter Brown]

Hi Doug

Post by Doug Bissett
On Wed, 23 Feb 2011 22:37:56 UTC, Peter Brown

Post by Peter Brown
Where does 1 find the sInitialShape entry exactly?
Regards
Pete

Open the registry editor (System Setup-> Registry Editor). Select
Edit-> Find and type "sInitialShape" (without the quotes), then click
Find Next. If it is there, it will find it. If it is not there, it is
likely that you never went through the procedure of shift drag drop
unshift.
HINI_USER_PROFILE\Shield
if it is there.

Thanks.


Pete

[Jonathan de Boyne Pollard]

Post by James J. Weinkam
The value of the sInitialShape keyword consists of 9 16 bit words.

It's possibly a SWP structure as returned by the WinQueryWindowPos()

Post by James J. Weinkam
word 1: always 8700

flags, meaning
SWP_NOAUTOCLOSE|SWP_MINIMIZE|SWP_DEACTIVATE|SWP_EXTSTATECHANGE .

Post by James J. Weinkam
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.

As I alluded before, what's probably happening is that the window is
actually being set to the required position and size, but the window
itself is altering the size request on the fly before it is acted upon.
Windows can do that. It's the WM_ADJUSTWINDOWPOS message.

[John Small]

On Tue, 22 Feb 2011 23:17:47 UTC, Jonathan de Boyne Pollard

Post by Jonathan de Boyne Pollard

Post by James J. Weinkam
The value of the sInitialShape keyword consists of 9 16 bit words.

It's possibly a SWP structure as returned by the WinQueryWindowPos()
call.

I was thinking this myself. But the SWP structure uses 32-bit fields,
not 16. Perhaps there is an old 16-bit call and structure being used?

[Jonathan de Boyne Pollard]

Post by John Small

Post by Jonathan de Boyne Pollard

Post by James J. Weinkam
The value of the sInitialShape keyword consists of 9 16 bit words.

It's possibly a SWP structure as returned by the WinQueryWindowPos()
call.

I was thinking this myself. But the SWP structure uses 32-bit fields,
not 16. Perhaps there is an old 16-bit call and structure being used?

There definitely was, and it's highly probable that that would be what
would be used. It wouldn't be the first data structure in the innards
of IBM OS/2 to turn out to be the old 16-bit one.

[MrG]

Post by James J. Weinkam

Post by James J. Weinkam

Post by MrG

Post by James J. Weinkam

Post by MrG
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,

Post by MrG
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

Post by MrG
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

Post by MrG
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
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.

[Jonathan de Boyne Pollard]

It is always 80x25 chars, but changing font sizes also changes the
defaul window 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.

You're conflating two separate things, things that Windows NT makes
mildly clearer as a matter of fact. So here it is in Windows NT terms.
There's the console *buffer* size, which is the size of the character
cell array, and the console *window* size, which is the size of the view
onto that character cell array, which is as presented in a GUI window or
in full screen mode. IBM OS/2 makes it almost impossible to manipulate
the console window size other than (a) by explicitly using the frame
window widgets to resize the window, or (b) as a side-effect of
manipulating the console buffer size. In particular for (b) the window
size is forced to be no larger than the size that is necessary for
displaying the entire console buffer. So if a program such as your TUI
MP3 player resizes the console *buffer*, and forces it to 80 columns by
25 rows from a larger size, the console *window* is automatically shrunk
to fit according to what 80 by 25 cells in the current font happens to
amount to. (This is not an unusual thing for TUI programs to do. I own
several that shrink or set the console buffer size when they start up.
It's thus quite likely that your MP3 program is doing that.)

[MrG]

On Feb 23, 9:35 pm, Jonathan de Boyne Pollard <J.deBoynePollard-

Post by Jonathan de Boyne Pollard

It is always 80x25 chars, but changing font sizes also changes the
defaul window 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.

You're conflating two separate things, things that Windows NT makes
mildly clearer as a matter of fact.  So here it is in Windows NT terms.  
There's the console *buffer* size, which is the size of the character
cell array, and the console *window* size, which is the size of the view
onto that character cell array, which is as presented in a GUI window or
in full screen mode.  IBM OS/2 makes it almost impossible to manipulate
the console window size other than (a) by explicitly using the frame
window widgets to resize the window, or (b) as a side-effect of
manipulating the console buffer size.  In particular for (b) the window
size is forced to be no larger than the size that is necessary for
displaying the entire console buffer.  So if a program such as your TUI
MP3 player resizes the console *buffer*, and forces it to 80 columns by
25 rows from a larger size, the console *window* is automatically shrunk
to fit according to what 80 by 25 cells in the current font happens to
amount to.  (This is not an unusual thing for TUI programs to do.  I own
several that shrink or set the console buffer size when they start up.  
It's thus quite likely that your MP3 program is doing that.)

Good explanation. Thanks for setting me straight.