🚀 go-pugleaf

Aaron Evans (situs@sirius.com) says:
> Welcome to the world of windows.
> ...
> I would be happy to answer specific questions.

How generous of you!  I'm not the person you addressed that offer to, but
hopefully you'll extend it to me too.

I am also just getting my feet wet in Windows via OWL.  I am able to read a
.bmp file into a TDib, and display it with TDC::SetDIBitsToDevice.  But now I
want to create and modify a TDib.  It seems the only way to do that is to
create a TDibDC pointing to the TDib.  For some reason, that didn't work
for me... it caused my screen to go black as soon as I initialised the
TDibDC.  The docs say that TDibDC uses a driver called dib.drv.  I don't
have any such file in the \windows\system dir.

It seems like TDibDC is not a good way to go.  Does `using' dib.drv (assuming
I could find the file) cause disk accesses?  Why would my screen go blank,
when TDibDC is supposed to be something that just accesses a memory object?
Isn't there a more `native' way to draw into a DIB?

Would I be better off using a TMemoryDC to draw into instead?

One more question (if you don't mind).  I'm confused by the relationship of
DCs to bitmaps and video memory.  I can create a TClientDC from a TWindow,
to draw into the window.  And I think I can create a TMemoryDC or TDibDC to
draw into memory.  But I'm confused by the TDC::SetDIBits and TDC::GetDIBits calls.
These calls take TBitmap and TDib arguments, and transfer bits between those
two.  But these calls don't seem to do anything to the device associated with
the DC.  Why must you transfer bits between TBitmaps and TDibs using a DC
associated with some `third' object?  Why can't you create a DC into either
the TBitmap or TDib to do the transfer?

Hoping for diminution of confusion...
-- 
J Scott Peter XXXIII   //  Wrong thinking is punishable.
scotty@netcom.com     //  Right thinking will be as quickly rewarded.
Los Angeles          //  You will find it an effective combination.