Hiding VIO window screensize changes? - OS2

This is a discussion on Hiding VIO window screensize changes? - OS2 ; The following *.CMD-file demonstrates the underlying problem: MODE 40,25 PAUSE MODE 80,25 When started from the OS/2-prompt in a (80x25) VIO window, being able to see the changes of the screensize is okay. But when this *.CMD-file is started as ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 29

Thread: Hiding VIO window screensize changes?

  1. Hiding VIO window screensize changes?


    The following *.CMD-file demonstrates the underlying problem:

    MODE 40,25
    PAUSE
    MODE 80,25

    When started from the OS/2-prompt in a (80x25) VIO window, being able to
    see the changes of the screensize is okay.

    But when this *.CMD-file is started as a WPS object, there's no need to
    start with a screensize of 80x25, and there's also no need to restore the
    screensize to 80x25, i.e. hiding the visible screensize changes.

    I assume I can avoid the visible restoring of the screensize to 80x25 by
    using an argument ("MY.EXE NoRestore"), but for one that won't work with
    any WPS object representing MY.EXE by default.

    Is there a trick/way to distinguish between the way an app is started
    (using a WPS object vs. using the OS/2-prompt)? This may be a way to
    avoid the visible restore/resize to 80x25 when a WPS object was used.

    Next, using a WPS object to start the app, is there a trick/way to start
    (just this app) with a screensize of 40x25 instead of 80x25, hiding the
    first visible change/resize to 40x25? I guess morphing to a PM app won't
    help, or would that concept allow for e.g. a minimized change to 40x25?



    ---

  2. Re: Hiding VIO window screensize changes?

    ML wrote:
    > Is there a trick/way to distinguish between the way an app is started
    > (using a WPS object vs. using the OS/2-prompt)? This may be a way to
    > avoid the visible restore/resize to 80x25 when a WPS object was used.


    Check for your parent process.


    > Next, using a WPS object to start the app, is there a trick/way to start
    > (just this app) with a screensize of 40x25 instead of 80x25, hiding the
    > first visible change/resize to 40x25?


    As far as I know there is no setting like this for VIO windows. This is
    a WinXX-only feature.

    > I guess morphing to a PM app won't
    > help, or would that concept allow for e.g. a minimized change to 40x25?


    PM apps do not have a console window. So the question makes no sence here.

    But yes, a PM app can start it's window in any arbitrary size at any
    arbitrary location. You have full control here.


    Marcel

  3. Re: Hiding VIO window screensize changes?


    >> Is there a trick/way to distinguish between the way an app is started
    >> (using a WPS object vs. using the OS/2-prompt)? This may be a way to
    >> avoid the visible restore/resize to 80x25 when a WPS object was used.


    > Check for your parent process.


    Allright, 50% solved.

    >> Next, using a WPS object to start the app, is there a trick/way to start
    >> (just this app) with a screensize of 40x25 instead of 80x25, hiding the
    >> first visible change/resize to 40x25?


    > As far as I know there is no setting like this for VIO windows. This
    > is a WinXX-only feature.


    It isn't that important, but what I was thinking about is a "PM app",
    which just starts this VIO window minimized, change the screensize to
    40x25, maximizes the VIO window and morph back into a VIO app.

    >> I guess morphing to a PM app won't help, or would that concept
    >> allow for e.g. a minimized change to 40x25?


    > PM apps do not have a console window. So the question makes no
    > sence here.


    The reverse works, by setting DosGetInfoBlocks() pib_ultype. Hence the
    thought about the reversed situation, a "PM app" that actually is a VIO
    app and just uses the PM-part to minimize the VIO app during resizing.
    Well, sounds like that requires two apps, the PM launcher and the VIO
    app. I was hoping to be able to glue those parts together. When run,
    restart itself with the right environment. Pseudo-code:

    START /MIN START -PM_40x25_init
    START /MAX START -VIO

    So it starts, creates a minimized 40x25 VIO window, and next restarts
    itself maximized as a VIO app and continues at the right point (based
    on the argument "-VIO", basicly just skipping the change to 40x25).



    ---

  4. Re: Hiding VIO window screensize changes?

    [A complimentary Cc of this posting was sent to
    ML
    ], who wrote in article :
    > MODE 40,25
    > PAUSE
    > MODE 80,25
    >
    > When started from the OS/2-prompt in a (80x25) VIO window, being able to
    > see the changes of the screensize is okay.
    >
    > But when this *.CMD-file is started as a WPS object, there's no need to
    > start with a screensize of 80x25, and there's also no need to restore the
    > screensize to 80x25, i.e. hiding the visible screensize changes.
    >
    > I assume I can avoid the visible restoring of the screensize to 80x25 by
    > using an argument ("MY.EXE NoRestore"), but for one that won't work with
    > any WPS object representing MY.EXE by default.
    >
    > Is there a trick/way to distinguish between the way an app is started
    > (using a WPS object vs. using the OS/2-prompt)?


    %WP_OBJHANDLE% is set by WPS when it starts the application; however,
    since it is preserved by applications starting THEIR kids, this may be
    not that useful for you...

    > Next, using a WPS object to start the app, is there a trick/way to start
    > (just this app) with a screensize of 40x25 instead of 80x25, hiding the
    > first visible change/resize to 40x25?


    Sure; just do as in PM: start minimized, set the size, then restore.

    Hope this helps,
    Ilya

  5. Re: Hiding VIO window screensize changes?

    ML wrote:
    > > PM apps do not have a console window. So the question makes no
    > > sence here.

    >
    > The reverse works, by setting DosGetInfoBlocks() pib_ultype. Hence the
    > thought about the reversed situation, a "PM app" that actually is a VIO
    > app and just uses the PM-part to minimize the VIO app during resizing.
    > Well, sounds like that requires two apps, the PM launcher and the VIO
    > app. I was hoping to be able to glue those parts together. When run,
    > restart itself with the right environment. Pseudo-code:
    >
    > START /MIN START -PM_40x25_init
    > START /MAX START -VIO


    This won't help you much. The PM-APP property is part of the executable
    header. In fact it only avoids the creation of the default VIO window
    where the redirected stdin/stdout/stderr is handled.

    Any VIO app can open PM windows and vice versa. Look for VioCreatePS,
    VioAssociate, VioWrtTTY and KbdCharIn and so on. But you will loose the
    convenient mapping to the standard file handles. This still won't enable
    you to minimize your window. But you can create it with the right
    initial size.


    > So it starts, creates a minimized 40x25 VIO window, and next restarts
    > itself maximized as a VIO app and continues at the right point (based
    > on the argument "-VIO", basicly just skipping the change to 40x25).


    Once you managed to get the window handle of your VIO window you can do
    this. But I don't know a way to get this handle. And the name in the
    switch list is not unique.
    The VIO functions and the window manager functions for emulated video
    modes are completely unrelated.


    Marcel

  6. Re: Hiding VIO window screensize changes?

    [A complimentary Cc of this posting was sent to
    ML
    ], who wrote in article :
    > Well, sounds like that requires two apps, the PM launcher and the VIO
    > app. I was hoping to be able to glue those parts together. When run,
    > restart itself with the right environment. Pseudo-code:
    >
    > START /MIN START -PM_40x25_init
    > START /MAX START -VIO
    >
    > So it starts, creates a minimized 40x25 VIO window, and next restarts
    > itself maximized as a VIO app and continues at the right point (based
    > on the argument "-VIO", basicly just skipping the change to 40x25).


    Why so baroque? Just start minimized, reset the size, then
    un-minimize yourselves. E.g.,

    start /c/min perl -MOS2::Process -MOS2::Process=WM_SYSCOMMAND,SC_RESTORE,MPFROMSHORT -we "scrsize_set 8; PostMsg process_hwnd, WM_SYSCOMMAND, MPFROMSHORT SC_RESTORE; sleep 20"

    Hope this helps,
    Ilya

  7. Re: Hiding VIO window screensize changes?


    >> START /MIN START -PM_40x25_init
    >> START /MAX START -VIO


    >> So it starts, creates a minimized 40x25 VIO window, and next restarts
    >> itself maximized as a VIO app and continues at the right point (based
    >> on the argument "-VIO", basicly just skipping the change to 40x25).


    > Why so baroque? Just start minimized, reset the size, then
    > un-minimize yourselves. E.g.,


    > start /c/min perl -MOS2::Process -MOS2::Process=WM_SYSCOMMAND,SC_RESTORE,MPFROMSHORT -we "scrsize_set 8; PostMsg process_hwnd, WM_SYSCOMMAND, MPFROMSHORT SC_RESTORE; sleep 20"


    How can a single app in a VIO environment (CMD.EXE-session, controlled
    WPS object or uncontrolable WPS object) always start itself minimized?

    The controlled WPS object may be easy (e.g. using START), but I guess
    the other cases may require distributing 2 apps. Maybe a PMMyApp.EXE
    which just initially launches the real MyVioApp.FOO minimized. Or did
    I overlook e.g. some /DETACH or /MIN linker switch?

    BTW, with "uncontrolable WPS object" I mean a basic WPS file object
    pointing to MyApp.EXE, but without that WPS object being created by my
    installer (which actually could use "START /MIN MyApp.EXE").



    ---

  8. Re: Hiding VIO window screensize changes?


    > Once you managed to get the window handle of your VIO window you
    > can do this. But I don't know a way to get this handle.


    My NewView seems to be broken somehow, but I think DosGetInfoBlocks()
    can provide a PID of the parent process. If that's right indeed, how
    can I get the name matching the PID (like eCS' CAD-Popup can show the
    name PMSHELL.EXE instead of just a rather meaningless PID number)? If
    that would work, I guess then it's safe to assume PMSHELL.EXE is what
    I think it is.

    BTW, if that's too tricky, forget about it, it isn't that important in
    this case, unless one wants to share such knowledge FTR...



    ---

  9. Re: Hiding VIO window screensize changes?

    [A complimentary Cc of this posting was sent to
    ML
    ], who wrote in article :

    > > start /c/min perl -MOS2::Process -MOS2::Process=WM_SYSCOMMAND,SC_RESTORE,MPFROMSHORT -we "scrsize_set 8; PostMsg process_hwnd, WM_SYSCOMMAND, MPFROMSHORT SC_RESTORE; sleep 20"

    >
    > How can a single app in a VIO environment (CMD.EXE-session, controlled
    > WPS object or uncontrolable WPS object) always start itself minimized?
    >
    > The controlled WPS object may be easy (e.g. using START), but I guess
    > the other cases may require distributing 2 apps. Maybe a PMMyApp.EXE
    > which just initially launches the real MyVioApp.FOO minimized. Or did
    > I overlook e.g. some /DETACH or /MIN linker switch?
    >
    > BTW, with "uncontrolable WPS object" I mean a basic WPS file object
    > pointing to MyApp.EXE, but without that WPS object being created by my
    > installer (which actually could use "START /MIN MyApp.EXE").


    Unfortunately, I can't parse your questions. It may be easier to
    understand if you would write down explicitly the list of your requirements.

    Yours,
    Ilya

  10. Re: Hiding VIO window screensize changes?

    On Thu, 2 Aug 2007 22:51:39 UTC, spamgate@hotmai1.com (ML) wrote:

    >
    > > Once you managed to get the window handle of your VIO window you
    > > can do this. But I don't know a way to get this handle.

    >
    > My NewView seems to be broken somehow, but I think DosGetInfoBlocks()
    > can provide a PID of the parent process. If that's right indeed, how
    > can I get the name matching the PID (like eCS' CAD-Popup can show the
    > name PMSHELL.EXE instead of just a rather meaningless PID number)? If
    > that would work, I guess then it's safe to assume PMSHELL.EXE is what
    > I think it is.
    >
    > BTW, if that's too tricky, forget about it, it isn't that important in
    > this case, unless one wants to share such knowledge FTR...


    pipe the result of pstat into a queue and read that that queue to get
    the data you needs.

    Type help pstat to see which option(s) helps you.


    --
    Tschau/Bye
    Herbert

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

  11. Re: Hiding VIO window screensize changes?

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Ilya Zakharevich
    ], who wrote in article :
    > Unfortunately, I can't parse your questions. It may be easier to
    > understand if you would write down explicitly the list of your requirements.


    I see that you do not care. Nevertheless, one possible solution is to
    make your application PM, and make it immediately restart itself in a
    minimized VIO window (as in "start /win/min").

    Hope this helps,
    Ilya

  12. Re: Hiding VIO window screensize changes?


    >> Unfortunately, I can't parse your questions. It may be easier to
    >> understand if you would write down explicitly the list of your
    >> requirements.


    > I see that you do not care.


    Don't jump to wrong conclusions. Never mind...

    One down, five to go. "Problems" are/were switching to 40x25 and back
    to 80x25. Starting point using a WPS object created by me, the switch
    back to 80x25 is now skipped. One down. To go now: all switches from
    80x25 to 40x25, and all switches from 40x25 to 80x25 when CMD.EXE or
    a regular WPS file object representing MyApp.EXE was used.

    > Nevertheless, one possible solution is to make your application PM,
    > and make it immediately restart itself in a minimized VIO window
    > (as in "start /win/min").


    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. Excuse
    me for a broken NewView, but is DosStartSession() what you meant with
    "make it immediately restart itself in a minimized VIO window"?

    FWIW, here's SYS457.C as-is, for one maximized instead of minimized.
    To be used if you wanted to reboot anyway. Have another PM app open,
    e.g. E.EXE. While typing in E, select a eCenter "My App", and if you
    get bored or scared switch back to E.

    It ain't pretty (yet), but it just may work. And obviously this is far
    from finished or a working situation. BTW, parsing PSTAT's output can
    be an option too (to find the parent's name->PMSHELL), but this isn't
    an important problem, so the cure would be worser than the illness.

    /* Compiled with: ICC /B"/PMTYPE:PM" SYS457.C */

    #define INCL_DOSERRORS
    #define INCL_DOSPROCESS
    #define INCL_DOSSESMGR

    #include
    #include

    int main(int argc,char *argv[])
    {
    APIRET rc=NO_ERROR;
    PID pid=0;
    PTIB ptib;
    PPIB ppib;
    PSZ PgmTitle="My App",PgmName="VIO.EXE";
    STARTDATA SData={0};
    UCHAR achObjBuf[256]={0};
    ULONG ulSessID=0;

    SData.Length=sizeof(STARTDATA);
    SData.Related=SSF_RELATED_INDEPENDENT;
    SData.FgBg=SSF_FGBG_FORE;
    SData.TraceOpt=SSF_TRACEOPT_NONE;
    SData.PgmTitle=PgmTitle;
    SData.PgmName=PgmName;
    SData.PgmInputs="Arg_1";
    SData.TermQ=0;
    SData.Environment=0;
    SData.InheritOpt=SSF_INHERTOPT_SHELL;
    SData.SessionType=SSF_TYPE_WINDOWABLEVIO;
    SData.IconFile=0;
    SData.PgmHandle=0;
    SData.PgmControl=SSF_CONTROL_VISIBLE|SSF_CONTROL_M AXIMIZE;
    SData.InitXPos=30;
    SData.InitYPos=40;
    SData.InitXSize=200;
    SData.InitYSize=140;
    SData.Reserved=0;
    SData.ObjectBuffer=achObjBuf;
    SData.ObjectBuffLen=(ULONG)sizeof(achObjBuf);

    DosGetInfoBlocks(&ptib,&ppib);
    ppib->pib_ultype=2;

    rc=DosStartSession(&SData,&ulSessID,&pid);
    if (rc!=NO_ERROR)
    {
    printf("DosStartSession error: return code=%u\n",rc);
    return 1;
    }

    printf("Point 1\n");
    printf("Point 2\n");

    DosSleep(3000UL);

    return 0;
    }



    ---

  13. Re: Hiding VIO window screensize changes?

    [A complimentary Cc of this posting was sent to
    ML
    ], who wrote in article :
    > One down, five to go. "Problems" are/were switching to 40x25 and back
    > to 80x25. Starting point using a WPS object created by me, the switch
    > back to 80x25 is now skipped. One down. To go now: all switches from
    > 80x25 to 40x25, and all switches from 40x25 to 80x25 when CMD.EXE or
    > a regular WPS file object representing MyApp.EXE was used.


    Sorry, I can't parse this. One way to make a better exposition is to
    list (one-by-one) what you want to do, what you tried, what you saw
    when you tried, and what you expected to see when you tried...

    > > Nevertheless, one possible solution is to make your application PM,
    > > and make it immediately restart itself in a minimized VIO window
    > > (as in "start /win/min").

    >
    > 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. Excuse
    > me for a broken NewView, but is DosStartSession() what you meant with
    > "make it immediately restart itself in a minimized VIO window"?


    One can do it with DosStartSession(), but the simpler way to start
    developing is to do what I wrote:

    start /win/min

    > It ain't pretty (yet), but it just may work. And obviously this is far
    > from finished or a working situation. BTW, parsing PSTAT's output can
    > be an option too (to find the parent's name->PMSHELL), but this isn't
    > an important problem, so the cure would be worser than the illness.


    With perl, it is as easy as

    perl -MOS2::Proc -wle "($proc) = proc_info; $ppid = $proc->[0]{ppid};
    ($pproc) = proc_info($ppid); print $pproc->[0]{module_name}"

    but proc_info() involves a lot of parsing of output of
    DosQuerySysState() under the hood...

    Hope this helps,
    Ilya

  14. Re: Hiding VIO window screensize changes?

    [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 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 via

    perl__ -wle "system qw(cmd /c), @ARGV"
    start /win/n/min
    perl -MOS2::Process -MOS2::Process=WM_SYSCOMMAND,SC_RESTORE,MPFROMSHORT
    -we "scrsize_set 8; $w = process_hwnd; $w = TopLevel $w;
    PostMsg $w, WM_SYSCOMMAND, MPFROMSHORT SC_RESTORE; sleep 1;
    {my $lock = OS2::localMorphPM->new; FocusWindow_set $w};
    sleep 20"

    (toplevel perl__ is a PM application, then it starts another copy of
    perl in a VIO window via CMD.EXE). The new window is in foreground
    (and both TopLevel and sleep 1 calls are not needed), but it does not
    take keyboard focus (it is not killable with C-c)!

    Anyone with an idea why this window would not take keyboard focus? Is
    explicit activation needed as well? Hmm, "ActiveWindow_set $w" does
    not help anyway... I need to click the mouse before C-c works...

    Thanks,
    Ilya

  15. Re: Hiding VIO window screensize changes?


    >> BTW, if that's too tricky, forget about it, it isn't that important in
    >> this case, unless one wants to share such knowledge FTR...


    > pipe the result of pstat into a queue and read that that queue to
    > get the data you needs.


    Thanks, but I'll rate that too tricky. For one due to too much overhead
    and re-inventions required to solve a minor problem (the app already is
    exceeding the size of the original one by far, not 100% avoidable with
    additional optimization for OS/2).

    Nevertheless thanks for the pointer! Unless there's a PSTAT API, but I
    bet programmers already ought to be satisfied with 'em PID numbers. :-/



    ---

  16. Re: Hiding VIO window screensize changes?

    On Mon, 6 Aug 2007 22:43:38 UTC in comp.os.os2.programmer.misc,
    spamgate@hotmai1.com (ML) wrote:

    > Nevertheless thanks for the pointer! Unless there's a PSTAT API, but I
    > bet programmers already ought to be satisfied with 'em PID numbers. :-/


    DosQProcStatus();

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

    --
    Trevor Hemsley, Brighton, UK
    Trevor dot Hemsley at ntlworld dot com

  17. Re: Hiding VIO window screensize changes?

    On Mon, 06 Aug 2007 18:53:01 -0500, Trevor Hemsley
    wrote:

    > On Mon, 6 Aug 2007 22:43:38 UTC in comp.os.os2.programmer.misc,
    > spamgate@hotmai1.com (ML) wrote:
    >
    >> Nevertheless thanks for the pointer! Unless there's a PSTAT API, but I
    >> bet programmers already ought to be satisfied with 'em PID numbers. :-/

    >
    > DosQProcStatus();


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

  18. Re: Hiding VIO window screensize changes?


    > Sorry, I can't parse this. One way to make a better exposition is
    > to list (one-by-one) what you want to do


    Essentially, my app would do this when it was a MyApp.[BAT|CMD]-file:

    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

    "Problems": visible MODE switches. And an unrelated one: with a buggy
    video driver (not SNAP, but the original one for IBM ThinkPads 380's,
    385's, 560's and 600's) there's a problem with the cursor in fullscreen
    modes. But back to the MODE-related issues:

    First of all, IMHO there's no good reason to require an environment or
    else don't execute "TYPE C:\AUTOEXEC.BAT". Next, another alternative
    could be to distribute a single (Rexx) INSTALL.CMD, which creates my
    own WPS objects and creates the file MyApp.EXE. But I prefer to avoid
    work-arounds here, for one because the problem isn't enormous. If it
    doesn't get any better, "TYPE C:\AUTOEXEC.BAT" will keep working.
    Other possible work-arounds are to not use the whole 80x25 screen, or
    start with a 80x25 "logo" (just like some PM apps do) or use a graphic
    mode. But this isn't about diving into Dive, and the original app (over
    20 years old, a learning project port from memory) depends on 40x25.

    Suffix "a": the equivalent of "MODE 40,25"
    Suffix "b": the equivalent of "MODE 80,25"

    Prefix "1": type MyApp.EXE in a fullscreen CMD.EXE session
    Prefix "2": type MyApp.EXE in a VIO CMD.EXE session
    Prefix "3": use a regular WPS file object representing MyApp.EXE (VIO)
    Prefix "4": use my own WPS object representing MyApp.EXE (fullscreen)
    Prefix "5": use my own WPS object representing MyApp.EXE (VIO)

    Covered so far are the situations (prefix/suffix-notation) 1a, 1b, 4a,
    4b and 5b. It's not an ugly looking issue w.r.t. 1a, 1b, 4a and 4b. In
    case of 4b and 5b I use a parameter to skip switching back to 80x25.

    Remaining: 2a, 2b, 3a, 3b, 4a and 5a. When I can detect PMSHELL is the
    parent process, situation 3b is also covered (comparable with both 4b
    and 5b, switching back to 80x25 is superfluous and can be skipped). I
    guess situation 2b is unavoidable, I consider restoring the screen to
    be best practice.

    Remaining: 2a, 3a, 4a and 5a. The only reasonable approach indeed seems
    to be a minimized switch to 40x25, followed by maximizing the session.
    In theory it may perhaps also be possible to adjust the VIO font, but
    if that would work it's a lot of overhead for "TYPE C:\AUTOEXEC.BAT".

    > One can do it with DosStartSession(), but the simpler way to start
    > developing is to do what I wrote:


    > start /win/min


    Okay, I got the message. I'll start playing with START, hope to end up
    with a good solution, and after that I'll start thinking about avoiding
    to depend on START (I've experience with porting REXX apps to PM and/or
    VIO output, but a PMREXX bug made those efforts useless because PMREXX
    no longer returns PMREXX as the environment, so basicly I cannot select
    between "SAY " and/or "RxMessageBox " depending on the
    REXX Address()-environment used to run those dual-mode REXX apps :-/).

    > With perl, it is as easy as


    > perl -MOS2::Proc -wle "($proc) = proc_info; $ppid = $proc->[0]{ppid};
    > ($pproc) = proc_info($ppid); print $pproc->[0]{module_name}"


    > but proc_info() involves a lot of parsing of output of
    > DosQuerySysState() under the hood...


    Oh, when you'ld have to issue the command "MODE 132,43" to make it a
    perl-one-liner here, it typically involves a lot of <...>! ;-)

    I'll take a look at that API. It took a while to get a NewView-update,
    I'm doing most of the work involved while travelling, and searching for
    "parent process" just resulted in an overload of hard-to-read hits.
    That's sorted out now, at least I hope so, so I'll look at this. And
    when IMO the overhead becomes to huge, I can still decide to forget
    about solving case "3b" (while preferring an API above parsing output
    of PSTAT).

    BTW, the app is finished, other than the problems mentioned above and
    another (minor) novice detail. I could post it here, but an earlier
    example is a better demonstration of the bad look of the switches:

    /* VIO_DEMO.CMD */;DO i=80 TO 40 BY -1;"@MODE" i||",25";END i;EXIT

    It may look better with a fast pc and an excellent video driver, but I
    also keep less perfect hardware situations in mind. BTW, over 20 years
    ago my next project back then was a state-of-the-art DTP app. There's
    some progress going on, but I won't rewrite that app. IIRC part of the
    fun used to be less than 3KB of memory for the BASIC app in a graphic
    mode, 100% joystick controlled: I no longer own a joystick... :-)

    Anyway, thanks for the input/pointers!



    ---

  19. Re: Hiding VIO window screensize changes?


    >> 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.



    ---

  20. Re: Hiding VIO window screensize changes?

    [A complimentary Cc of this posting was sent to
    ML
    ], who wrote in article :
    > Essentially, my app would do this when it was a MyApp.[BAT|CMD]-file:
    >
    > 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?

    > "Problems": visible MODE switches. And an unrelated one: with a buggy
    > video driver (not SNAP, but the original one for IBM ThinkPads 380's,
    > 385's, 560's and 600's) there's a problem with the cursor in fullscreen
    > modes. But back to the MODE-related issues:


    [big incomprehensible chunk skipped...]

    > > With perl, it is as easy as

    >
    > > perl -MOS2::Proc -wle "($proc) = proc_info; $ppid = $proc->[0]{ppid};
    > > ($pproc) = proc_info($ppid); print $pproc->[0]{module_name}"

    >
    > > but proc_info() involves a lot of parsing of output of
    > > DosQuerySysState() under the hood...

    >
    > Oh, when you'ld have to issue the command "MODE 132,43" to make it a
    > perl-one-liner here, it typically involves a lot of <...>! ;-)


    One-liner is what fits into one shell's command (and does not use
    external scripts). On OS/2, this limits one-liners by 32k characters;
    broken shells may impose some additional restrictions...

    It is a pity that a lot of otherwise good programming languages do not
    allow providing a program on the command line (e.g., they may depend
    on line feeds etc). The idea of a one-liner is a great simplification
    to many tasks. Of course, with broken shells (such as typical OS/2
    ones) one should trade-off readability vs ease of cut-and-paste.
    Above, I opted for c&p (put whole command on one line).

    Hope this helps,
    Ilya

+ Reply to Thread
Page 1 of 2 1 2 LastLast