🚀 go-pugleaf

AFAIK you can use a screen-compatible DC (or the "O" option) safely with 
bitmaps too. I think the windows docs refer to special DC's for printers (as 
many printers have different capabilities, e.g. some have their own 
rastering engine, some not, some are even plotters with pens).

Nils

"Ian Boyd" <ian.borlandnews010@avatopia.com> schreef in bericht 
news:4888c414@newsgroups.borland.com...
> CreateCompatibleDC creates a device context that is compatible with the 
> supplied device context.
>
> i want to create a device context in memory so that i can hijack GDI 
> operations to draw onto a bitmap that i've "selected" into the memory 
> device context.
>
> But the only way to create a MemDC (memory device context) is to give it 
> an existing device context. The two common choices are:
>
>    dc :=  CreateCompatibleDC(GetDC(GetDesktopWindow));
>    dc := CreateCompatibleDC(0);
>
> (for the 2nd case: "function creates a memory DC compatible with the 
> application's current screen.")
>
>
> Both of these choices create a DC that is compatible with the 
> screen/desktop. What does that mean? What if i don't want to be compabible 
> with the screen? What if the screen is in 320x200 monochrome 1-bit? What 
> if i want to do advanced 32-bit alpha blending, while the screen is in 256 
> color mode?
>
>
> What does it mean if a DC is compatible with the screen? What are the 
> advantages for it being compatible with the screen? What if i want it to 
> be incompatible? How do i create an incompatible DC? Whare the limitations 
> with having a compatible DC as opposed to an incompatible DC? When would 
> one want an incompatible DC over a compatible one?
>
>
> 

> AFAIK you can use a screen-compatible DC (or the "O" option) safely with 
> bitmaps too.

i'm concerned about a 32-bit bitmap and a 1-bit screen.

Or a 48bit screen and a 32-bit bitmap

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message 
news:4888c414@newsgroups.borland.com...
> Both of these choices create a DC that is compatible with the 
> screen/desktop. What does that mean? What if i don't want to be compabible 
> with the screen? What if the screen is in 320x200 monochrome 1-bit? What 
> if i want to do advanced 32-bit alpha blending, while the screen is in 256 
> color mode?

If you want something different, create a bitmap with the desired color 
resolution, and either use it's canvas's hdc, or create a compatible one 
from that.

If that doesnt do, please describe more specifically what you are trying to 
acheive.

> If you want something different, create a bitmap with the desired color 
> resolution, and either use it's canvas's hdc, or create a compatible one 
> from that.
>
> If that doesnt do, please describe more specifically what you are trying 
> to acheive.

i'm trying to convert an icon to a 32-bpp bitmap. The only solution i can 
find is to draw on a mem dc backed by DI bitmap.

i'm worried that the library code now requires a screen. What if there is no 
screen to get a compatible DC of? 

Ian Boyd wrote:

> CreateCompatibleDC creates a device context that is compatible with
> the supplied device context.
> 
> i want to create a device context in memory so that i can hijack GDI
> operations to draw onto a bitmap that i've "selected" into the memory
> device context.
> 
> But the only way to create a MemDC (memory device context) is to give
> it an existing device context. The two common choices are:
> 
>    dc :=  CreateCompatibleDC(GetDC(GetDesktopWindow));
>    dc := CreateCompatibleDC(0);
> 
> (for the 2nd case: "function creates a memory DC compatible with the
> application's current screen.")
> 
> 
> Both of these choices create a DC that is compatible with the
> screen/desktop. What does that mean? What if i don't want to be
> compabible with the screen? What if the screen is in 320x200
> monochrome 1-bit? What if i want to do advanced 32-bit alpha
> blending, while the screen is in 256 color mode?
> 
> 
> What does it mean if a DC is compatible with the screen?

Think of device contexts as objects. There is a base class that defines
the operations allowed on any device in terms of abstract functions.
Then there are a number of classes derived from this base class that
implement the operations for a specific device type, e.g. a screen
device, a printer device, a plotter device, a Postscript device.
CreateCompatibleDC creates a device context of the same class as the
one you pass in. Things like color depth or screen resolution are just
properties of the object, you can change them as needed.

The Windows screen device context is able to work with off-screen
bitmaps as storage as well as the graphics cards onboard storage (or
the graphic cards low-level driver).

Why you use this low-level approach, by the way? Just create a TBitmap
and use its Canvas. The VCL internally uses CreateCompatibleDC and
takes care of selecting the bitmap into it to server as storage for the
pixels.

-- 
Peter Below (TeamB)  
Don't be a vampire (http://slash7.com/pages/vampires), 
use the newsgroup archives :
http://www.tamaracka.com/search.htm
http://groups.google.com

Ian Boyd wrote:

> > If you want something different, create a bitmap with the desired
> > color  resolution, and either use it's canvas's hdc, or create a
> > compatible one  from that.
> > 
> > If that doesnt do, please describe more specifically what you are
> > trying  to acheive.
> 
> i'm trying to convert an icon to a 32-bpp bitmap. The only solution i
> can find is to draw on a mem dc backed by DI bitmap.
> 
> i'm worried that the library code now requires a screen. What if
> there is no screen to get a compatible DC of?

You are doing way too much work. Create a TBitmap, set its size to the
size of the icon, set its PixelFormat to pf24 or pf32, then use the
bitmap.canvas.draw method to render the icon to the bitmap. Use its
SaveToFile method to save it to a bmp file. Let the VCL worry about how
to deal with the "no screen" situation. Windows has a screen driver
present even if there is no physical monitor attached.

-- 
Peter Below (TeamB)  
Don't be a vampire (http://slash7.com/pages/vampires), 
use the newsgroup archives :
http://www.tamaracka.com/search.htm
http://groups.google.com

> You are doing way too much work. Create a TBitmap, set its size to the
> size of the icon, set its PixelFormat to pf24 or pf32, then use the
> bitmap.canvas.draw method to render the icon to the bitmap. Use its
> SaveToFile method to save it to a bmp file. Let the VCL worry about how
> to deal with the "no screen" situation. Windows has a screen driver
> present even if there is no physical monitor attached.

VCL doesn't support alpha transparency. That's why i'm doing way too much 
work. 

> What you may want to do  if you dont want to mess around with these gdi 
> calls, is use a different graphics interface such as the delphi headers 
> for GDI+ (http://www.progdigy.com/?page_id=7), and save the images as 
> .png's.

Oddly enough, that's exactly what i'm trying to do.

GDIPlus's Bitmap has a constructor that takes an HICON, but it doesn't 
support alpha transparency in icons.

Someone in ms group suggested converting the icon to a bitmap, and construct 
the Bitmap with the overload that takes a bitmap.

Unfortunatly, that constructor doesn't support 32bpp alpha bitmaps either.


i also tried creating a Graphics object, use it's GetHDC() method to get a 
dc of that GDI+ graphics object. But when i DrawIcon the HICON onto the 
Graphic's HDC, it doesn't support alpha either.

i'm completely and totally screwed.



But, the point of my post was wondering what a compatible DC was, and why 
it's called CreateCompatibleDC as opposed to just CreateDC. 

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message 
news:488a1cc0$1@newsgroups.borland.com...
> VCL doesn't support alpha transparency. That's why i'm doing way too much 
> work.

That is a problem with the VCL's TBitmap.  Its not been updated in a long 
time (as far as I know... I'm still on D7).

What you may want to do  if you dont want to mess around with these gdi 
calls, is use a different graphics interface such as the delphi headers for 
GDI+ (http://www.progdigy.com/?page_id=7), and save the images as .png's.

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message news:488a23b8
> i'm completely and totally screwed.

LOL.  Nah, you're nowhere near being screwed.

If I am to understand... you have an icon.  You want to convert it to a 
bitmap, while retaining the alpha transparency.  While I havent done 
anything with icons before... several options come to mind.  Worst case, you 
can open the icon file diectly (as in a tfilestream), read it pixel by 
pixel, write the pixel with alpha to a gdi+ bitmap, and save the file.  How 
you locate the pixel data in an icon file I have no idea - you'd have to 
research that.  There's probably some mechanism to access the pixels knowing 
the hicon as well, which may be a better option.

Here's what may be a really dumb question... there's a winapi function 
called drawicon.  Have you tried using that to draw the icon on a bitmap 
that has all its pixels set to transparent?   I would think such an api call 
would support the alpha channel, but who knows.

You can use the HDC provided by TBitmap.Canvas.Handle to call Alphablending 
methods of GDI. You can also do your own rasterization by accessing the 
Bitmap.Scanlines property to get direct access to the pixels.

Success, Nils

"Ian Boyd" <ian.borlandnews010@avatopia.com> schreef in bericht 
news:488a1cc0$1@newsgroups.borland.com...
>> You are doing way too much work. Create a TBitmap, set its size to the
>> size of the icon, set its PixelFormat to pf24 or pf32, then use the
>> bitmap.canvas.draw method to render the icon to the bitmap. Use its
>> SaveToFile method to save it to a bmp file. Let the VCL worry about how
>> to deal with the "no screen" situation. Windows has a screen driver
>> present even if there is no physical monitor attached.
>
> VCL doesn't support alpha transparency. That's why i'm doing way too much 
> work.
> 

> Here's what may be a really dumb question... there's a winapi function 
> called drawicon.

There is.

> Have you tried using that to draw the icon on a bitmap that has all its 
> pixels set to transparent?

i have.

>   I would think such an api call would support the alpha channel, but who 
> knows.

You would think that, wouldn't you. i know did. 

i tried this method.

> For your use, since you want an actual alpha component in each pixel, 
> you'll need to use gdi+ to fill the rectangle with transparent pixels (ie, 
> RGBA( 0,0,0,0)) rather than filling it with a specific color.

i tried that too.

>  Or, if you want the easy way out, you can use some wierd color as a 
> background knowing that its not used in any of your icons

That doesn't work for icons with an alpha channel. Also they're not my icons 
(they're icons associated with a file, or a file's icon).

asflkjasfdasf
sa

i'm just tired. 

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message 
news:488ddeab$1@newsgroups.borland.com...
>> Have you tried using that to draw the icon on a bitmap that has all its 
>> pixels set to transparent?
>
> i have.

The following correctly draws an icon for me with the 'masked' areas being 
transparent:

procedure TForm1.Button1Click(Sender: TObject);
var
   icon: TIcon;
   h: HICON;
   bmp: TBitmap;
begin

  //loadfromfile didnt seem to load the masks correctly, so use loadimage 
instead
  h := loadimage( 0, 'c:\temp\google_earth.ico',
  IMAGE_ICON,
  16, 16, LR_LOADFROMFILE);

  icon := TIcon.Create;
  icon.Handle := h;

  bmp := TBitmap.Create;
  bmp.pixelformat := pf32bit;
  bmp.Width := icon.Width;
  bmp.Height := icon.Height;

  //see note below about this part
  bmp.Canvas.Brush.Color := clBlack;
  bmp.Canvas.FillRect( rect( 0, 0, 15, 15));
  //

  bmp.Canvas.Draw( 0, 0, icon);

  image1.Canvas.Draw( 0, 0, bmp);

  //save the bmp to file?
  //

  bmp.Free;
  icon.free;
end;

For your use, since you want an actual alpha component in each pixel, you'll 
need to use gdi+ to fill the rectangle with transparent pixels (ie, RGBA( 
0,0,0,0)) rather than filling it with a specific color.  Or, if you want the 
easy way out, you can use some wierd color as a background knowing that its 
not used in any of your icons, and then manually go back and set all pixels 
with that color to transparent.  After you draw the icon onto the bitmap, 
use gdi+ to save the bitmap as a .png to preserve the alpha channel.  If you 
create the bitmap with GDI+ you may be able to get it to save the alpha 
channel in the pixel data of a .bmp file, but I've never tried that.

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message news:488e12b4
> That doesn't work for icons with an alpha channel. Also they're not my 
> icons (they're icons associated with a file, or a file's icon).

Instead of all the back and forth, why dont you upload one of these icons to 
the attachments group so we can look at one?  If they have honest to 
goodness alpha channels as opposed to bit masks, I doubt TIcon will be able 
to load and work with them because... who knows the last time TIcon was 
updated.

> > That doesn't work for icons with an alpha channel. Also they're not
> > my  icons (they're icons associated with a file, or a file's icon).
> 
> Instead of all the back and forth, why dont you upload one of these
> icons to the attachments group so we can look at one?  If they have
> honest to goodness alpha channels as opposed to bit masks, I doubt
> TIcon will be able to load and work with them because... who knows
> the last time TIcon was updated.

It does in fact work - even for Vista PNG icons - if you assign a
TIcon's Handle property with a value got from the API's LoadImage.

> It does in fact work - even for Vista PNG icons - if you assign a
> TIcon's Handle property with a value got from the API's LoadImage.

Yes, DrawIconEx does draw partial transparency.

But getting the icon into any other (more portable) format is a trick. 

> > It does in fact work - even for Vista PNG icons - if you assign a
> > TIcon's Handle property with a value got from the API's LoadImage.
> 
> Yes, DrawIconEx does draw partial transparency.
> 
> But getting the icon into any other (more portable) format is a trick.

What do you mean exactly?  D7 at least seems to work pretty much
perfectly with XP ICO files - its Vista ones it has issues with since
the file format was amended by MS.

> What do you mean exactly?

In order to convert an icon into a bitmap you had to go wading though DIB 
sections etc. The 'trick' is having to write all that code, rather than just 
Delphi or an API call to do it.


What do you mean what do i mean? 

> What do you mean exactly?

Tricky.

"What do you mean, 'tricky', like magic tricky?"

No, i'm saying it was tricky.

"Tricky how? Like magic show tricky? Are you saying i'm some sort of 
magician?"

No, all i'm saying is it was tricky.

"What am i some sort of David Copperfield here to amuse you?"

"Ian Boyd" <ian.borlandnews010@avatopia.com> wrote in message 
news:488f7262$1@newsgroups.borland.com...
>> What do you mean exactly?
>
> In order to convert an icon into a bitmap you had to go wading though DIB 
> sections etc. The 'trick' is having to write all that code, rather than 
> just Delphi or an API call to do it.

You know, I tried that snippet I posted yesterday against your sample icon, 
and it output the icon with transparency just fine.  I think the problem you 
were having was creating an image in gdi+ that had a transparent background 
on which to draw the icon.  Thats easy enough to accomplish by setting all 
the pixels to rgba(0,0,0,0).  Alternatively, you could have filled the 
background image with an unusual color (like is done with tspeedbutton 
glyphs), and told tbitmap that was your transparent color.

> > What do you mean exactly?
> 
> In order to convert an icon into a bitmap you had to go wading though
> DIB sections etc. The 'trick' is having to write all that code,
> rather than just Delphi or an API call to do it.
> 
> 
> What do you mean what do i mean?

I've no idea what you mean when you ask what do I mean when I ask what
do you mean...  As for the 'having to write all that code' business, do
you realise the 'classic' GDI API doesn't even provide a standard
routine for writing out BMP files, i.e. its native bitmap file format?
(Cf. http://msdn.microsoft.com/en-us/library/ms532340.aspx for the
SDK's example code on the matter.)  'Having to write all that code' is
just something you have to get used to if coding directly to the GDI...

> do you realise the 'classic' GDI API doesn't even provide a standard
> routine for writing out BMP files, i.e. its native bitmap file format?

Ugh. i didn't actually know that.