Announcement

Collapse
No announcement yet.

Programmable minimize

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
    Don Ward
    Member

  • Don Ward
    replied
    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

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

    Leave a comment:

  • Mike Luther
    Member

  • Mike Luther
    replied
    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]

    Leave a comment:

  • Don Ward
    Member

  • Don Ward
    replied
    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.


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

    Leave a comment:

  • Eric Pearson
    Member

  • Eric Pearson
    replied
    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>

    Leave a comment:

  • Don Ward
    Member

  • Don Ward
    started a topic Programmable minimize

    Programmable minimize

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

    ------------------
Working...
X