🚀 go-pugleaf

In article <101@slpfs1.UUCP> jct@slpfs1.UUCP (Jeff Tolmie) writes:
>    WndClientProc(..., msg, parm1, parm2) {
>    switch(msg) {
>    case WIN_PAINT:
>    case 
>    etc etc etc
>    }

The first parameter for a clientProc() is hwnd - the window handle for
the window that's receiving the message.  Normally, you register a
window class with the system and all windows created with that class
use the same client procedure.  Windows with a different class may use
a different procedure.

>Now, all that PM has to create (in the code) are the windows/dialogs. And
>there is a PM function to do this. WinCreateStdWindow(...). Here you tell
>the PM if this window has a menu bar, an icon, all the decorations you are
>used to getting automatically from Motif Window Manager like Maximize, 
>Minimize etc, and of course where to find the right resource (.rc) file. Note
>that the creating includes registering the window class. (Can't exactly
>remember the function name.) 

WinRegisterClass()

>X-Windows  
>    XDrawRectangle(..., x,y, w,h) 
>
>OS/2 PM
>    pt.x=x; pt.t=y; GpiMove(pt); pt.x=x+w, pt.y=y+h; GpiRectangle(...,pt, ...)
>
>Oh!, and watch out! PM uses bottom-left as origin, not top-left.

PM's coordinates can be reversed for individual windows.  It's a flag
(a frame creation (FCF_) flag, I believe) passed to WinRegisterClass
(or maybe to WinCreateStdWindow).  Personally, I like the bottom-left
coordinates, it matches the first-quadrant coordinates you find in
mathematics. 

>This is a SHOUT for help. Because as far as I can tell, color handling
>in OS/2 PM is terrible. If you just want standard 4 bit colors like
>RED, DARK_RED etc, then it's quite straightforward. If you want to mess
>around with palettes, then it gets very unclear. If someone who understands
>PM color and knows how to, for example, display all 256 colors from the
>hardware colormap (I am using orchid 800x600x256) then please let me know.

You can use any RGB color fairly easilly - you request an RGB and it
gives you a palette offset.  If you're on a 24-bit color device, you
get the color.  Otherwise, PM gives you the nearest match based on the
current palette.  Dithered colors (for fills) may be done with a
different API call.

If you need the exact colors, you're going to have to mess with the
palette manager.  This is a pain under OS/2 and Windows.  I don't know
why it has to be, though.  Doesn't X assume a 24-bit palette?  That
makes things infinitely easier, since there are no palettes to muck
with. 

If you don't want a specific RGB color, but want an offset into the
current palette, I think that can be done fairly easilly as well.  As
far as I can remember, there is a default palette where the first 16
colors correspond to the 16 DOS colors.  The constants CLR_BLACK,
CRL_BLUE, etc., are defined as the numbers 0-15.  I think you can just
use values 16-255 for the rest of the palette, if you don't want a
specific color.

I haven't done much with this, but based on what I've read in the
Toolkit documentation, it seems pretty straightforward to me.  To edit
the palette, you request a handle to a palette, make the changes to
it, and register it with the system.  OS/2 then adjusts its palette as
it thinks it should to get you the colors.  Where there's a conflict,
I'm not sure what it does (I haven't played with this, yet).  Windows
resolves conflicts by giving the foreground process the palette and
makes everyone else take the closest matches - this results in windows
getting mangled and repainted whenever two palette-using windows swap
focus.  I haven's seen this behavior under OS/2, so it's doing
something else.
-- 
   |)  David Charlap           "I don't even represent myself
  /|_  dic5340@hertz.njit.edu   sometimes so NJIT is right out!.
 ((|,)
  ~|~  Hi! I am a .signature virus, copy me into your .signature file.