DR>
  > You could basically just write a small set of function that
  > access a 4K buffer in memory (an 80x25 buffer with char/attr
  > pairs) as thow it were a text mode buffer. Then you would just
  > need to provide a refresh function that would be called from the
  > WM_PAINT message. It would calculate the cells covered by the
  > invalidated area, then translate the information in the pseudo
  > buffer and convert them to very simple GPI calls.
DR>

  There's no need to roll your own functions to do this, because the
  existing VIO functions will do all this for you, allowing you do
  display text-mode-like screens in PM.

  Very simply, (and for the benefit of the lurkers) you create a "VIO
  Presentation Space", which is a buffer of character/attribute pairs,
  known as cells.  You can then associate it with the device context of
  a given screen window.

  All of the VioXXXX() function calls (for text mode) can use the
  handle to this VIO Presentation Space, and will operate on the
  contents of the presentation space instead of the text screen.

  Then, at WM_PAINT time, you simply call VioShowBuf to cause the
  appropriate part of the window to be displayed.  VioShowBuf works out
  how to draw the characters on the screen in the correct colours and
  font (which you can configure).

  Once you understand the principles, it's not hard to get an AVIO
  window on the PM desktop.

  I've even gone so far as to derive my own C++ stream classes (from
  streambuf and ios) to handle output to a VIO window (treating it like
  a dumb scrolling TTY) in the same manner as output to cout.

DR>
  > ... although I think now that they have been badgered into
  > providing [VIO] in Workplace OS/2.
DR>

  Look on the Developers' Connection CD-ROM.

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 2.01wb