Announcement

Collapse
No announcement yet.

Programmable minimize

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Programmable minimize

    Is it possible to minimize a PBDOS application by program?
    ie simulate the Windows key.

    ------------------

  • #2
    You can't simulate the Windows key, at least not as far as I know. Even if you could it would not be reliable because of Windows "foreground" issues.

    One alternative would be my company's DOSBox product, which can be used to add Windows features like window-state-control to DOS applications. For more information, click on one of the links below and navigate to "DOSBox".

    -- Eric Pearson, Perfect Sync Software

    ------------------
    Perfect Sync Development Tools
    Perfect Sync Web Site
    Contact Us: mailto:[email protected][email protected]</A>
    "Not my circus, not my monkeys."

    Comment


    • #3
      Thanks Eric I will look at that. The reason I ask is that I have
      written a GUI for DOS suite all running in SCREEN 12. As PBDOS
      graphics do not run in a DOS Window the only way to minimize
      is to use the Windows key or ALT-ESC etc and I would like to
      put a minimize button at the top right of the screen like
      Windows.


      ------------------

      Comment


      • #4
        If you are a brave and hearty soul with a hidden desire for a huge
        amount of work I think you can do it.

        What you do is tailor write the video output of the program to one
        of the alternate screen pages in memory. When I wrote my version of
        this for my HELP screen popups, I think I recall that there are
        actually six pages of screen memory for DOS video. We know and love
        the first one. It's where we write, in memory, for all that we normally
        see on the screen for TEXT characters, you know, 80 columns wide and
        25 lines deep in 'normal' mode.

        This video memory is actually arranged in a 'page' with two byte for
        every letter on the line. One byte is the actual graphic form which
        you see on the screen. The other is an attribute byte. One of the
        ways you can use other pages of this video memory is to simply chop
        out an area of what is on display and slush it up in one of the other
        pages. Actually, such a technique is very fast and effective, even in
        good old DOS as memory copies are very fast. What you are doing is
        reading that memory for that part of the image and block copying it
        up into one of the other page areas for holding. A full screen of
        DOS text thus contains 4000 bytes of data, arranged in exactly the
        geometric order of what you see on the screen.

        You use a DEF SEG technique to approach the video page you know and
        love already. Then you PEEK at each of the wanted bytes in the wanted
        places according to what chunk of the page you want to COPY elsewhere.
        Since that segment has more than 4000 bytes of available space in it,
        you just --- OFFSET --- upward numerically where you want to move the
        data and go do it.

        [source]
        IF GFX% <> 3 THEN ' Normal IBM video memory area
        DEF SEG = &HB800 ' Where it is in memory
        ELSE ' Old Heathkit Z100 computer!
        DEF SEG = &HB000 ' Where Gordon Letwin originally put it!
        END IF
        FOR NZ% = HCLL% TO HCLR% ' You pick the chunk
        HXX% = PEEK(NZ%) ' You take it from here
        POKE (NZ% + 8000), HXX% ' You put it there
        NEXT NZ%
        [/source]

        I left my old segment place in there for humor here! Gordon Letwin
        drafted this on the old HeathKit platform in Benton Harbor for Heath
        before he got hired away by Bill Gates and it became where it is
        today. Certain of my programs will still actually run on an Heathkit
        Z100 for proof of concept purposes and intellectual benchmarking of
        who thought it up what first here, if needed .....

        Code written in 1980 and earlier is still cheerfully running today ..

        Now, once you get this done, you have a way to store a screen or a
        whole chunk of screen all nice and safe in memory. When it is stored
        there, you simply write what you want on the screen in its place. In
        my case, I write my HELP boxes, graphics and all in the holes I create
        this way. In reality the HELP overwrites that part of the screen.
        Then when HELP is no longer needed, I simply ***REVERSE*** the whole
        PEEK and POKE. I memory copy back to that area what was there before
        the HELP was issued.

        Now. This technique has another less realized but still important way
        of being used to do exactly what you want, I think! In fact, a very
        few of the DOS utility programs do exactly what I am proposing to you.
        You can write a TSR program in DOS. One of the old hard disk checking
        and analysis programs was written exactly this way. Instead of using
        the NORMAL page to write the desired video output of this program for
        DOS, you make the TSR output your desired TEXT mode stuff to an OFFSET
        of 4000 bytes in one of the other five pages of video memory that are
        reserved in standard DOS ... and COMPLIAHT DOS boxes for this use!

        I've only run into ONE deal where an old HP computer violated the
        standard video memory layout deal and got this garbaged and that was
        a very long time ago.

        Then, when you want a display of what was in the alert box, you simply
        make a pass to slush the normal screen on a yet unused page up there.
        You make a pass to pop in the hidden video data. When through with
        it you do what you want to recover the cached video that was there.

        As an alternative, you can put a TOGGLE in the video output of the
        program running as a TSR to let it write to standard screen. Or, you
        can, if the data is small enough, let part of it march on in standard
        video and the rest of your program does what you want elsewhere.

        This all may be of help to you for de-minimus shuffle work.

        I realize this is not the same thing as window session control which
        re-arranges the order of programs on a more complicated desktop. I
        have no idea how to do this in Windows environments. However it is
        completely possible to call what I will describe as a 'super shell'
        program from a DOS-VDM session in OS/2. From that you can launch
        any program you want as yet another DOS-VDM session, a WIN session,
        or another OS/2 session. Any or all of them may be full screen, or
        they may be seamless windows, or they may be hidden and only can be
        accessed from certain pull down(up) standard OS/2 desktop keys.

        And example of one of the utilities that are public domain and that
        may be used to do this in OS/2 is the ORUN utility. I can issue a
        SHELL command in a PowerBASIC 3.5 running DOS-VDM OBJECT on the OS/2
        desktop. The ORUN utility or another one like HSTART, for example,
        will do whatever I want to fire up whatever I want as a new program.
        However, another use of these will do exactly what you want in OS/2.
        You simply use them to pop the required keyboard control strokes as
        opposed to a full program. Think of it as a batch-batch deal, sort
        of. Poof, exactly what you want to do with the desktop.

        Imagine! You can have a TSR running in a DOS-VDM in OS/2 and hit a
        HOT KEY in it. All controlling a PowerBASIC SHELL game. You can then
        have OS/2 open a seamless window in even WIN or open an OS/2 windowed
        session. You may make the desktop then run a completely native full
        OS/2 video game or whatever, or, say run a TV card with Wheel of Fortune
        on the desktop either on top or under your application.

        All from even a HOT KEY in a TSR for DOS-VDM's. And while it is all
        going on, you can pop video between the six pages of alloted such
        storage stuff on your PowerBASIC application! I do similar things
        all the time in running even DOS BBS systems in the OS/2 world.

        That will include even text written into a slush file on the hard
        disk from the OS/2 or WIN program which may have used it to transfer
        data there you want served to your PowerBASIC DOS program.

        You may even run half a dozen PowerBASIC DOS-VDM written utility
        programs at the same time all contributing to this combined screen
        toggle output in the DOS program on the desktop..

        No fuss, no muss, no bother, with fill hardware access and access
        to the timer and all that for cadence ... if you want it..

        In OS/2.

        And, now with CONNECTIX and INNOTEK's VPC product, that will include
        even at least spawning full WIN-XP stuff in a protected OBJECT if
        your little ol' heart wants to do it, auto-merged to all the hardware,
        and video cameras, and codecs and sigh..

        But you will have to work like a mule to get there!




        ------------------
        Mike Luther
        [email protected]
        Mike Luther
        [email protected]

        Comment


        • #5
          Thanks Mike but that is not the problem I am trying to solve.
          I have used the other screens (8 to be precise) since the days
          of TurboBasic. Before I delve deeper into system interrupt I
          wondered if it had already been done.
          Cheers all

          ------------------

          Comment

          Working...
          X