Firefox/4.0b8pre SeaMonkey/2.1b2pre   
   From: "James J. Weinkam"    
      
   James J. Weinkam wrote:   
   > MrG wrote:   
   >> On Feb 20, 12:07 am, "James J. Weinkam" 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.   
      
      
   --- Internet Rex 2.31   
    * Origin: Aioe.org NNTP Server (1:261/20.999)