Hiding VIO window screensize changes? - OS2

This is a discussion on Hiding VIO window screensize changes? - OS2 ; [A complimentary Cc of this posting was sent to ML ], who wrote in article : > > >> As I type I've a PM app (well, ICC /B"/PMTYPE:PM" MyApp.C) restarting > >> itself maximized and VIO'ed, basicly with DosStartSession()'s ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 29 of 29

Thread: Hiding VIO window screensize changes?

  1. Re: Hiding VIO window screensize changes?

    [A complimentary Cc of this posting was sent to
    ML
    ], who wrote in article <7q7uGlQNAtBZ090yn@hotmai1.com>:
    >
    > >> As I type I've a PM app (well, ICC /B"/PMTYPE:PM" MyApp.C) restarting
    > >> itself maximized and VIO'ed, basicly with DosStartSession()'s default
    > >> example code. SYS457's, unless I make such a session the foreground
    > >> session by clicking on its eCenter "tasklist" representation.

    >
    > > Hmm, I forgot about this effect: processes started from PM processes
    > > (without windows?) are started "back" in z-order. In Perl, I can fix
    > > it

    >
    > Rating: "has no idea what he's talking about", but if WinGetFocus() (?)
    > isn't a working fix, cannot the same be achieved with virtual keys? For
    > example with ? I would expect that to have the
    > same result as clicking on the eCenter button of the app, getting all
    > thinkable kinds of focus (in time?) properly.


    Did you run this command? Alt-Tab does not help; window-highlights
    and z-order change, but when you come back, Ctrl-c still does not
    work. I need an actual mouse click to make keyboard work...

    Puzzled,
    Ilya

  2. Re: Hiding VIO window screensize changes?


    > Did you run this command? Alt-Tab does not help; window-highlights
    > and z-order change, but when you come back, Ctrl-c still does not
    > work. I need an actual mouse click to make keyboard work...


    I think my SYS457.C-app had the same problem, but due to the recursive
    construction of that app I haven't tried nor thought about .

    The app I'll run next will start minimized, perhaps that bypasses the
    SYS457 at startup. After all, once my app ran, it went recursivly nuts,
    so I hope trying this minimized will be considered as background by the
    "session manager", and when it runs I hope maximizing it won't affect
    the running status (which didn't seem to require a mouse click once I
    got SYS457.C to run properly, but right after that I rebooted to stop
    SYS457.EXE's restarting itself a zillion times and to save my work).

    In a nutshell:

    - start my "PM" app (little more than just "/PMTYPE:PM")
    - restart my app with an equivalent of START /MIN /WIN (VIO)
    - hope to bypass the assumed "session manager" SYS457-initialization
    step that way
    - maximize my VIO app, hoping to see a 'able app, instead of
    a SYS457 error or an app that has to be awakened by a mouse

    But if failed, it's not unlikely fooling the session manager
    fails too.



    ---

  3. Re: Hiding VIO window screensize changes?


    > DosQProcStatus();


    > Google is the answer to your next question. :-)


    FTR, http://www.howzatt.demon.co.uk/articles/05aug92.html (bottom of
    the page for the sample output of this PROGLIST.C) displays what I'm
    looking for:


    PID PPID Name
    002b 0002 C:\OS2\CMD.EXE
    0145 002b C:\ROGER\ARTICLES\PROGLIST.EXE


    The parent process (PPID) of PROGLIST.EXE is 002b, the PID of CMD.EXE.



    ---

  4. Re: Hiding VIO window screensize changes?


    >> DosQProcStatus();


    > DosQuerySysState(); preferred as it's a 32 bit function.


    Just a remark: perhaps not with backward compatibility in mind? I read
    Warp 4 FP13 somewhere, but AFAIK FP13 isn't available for all language
    versions of Warp 4. I think FP9 (Y2K-related) is the latest generic FP
    w.r.t Warp 4, and maybe the next generic (without SWC) version is eCS.
    Requiring Warp 4 FP13 can come down to dropping OS/2-support, except
    for the happy few with eighter FP13-availability or users not disliking
    to face "Libertados speicher aussi (si/nee)?" once in a while.



    ---

  5. Re: Hiding VIO window screensize changes?


    >> REM Switch to 40x25
    >> MODE 40,25
    >> REM Do something, e.g.display C:\AUTOEXEC.BAT
    >> TYPE C:\AUTOEXEC.BAT
    >> REM Finally restore the previous screen setting, e.g. 80x25
    >> MODE 80,25


    > Still unclear. Do you want this to work in any VIO window, or in
    > specially created VIO windows?


    Would you expect the above to fail, no matter how you started it? The
    only mentioned requirement is "MODE 40,25" (because 40/2<25, and this
    VIO/video-mode is also available fullscreen). You can reduce the app to
    "MODE 40,25", so there isn't really that much left over to be unclear.

    BTW, minimizing and maximizing isn't going to work. Technically it may
    work, but I fear it will look rather ugly when started fullscreen, due
    to it being a PM app. I guess making it always look good requires more
    than a stand-alone *.EXE, if it would work properly at all.



    ---

  6. Re: Hiding VIO window screensize changes?


    > I guess making it always look good requires more than a stand-alone
    > *.EXE, if it would work properly at all.


    FWIW, if a DosBox-project ever gets to an eCS- or OS2Box-project, it's
    better to not only support initial screensize settings, but also to
    allow for different screensizes depending on the environment.

    E.g. YARN (textmode newsreader) supports all possible screensizes. It's
    thinkable one wants 80x19 in a VIO window (that doesn't cover the whole
    screen), but one wants to use 80x43 in a fullscreen session (keeping a
    line length of 80, but displaying more lines per article).

    This YARN-"problem" obviously is already solvable, but that'll require
    at least 2 apps (YARN.CMD, YARN.EXE) and includes the unneeded switch
    from the initial screensize in use to the desired initial screensize.



    ---

  7. Re: Hiding VIO window screensize changes?

    On Sat, 11 Aug 2007 08:39:07 UTC, spamgate@hotmai1.com (ML) wrote:

    >
    > >> DosQProcStatus();

    >
    > > DosQuerySysState(); preferred as it's a 32 bit function.

    >
    > Just a remark: perhaps not with backward compatibility in mind? I read
    > Warp 4 FP13 somewhere, but AFAIK FP13 isn't available for all language
    > versions of Warp 4. I think FP9 (Y2K-related) is the latest generic FP
    > w.r.t Warp 4, and maybe the next generic (without SWC) version is eCS.
    > Requiring Warp 4 FP13 can come down to dropping OS/2-support, except
    > for the happy few with eighter FP13-availability or users not disliking
    > to face "Libertados speicher aussi (si/nee)?" once in a while.


    WARP4 FP12 is the most stable fixpack WARP has ever seen.
    FP13 is the most worse fixpack WARP has ever seen

    Since FP10 you needs a device driver fixpack as since that no device
    drivers are included into the base fixpack.

    FP12 - most stable FP OS/2 has ever seen
    FP13 - released to merge WARP4 with WSoD - but failed
    FP14 - try to fix the worse FP13
    FP15 - coming back to stability of FP10
    and last FP released to public

    MCP1 - consolidate Fixes as installable system
    too many different fixes and fixpacks, makes it unhandy
    to get an install without modifying installation diskettes
    MCP2 - fixpup MCP1
    something in MCP1 was broken, giving problems on install
    on at that time current hardware

    MCP2 - FP4 - fixup lots of things, increased stability since FP15
    FP5 - try to beat instability of FP13

    eCS 1.0 - OEM label of MCP1, fixed installer
    1.1 - MCP2, fixed MMPM, installer rewritten from
    scratch
    1.2 - fixed MCP2, again installer rewritten from
    scratch,
    fixed network install
    1.2R - like 1.2 but install fixed to be able to
    get installation on 64 bit CPU successfull
    instead general boot failture on any try.

    eCS 2.0 - late beta, not available yet.

    --
    Tschau/Bye
    Herbert

    Visit http://www.ecomstation.de the home of german eComStation
    eComStation 1.2R Deutsch ist da!

  8. Re: Hiding VIO window screensize changes?


    > FTR, http://www.howzatt.demon.co.uk/articles/05aug92.html (bottom of
    > the page for the sample output of this PROGLIST.C) displays what I'm
    > looking for:


    FTR again, actually trying this code resulted in a rc of (IIRC) 111. I
    didn't bother to find some "unofficial documentation" for this API, so
    I decided to not use it because of rc!=0 and it wasn't mission-critical
    anyway. Thanks anyway, it was what I was looking for.



    ---

  9. Re: Hiding VIO window screensize changes?


    >> AFAIK FP13 isn't available for all language versions of Warp 4.


    > WARP4 FP12 is the most stable fixpack WARP has ever seen.


    In a way that's not true, e.g. there's no FP12 for several languages
    to be seen because it doesn't exist. Y(English, German)MMV! Then FP9
    is the latest "publicly available worldwide" version of OS/2 Warp 4.

    > MCP1


    I tend to skip those. When I read "requires FP10+", I cannot expect
    anyone to have that, so then I read "requires eCS" instead of that.

    Technically "FP10+" can be 100% perfect, IRL it can be irrelevant.
    You may have FP12 (available in your native language and) installed,
    you may have a SWC subscription, but after FP9 the next worldwide
    installable version indeed is eCS 1.x. So "requires FP10+" doesn't
    apply to all OS/2-users, and often comes down to "requires eCS".

    > eCS 2.0 - late beta, not available yet.


    I'm waiting for it! I've heard rumours it'll provide PCMCIA-support
    (and a bit more) for IBM Thinkpad X20's. People reported to have the
    PCMCIA-part working, but I tried their latest drivers with 1.2 (no
    1.2R in all languages available, just like with FP9) without any
    progress worth mentioning (albeit typically I don't use "eCSMT", so
    other unupdated eCS-components may play a role here too).



    ---

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2