gamedevlists-windows — List for discussing game development on the Windows platform

RE: [GD-Windows] WM_KILLFOCUS

[Daniel V. <vo...@ep...>]

Thanks! Shows how little I know about Windows programming :)

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: Brian Sharon [mailto:bs...@mi...]
> Sent: Tuesday, December 11, 2001 1:19 PM
> To: Daniel Vogel
> Subject: RE: [GD-Windows] WM_KILLFOCUS
> 
> 
> Wouldn't WM_ACTIVATE or WM_ACTIVATEAPP be a more logical place to handle
> restoring gamma settings?  After all, you could get WM_KILLFOCUS from
> destroying a text control while your app remains in the foreground.
> Your code still handles that case correctly by checking to for the
> current foreground window, but using WM_ACTIVATE(APP) would probably
> make things clearer to the next person who visits your code :)
> 
> Just a thought,
> 
> --brian
> 
> -----Original Message-----
> From: Daniel Vogel [mailto:vo...@ep...] 
> Sent: Monday, December 10, 2001 9:11 PM
> To: Daniel Vogel; Brian Sharon; Gamedevlists-Windows@Lists. Sourceforge.
> Net
> Subject: RE: [GD-Windows] WM_KILLFOCUS
> 
> I should've elaborated more what I was trying to do. My goal was to
> ensure
> that our engine (most importantly the Editor) restores the gamma
> settings
> when loosing focus which the following codesnippet does. At first I
> didn't
> have the GetForegroundWindow line so that's why I was wondering in which
> cases wParam were NULL.
> 
> case WM_KILLFOCUS:
> {
> 	guard(WM_KILLFOCUS);
> 
> 	DWORD ProcID;
> 	HWND hWnd = wParam ? (HWND) wParam : ::GetForegroundWindow();
> 
> 	GetWindowThreadProcessId(hWnd, &ProcID);
> 	if( ProcID != GetCurrentProcessId() )
> 		RenDev->RestoreGamma();
> 
> 	...
> 
> 	return 0;
> 	unguard;
> }
> 
> -- Daniel, Epic Games Inc.
> 
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]On Behalf Of
> > Daniel Vogel
> > Sent: Monday, December 10, 2001 8:50 PM
> > To: Brian Sharon; Gamedevlists-Windows@Lists. Sourceforge. Net
> > Subject: RE: [GD-Windows] WM_KILLFOCUS
> >
> >
> > I was manually checking whether wParam was an owned window before
> > restoring
> > the gamma. Looks like I could simply use GetFocus. Thanks for the link
> :)
> >
> > -- Daniel, Epic Games Inc.
> >
> > > -----Original Message-----
> > > From: gam...@li...
> > > [mailto:gam...@li...]On Behalf
> Of
> > > Brian Sharon
> > > Sent: Monday, December 10, 2001 8:30 PM
> > > To: Daniel Vogel; Gamedevlists-Windows@Lists. Sourceforge. Net
> > > Subject: RE: [GD-Windows] WM_KILLFOCUS
> > >
> > >
> > > See http://msdn.microsoft.com/library/en-us/winui/keybinpt_5z8u.asp
> > >
> > > Keyboard focus is a property that's passed between the windows in
> the
> > > foreground thread.  And if something in your app calls
> SetFocus(NULL)
> > > then the HWND would be NULL and your app would be ignoring keyboard
> > > messages.  I'm not sure what you would want to retrieve in that
> case?
> > >
> > > --brian
> > >
> > > -----Original Message-----
> > > From: Daniel Vogel [mailto:vo...@ep...]
> > > Sent: Monday, December 10, 2001 5:18 PM
> > > To: Gamedevlists-Windows@Lists. Sourceforge. Net
> > > Subject: [GD-Windows] WM_KILLFOCUS
> > >
> > > >From the MSDN docs:
> > >
> > > "wParam
> > > Handle to the window that receives the keyboard focus. This
> parameter
> > > can be
> > > NULL."
> > >
> > > In which cases is it NULL and is there a chance to retrieve the HWND
> > > anyways?
> > >
> > > -- Daniel, Epic Games Inc.
> > >
> > >
> > >
> > > _______________________________________________
> > > Gamedevlists-windows mailing list
> > > Gam...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > >
> >
> >
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> >
> 

RE: [GD-Windows] WM_KILLFOCUS

[Daniel V. <vo...@ep...>]

I should've elaborated more what I was trying to do. My goal was to ensure
that our engine (most importantly the Editor) restores the gamma settings
when loosing focus which the following codesnippet does. At first I didn't
have the GetForegroundWindow line so that's why I was wondering in which
cases wParam were NULL.

case WM_KILLFOCUS:
{
	guard(WM_KILLFOCUS);

	DWORD ProcID;
	HWND hWnd = wParam ? (HWND) wParam : ::GetForegroundWindow();

	GetWindowThreadProcessId(hWnd, &ProcID);
	if( ProcID != GetCurrentProcessId() )
		RenDev->RestoreGamma();

	...

	return 0;
	unguard;
}

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Daniel Vogel
> Sent: Monday, December 10, 2001 8:50 PM
> To: Brian Sharon; Gamedevlists-Windows@Lists. Sourceforge. Net
> Subject: RE: [GD-Windows] WM_KILLFOCUS
>
>
> I was manually checking whether wParam was an owned window before
> restoring
> the gamma. Looks like I could simply use GetFocus. Thanks for the link :)
>
> -- Daniel, Epic Games Inc.
>
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]On Behalf Of
> > Brian Sharon
> > Sent: Monday, December 10, 2001 8:30 PM
> > To: Daniel Vogel; Gamedevlists-Windows@Lists. Sourceforge. Net
> > Subject: RE: [GD-Windows] WM_KILLFOCUS
> >
> >
> > See http://msdn.microsoft.com/library/en-us/winui/keybinpt_5z8u.asp
> >
> > Keyboard focus is a property that's passed between the windows in the
> > foreground thread.  And if something in your app calls SetFocus(NULL)
> > then the HWND would be NULL and your app would be ignoring keyboard
> > messages.  I'm not sure what you would want to retrieve in that case?
> >
> > --brian
> >
> > -----Original Message-----
> > From: Daniel Vogel [mailto:vo...@ep...]
> > Sent: Monday, December 10, 2001 5:18 PM
> > To: Gamedevlists-Windows@Lists. Sourceforge. Net
> > Subject: [GD-Windows] WM_KILLFOCUS
> >
> > >From the MSDN docs:
> >
> > "wParam
> > Handle to the window that receives the keyboard focus. This parameter
> > can be
> > NULL."
> >
> > In which cases is it NULL and is there a chance to retrieve the HWND
> > anyways?
> >
> > -- Daniel, Epic Games Inc.
> >
> >
> >
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> >
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

RE: [GD-Windows] WM_KILLFOCUS

[Daniel V. <vo...@ep...>]

I was manually checking whether wParam was an owned window before restoring
the gamma. Looks like I could simply use GetFocus. Thanks for the link :)

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Sharon
> Sent: Monday, December 10, 2001 8:30 PM
> To: Daniel Vogel; Gamedevlists-Windows@Lists. Sourceforge. Net
> Subject: RE: [GD-Windows] WM_KILLFOCUS
>
>
> See http://msdn.microsoft.com/library/en-us/winui/keybinpt_5z8u.asp
>
> Keyboard focus is a property that's passed between the windows in the
> foreground thread.  And if something in your app calls SetFocus(NULL)
> then the HWND would be NULL and your app would be ignoring keyboard
> messages.  I'm not sure what you would want to retrieve in that case?
>
> --brian
>
> -----Original Message-----
> From: Daniel Vogel [mailto:vo...@ep...]
> Sent: Monday, December 10, 2001 5:18 PM
> To: Gamedevlists-Windows@Lists. Sourceforge. Net
> Subject: [GD-Windows] WM_KILLFOCUS
>
> >From the MSDN docs:
>
> "wParam
> Handle to the window that receives the keyboard focus. This parameter
> can be
> NULL."
>
> In which cases is it NULL and is there a chance to retrieve the HWND
> anyways?
>
> -- Daniel, Epic Games Inc.
>
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

RE: [GD-Windows] WM_KILLFOCUS

[Brian S. <bs...@mi...>]

See http://msdn.microsoft.com/library/en-us/winui/keybinpt_5z8u.asp

Keyboard focus is a property that's passed between the windows in the
foreground thread.  And if something in your app calls SetFocus(NULL)
then the HWND would be NULL and your app would be ignoring keyboard
messages.  I'm not sure what you would want to retrieve in that case?

--brian

-----Original Message-----
From: Daniel Vogel [mailto:vo...@ep...]=20
Sent: Monday, December 10, 2001 5:18 PM
To: Gamedevlists-Windows@Lists. Sourceforge. Net
Subject: [GD-Windows] WM_KILLFOCUS

From the MSDN docs:

"wParam
Handle to the window that receives the keyboard focus. This parameter
can be
NULL."

In which cases is it NULL and is there a chance to retrieve the HWND
anyways?

-- Daniel, Epic Games Inc.

[GD-Windows] WM_KILLFOCUS

[Daniel V. <vo...@ep...>]

From the MSDN docs:

"wParam
Handle to the window that receives the keyboard focus. This parameter can be
NULL."

In which cases is it NULL and is there a chance to retrieve the HWND
anyways?

-- Daniel, Epic Games Inc.

RE: [GD-Windows] In memory bitmap to HBITMAP

[Brian H. <bri...@py...>]

At 10:40 AM 12/7/2001 +0000, Andrew Grant wrote:
>CreateCompatibleDC creates a memory DC. By default memory DC's have a 1x1
>monochrome surface so when you call CreateDIBitmap you are creating a bitmap
>which is the same type as that DC, e.g monochrome. Try passing in the DC of
>your window instead to CreateDIBitmap.

Someone else mentioned this to me off-list, and I felt stupid because the 
help says this.  But I don't feel THAT stupid because, well, look at the 
name of the function and I was passing in "NULL", which means (to me) 
"Create a DC compatible with the screen".  And I'm not running in 
monochrome, thank you =)  But as you say, DC compatibility doesn't mean 
color depth compatibility, it means "device characteristic" 
compatibility.  So, yeah, I guess it was a stupid newbie error =)

I'll give the various suggestions a shot today, thanks!

Brian

RE: [GD-Windows] In memory bitmap to HBITMAP

[Andrew G. <And...@ho...>]

To avoid confusion, I should also mention that Jon Watte's example works
regardless of what is in the memory DC because he is using CreateDIBSection,
not CreateDIBitmap.

CreateDIBSection = device independent bitmap
CreateDIBitmap = device dependent bitmap. (Why it's not CreateDDBitmap or
something sensible I don't know).

Device dependent bitmaps give better GDI performance because they are in
some device-friendly format.

Andrew Grant
Hothouse Creations 




> -----Original Message-----
> From: Andrew Grant [mailto:And...@ho...]
> Sent: 07 December 2001 10:41
> To: gam...@li...
> Subject: RE: [GD-Windows] In memory bitmap to HBITMAP
> 
> 
> Ahh, remembered what the problem was :)
> 
> CreateCompatibleDC creates a memory DC. By default memory 
> DC's have a 1x1
> monochrome surface so when you call CreateDIBitmap you are 
> creating a bitmap
> which is the same type as that DC, e.g monochrome. Try 
> passing in the DC of
> your window instead to CreateDIBitmap. 
> 
> 
> To explain further; (stuff you may/may not know)
> 
> In Windows DCs are your interface for drawing to the object 
> they contain.
> Screens, Bitmaps and so on. When you call CreateCompatibleDC you are
> returned a compatible but empty DC (well, 1x1 b/w) that you 
> can then use to
> draw to. Compatible doesn't mean format-wise (after all you can BitBlt
> between DCs of different colour depths), it means compatible 
> in some device
> way, in this case compatible with the screen. However until you place
> something into that DC then you are using the default 1x1 monochrome
> surface.
> 
> For instance if you wanted to draw text to a HBITMAP using 
> GDI you put that
> hbmp into the DC first so you are using that. Something like...
> 
> // create a dc
> HDC hdc = CreateCompatibleDC();
> 
> // select the bitmap into the dc
> HGDIOBJ hOld = SelectObject(hdc, hbmp);
> 
> // draw your text
> DrawText(hdc, "blah blah", ...);
> 
> // remove the hbmp from the dc
> SelectObject(hdc, hOld);
> 
> // delete the dc
> DeleteDC(hdc);
> 
> 
> 
> Another example. To solve your problem you could do
> 
> HDC hdc = CreateCompatibleDC();			// 
> create a memory DC
> 
> HBITMAP = CreateBitmapIndirect();			// 
> creates an empty
> bitmap of the specified dimensions and depth
> 
> // select the new bmp into the DC
> HGDIOBJ hOld = SelectObject(hdc, hbmp);
> 
> CreateDIBitmap(hdc, ...);
> 
> Now at this point you have loaded your new bitmap with the 
> same color depth
> as the bitmap you created with CreateBitmapIndirect(), 
> because that was
> format of the bitmap in the DC you used with CreateDIBitmap, 
> not the default
> 1x1 monochrome one. Of course this isn't always good method 
> because you are
> allocating extra resources with CreateBitmapIndirect, however 
> this technique
> is useful for the case where the users desktop is running in 
> 16-bit color
> and you want to work with 24-bit images.
> 
> It's good to think of a DC as an interface you use to draw on 
> something. In
> the case of WM_PAINT that 'something' is the screen, in the 
> case of memory
> DCs it is the bitmap you place in them with SelectObject. 
> 
> 
> Hope this helps somewhat.
> 
> 
> Andrew Grant
> Hothouse Creations 
> 
> 
> 
> > -----Original Message-----
> > From: Andrew Grant [mailto:And...@ho...]
> > Sent: 07 December 2001 09:57
> > To: gam...@li...
> > Subject: RE: [GD-Windows] In memory bitmap to HBITMAP
> > 
> > 
> > I've had this before, I can't remember what caused it but it 
> > turned out to
> > be a "duh" error on my part. Code Guru (www.codeguru) is a 
> > great site for
> > all sorts of GDI programming trickery. It's MFC based but the 
> > techniques are
> > sound and it's not a great deal of pain to implment any of 
> > the samples in
> > Win32. In this case 
> > http://www.codeguru.com/bitmap/bitmap_from_bmp.shtml. 
> > 
> > On another note, have you thought about using LoadImage() 
> > instead rather
> > than doing it manually?
> > 
> > Andrew Grant
> > Hothouse Creations 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Brian Hook [mailto:bri...@py...]
> > > Sent: 07 December 2001 02:04
> > > To: gam...@li...
> > > Subject: [GD-Windows] In memory bitmap to HBITMAP
> > > 
> > > 
> > > I'm struggling with something fairly basic -- I want to 
> > load a BMP out
> > > of a compressed file, convert to an HBITMAP, then blit it 
> > into a DDraw
> > > surface.  I know how to do the first and last part, but the 
> > middle is
> > > causing problems.  Even worse, I'm not getting any errors.
> > > 
> > > Loading the bitmap doesn't seem to be a problem.  I load it 
> > > up and parse
> > > and find the BITMAPFILEHEADER and BITMAPINFOHEADER no 
> probs.  I also
> > > locate the raw bits no problem (and inspect with the 
> > debugger to make
> > > sure I'm getting what I think I'm getting -- in this case, solid
> > > magenta).  Looks fine.
> > > 
> > > The next step is to create a DC compatible with the desktop:
> > > 
> > > HDC hDC = CreateCompatibleDC( NULL );
> > > 
> > > I then create a HBITMAP compatible with DC, and using the 
> > > bits I pulled:
> > > 
> > > HBITMAP hbm;
> > > 
> > > hbm = CreateDIBitmap( hDC, lpBMIH, CBM_INIT, lpBits, lpBMIH,
> > > DIB_RGB_COLORS );
> > > 
> > > lpBMIH are simply pointers to the appropriate 
> > BITMAPINFOHEADER.  They
> > > have correct values in them.  The bitmap is returned successfully.
> > > 
> > > To verify things, I grab the bits out of the Bitmap to make sure
> > > everything is cool:
> > > 
> > > GetDIBits( hDC, hbm, 0, iHeight, tempbuffer, &bmi, 
> DIB_RGB_COLORS );
> > > 
> > > It returns the correct number of scan lines, but tempbuffer 
> > is filled
> > > with black.  This means either the CreateDIBitmap() filled in 
> > > the bitmap
> > > with black, or the GetDIBits() failed somehow.  I can't 
> > > figure out which
> > > is the real culprit, but the bitmap is pretty much a black square.
> > > 
> > > Any suggestions on how to hunt this down?
> > > 
> > > 
> > > 
> > 
> > 
> > This email is covered by the following disclaimer, please 
> read before
> > accepting this email. http://www.hothouse.org/disclaimer/
> > 
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > 
> 
> 
> This email is covered by the following disclaimer, please read before
> accepting this email. http://www.hothouse.org/disclaimer/
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 


This email is covered by the following disclaimer, please read before
accepting this email. http://www.hothouse.org/disclaimer/

RE: [GD-Windows] In memory bitmap to HBITMAP

[Andrew G. <And...@ho...>]

Ahh, remembered what the problem was :)

CreateCompatibleDC creates a memory DC. By default memory DC's have a 1x1
monochrome surface so when you call CreateDIBitmap you are creating a bitmap
which is the same type as that DC, e.g monochrome. Try passing in the DC of
your window instead to CreateDIBitmap. 


To explain further; (stuff you may/may not know)

In Windows DCs are your interface for drawing to the object they contain.
Screens, Bitmaps and so on. When you call CreateCompatibleDC you are
returned a compatible but empty DC (well, 1x1 b/w) that you can then use to
draw to. Compatible doesn't mean format-wise (after all you can BitBlt
between DCs of different colour depths), it means compatible in some device
way, in this case compatible with the screen. However until you place
something into that DC then you are using the default 1x1 monochrome
surface.

For instance if you wanted to draw text to a HBITMAP using GDI you put that
hbmp into the DC first so you are using that. Something like...

// create a dc
HDC hdc = CreateCompatibleDC();

// select the bitmap into the dc
HGDIOBJ hOld = SelectObject(hdc, hbmp);

// draw your text
DrawText(hdc, "blah blah", ...);

// remove the hbmp from the dc
SelectObject(hdc, hOld);

// delete the dc
DeleteDC(hdc);



Another example. To solve your problem you could do

HDC hdc = CreateCompatibleDC();			// create a memory DC

HBITMAP = CreateBitmapIndirect();			// creates an empty
bitmap of the specified dimensions and depth

// select the new bmp into the DC
HGDIOBJ hOld = SelectObject(hdc, hbmp);

CreateDIBitmap(hdc, ...);

Now at this point you have loaded your new bitmap with the same color depth
as the bitmap you created with CreateBitmapIndirect(), because that was
format of the bitmap in the DC you used with CreateDIBitmap, not the default
1x1 monochrome one. Of course this isn't always good method because you are
allocating extra resources with CreateBitmapIndirect, however this technique
is useful for the case where the users desktop is running in 16-bit color
and you want to work with 24-bit images.

It's good to think of a DC as an interface you use to draw on something. In
the case of WM_PAINT that 'something' is the screen, in the case of memory
DCs it is the bitmap you place in them with SelectObject. 


Hope this helps somewhat.


Andrew Grant
Hothouse Creations 



> -----Original Message-----
> From: Andrew Grant [mailto:And...@ho...]
> Sent: 07 December 2001 09:57
> To: gam...@li...
> Subject: RE: [GD-Windows] In memory bitmap to HBITMAP
> 
> 
> I've had this before, I can't remember what caused it but it 
> turned out to
> be a "duh" error on my part. Code Guru (www.codeguru) is a 
> great site for
> all sorts of GDI programming trickery. It's MFC based but the 
> techniques are
> sound and it's not a great deal of pain to implment any of 
> the samples in
> Win32. In this case 
> http://www.codeguru.com/bitmap/bitmap_from_bmp.shtml. 
> 
> On another note, have you thought about using LoadImage() 
> instead rather
> than doing it manually?
> 
> Andrew Grant
> Hothouse Creations 
> 
> 
> 
> > -----Original Message-----
> > From: Brian Hook [mailto:bri...@py...]
> > Sent: 07 December 2001 02:04
> > To: gam...@li...
> > Subject: [GD-Windows] In memory bitmap to HBITMAP
> > 
> > 
> > I'm struggling with something fairly basic -- I want to 
> load a BMP out
> > of a compressed file, convert to an HBITMAP, then blit it 
> into a DDraw
> > surface.  I know how to do the first and last part, but the 
> middle is
> > causing problems.  Even worse, I'm not getting any errors.
> > 
> > Loading the bitmap doesn't seem to be a problem.  I load it 
> > up and parse
> > and find the BITMAPFILEHEADER and BITMAPINFOHEADER no probs.  I also
> > locate the raw bits no problem (and inspect with the 
> debugger to make
> > sure I'm getting what I think I'm getting -- in this case, solid
> > magenta).  Looks fine.
> > 
> > The next step is to create a DC compatible with the desktop:
> > 
> > HDC hDC = CreateCompatibleDC( NULL );
> > 
> > I then create a HBITMAP compatible with DC, and using the 
> > bits I pulled:
> > 
> > HBITMAP hbm;
> > 
> > hbm = CreateDIBitmap( hDC, lpBMIH, CBM_INIT, lpBits, lpBMIH,
> > DIB_RGB_COLORS );
> > 
> > lpBMIH are simply pointers to the appropriate 
> BITMAPINFOHEADER.  They
> > have correct values in them.  The bitmap is returned successfully.
> > 
> > To verify things, I grab the bits out of the Bitmap to make sure
> > everything is cool:
> > 
> > GetDIBits( hDC, hbm, 0, iHeight, tempbuffer, &bmi, DIB_RGB_COLORS );
> > 
> > It returns the correct number of scan lines, but tempbuffer 
> is filled
> > with black.  This means either the CreateDIBitmap() filled in 
> > the bitmap
> > with black, or the GetDIBits() failed somehow.  I can't 
> > figure out which
> > is the real culprit, but the bitmap is pretty much a black square.
> > 
> > Any suggestions on how to hunt this down?
> > 
> > 
> > 
> 
> 
> This email is covered by the following disclaimer, please read before
> accepting this email. http://www.hothouse.org/disclaimer/
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 


This email is covered by the following disclaimer, please read before
accepting this email. http://www.hothouse.org/disclaimer/

RE: [GD-Windows] In memory bitmap to HBITMAP

[Andrew G. <And...@ho...>]

I've had this before, I can't remember what caused it but it turned out to
be a "duh" error on my part. Code Guru (www.codeguru) is a great site for
all sorts of GDI programming trickery. It's MFC based but the techniques are
sound and it's not a great deal of pain to implment any of the samples in
Win32. In this case http://www.codeguru.com/bitmap/bitmap_from_bmp.shtml. 

On another note, have you thought about using LoadImage() instead rather
than doing it manually?

Andrew Grant
Hothouse Creations 



> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 07 December 2001 02:04
> To: gam...@li...
> Subject: [GD-Windows] In memory bitmap to HBITMAP
> 
> 
> I'm struggling with something fairly basic -- I want to load a BMP out
> of a compressed file, convert to an HBITMAP, then blit it into a DDraw
> surface.  I know how to do the first and last part, but the middle is
> causing problems.  Even worse, I'm not getting any errors.
> 
> Loading the bitmap doesn't seem to be a problem.  I load it 
> up and parse
> and find the BITMAPFILEHEADER and BITMAPINFOHEADER no probs.  I also
> locate the raw bits no problem (and inspect with the debugger to make
> sure I'm getting what I think I'm getting -- in this case, solid
> magenta).  Looks fine.
> 
> The next step is to create a DC compatible with the desktop:
> 
> HDC hDC = CreateCompatibleDC( NULL );
> 
> I then create a HBITMAP compatible with DC, and using the 
> bits I pulled:
> 
> HBITMAP hbm;
> 
> hbm = CreateDIBitmap( hDC, lpBMIH, CBM_INIT, lpBits, lpBMIH,
> DIB_RGB_COLORS );
> 
> lpBMIH are simply pointers to the appropriate BITMAPINFOHEADER.  They
> have correct values in them.  The bitmap is returned successfully.
> 
> To verify things, I grab the bits out of the Bitmap to make sure
> everything is cool:
> 
> GetDIBits( hDC, hbm, 0, iHeight, tempbuffer, &bmi, DIB_RGB_COLORS );
> 
> It returns the correct number of scan lines, but tempbuffer is filled
> with black.  This means either the CreateDIBitmap() filled in 
> the bitmap
> with black, or the GetDIBits() failed somehow.  I can't 
> figure out which
> is the real culprit, but the bitmap is pretty much a black square.
> 
> Any suggestions on how to hunt this down?
> 
> 
> 


This email is covered by the following disclaimer, please read before
accepting this email. http://www.hothouse.org/disclaimer/

Re: [GD-Windows] In memory bitmap to HBITMAP

[Aaron H. <Vid...@ho...>]

I tend to avoid the other DI bitmap functions other than
CreateDIBSection() because I've also had similar difficulty with windows
misbehaving.

Btw, why are you bothering to mix GDI functions with DDraw?  Isn't that
dangerous?

- Aaron
OTri Studios

Brian Hook wrote:
> 
> I'm struggling with something fairly basic -- I want to load a BMP out
> of a compressed file, convert to an HBITMAP, then blit it into a DDraw
> surface.  I know how to do the first and last part, but the middle is
> causing problems.  Even worse, I'm not getting any errors.
> 
> Loading the bitmap doesn't seem to be a problem.  I load it up and parse
> and find the BITMAPFILEHEADER and BITMAPINFOHEADER no probs.  I also
> locate the raw bits no problem (and inspect with the debugger to make
> sure I'm getting what I think I'm getting -- in this case, solid
> magenta).  Looks fine.
> 
> The next step is to create a DC compatible with the desktop:
> 
> HDC hDC = CreateCompatibleDC( NULL );
> 
> I then create a HBITMAP compatible with DC, and using the bits I pulled:
> 
> HBITMAP hbm;
> 
> hbm = CreateDIBitmap( hDC, lpBMIH, CBM_INIT, lpBits, lpBMIH,
> DIB_RGB_COLORS );
> 
> lpBMIH are simply pointers to the appropriate BITMAPINFOHEADER.  They
> have correct values in them.  The bitmap is returned successfully.
> 
> To verify things, I grab the bits out of the Bitmap to make sure
> everything is cool:
> 
> GetDIBits( hDC, hbm, 0, iHeight, tempbuffer, &bmi, DIB_RGB_COLORS );
> 
> It returns the correct number of scan lines, but tempbuffer is filled
> with black.  This means either the CreateDIBitmap() filled in the bitmap
> with black, or the GetDIBits() failed somehow.  I can't figure out which
> is the real culprit, but the bitmap is pretty much a black square.
> 
> Any suggestions on how to hunt this down?
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] In memory bitmap to HBITMAP

[Jon W. <hp...@mi...>]

Here's my personal utility offscreen bitmap generation function:

void
MyBitmap::setSize( 
  int width, 
  int height
  )
{
  assert( !bitmap );  //  can't re-allocate bitmap once done
  assert( !bits );
  xSize = width;
  ySize = height;
  dc = gl->getUtilDC( );
  BITMAPINFOHEADER bmi;
  memset( &bmi, 0, sizeof( bmi ) );
  bmi.biSize = sizeof( bmi );
  bmi.biWidth = width;
  bmi.biHeight = height;
  bmi.biPlanes = 1;
  bmi.biBitCount = 32;
  bmi.biCompression = BI_RGB;
  bitmap = CreateDIBSection( dc, (BITMAPINFO *)&bmi, DIB_RGB_COLORS, (void **)&bits, 0, 0 );
  assert( bitmap != 0 );
  assert( bits != 0 );
  textColor = 0xffffff;
  bgColor = 0;
  fillRect( 0, 0, width, height, 0 );
}

getUtilDC() returns a DC previously returned from CreateCompatibleDC().

fillRect() draws into the bitmap as such:

void 
MyBitmap::fillRect( 
  int left, 
  int top, 
  int width, 
  int height, 
  unsigned int pixel
  )
{
  assert( bitmap );
  assert( dc );
  HBITMAP oldBitmap = (HBITMAP)SelectObject( dc, bitmap );
  HBRUSH b = CreateSolidBrush( MK_COLORREF(pixel) );
  RECT r;
  r.left = left;
  r.top = top;
  r.right = left+width;
  r.bottom = top+height;
  BOOL res = FillRect( dc, &r, b );
  assert( res );
  SelectObject( dc, oldBitmap );
  DeleteObject( b );
  dirty = true;
}

Hope this helps.

Cheers,

			/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Thursday, December 06, 2001 6:04 PM
> To: gam...@li...
> Subject: [GD-Windows] In memory bitmap to HBITMAP
> 
> 
> I'm struggling with something fairly basic -- I want to load a BMP out
> of a compressed file, convert to an HBITMAP, then blit it into a DDraw
> surface.  I know how to do the first and last part, but the middle is
> causing problems.  Even worse, I'm not getting any errors.
> 
> Loading the bitmap doesn't seem to be a problem.  I load it up and parse
> and find the BITMAPFILEHEADER and BITMAPINFOHEADER no probs.  I also
> locate the raw bits no problem (and inspect with the debugger to make
> sure I'm getting what I think I'm getting -- in this case, solid
> magenta).  Looks fine.
> 
> The next step is to create a DC compatible with the desktop:
> 
> HDC hDC = CreateCompatibleDC( NULL );
> 
> I then create a HBITMAP compatible with DC, and using the bits I pulled:
> 
> HBITMAP hbm;
> 
> hbm = CreateDIBitmap( hDC, lpBMIH, CBM_INIT, lpBits, lpBMIH,
> DIB_RGB_COLORS );
> 
> lpBMIH are simply pointers to the appropriate BITMAPINFOHEADER.  They
> have correct values in them.  The bitmap is returned successfully.
> 
> To verify things, I grab the bits out of the Bitmap to make sure
> everything is cool:
> 
> GetDIBits( hDC, hbm, 0, iHeight, tempbuffer, &bmi, DIB_RGB_COLORS );
> 
> It returns the correct number of scan lines, but tempbuffer is filled
> with black.  This means either the CreateDIBitmap() filled in the bitmap
> with black, or the GetDIBits() failed somehow.  I can't figure out which
> is the real culprit, but the bitmap is pretty much a black square.
> 
> Any suggestions on how to hunt this down?
> 
> 
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

[GD-Windows] In memory bitmap to HBITMAP

[Brian H. <bri...@py...>]

I'm struggling with something fairly basic -- I want to load a BMP out
of a compressed file, convert to an HBITMAP, then blit it into a DDraw
surface.  I know how to do the first and last part, but the middle is
causing problems.  Even worse, I'm not getting any errors.

Loading the bitmap doesn't seem to be a problem.  I load it up and parse
and find the BITMAPFILEHEADER and BITMAPINFOHEADER no probs.  I also
locate the raw bits no problem (and inspect with the debugger to make
sure I'm getting what I think I'm getting -- in this case, solid
magenta).  Looks fine.

The next step is to create a DC compatible with the desktop:

HDC hDC = CreateCompatibleDC( NULL );

I then create a HBITMAP compatible with DC, and using the bits I pulled:

HBITMAP hbm;

hbm = CreateDIBitmap( hDC, lpBMIH, CBM_INIT, lpBits, lpBMIH,
DIB_RGB_COLORS );

lpBMIH are simply pointers to the appropriate BITMAPINFOHEADER.  They
have correct values in them.  The bitmap is returned successfully.

To verify things, I grab the bits out of the Bitmap to make sure
everything is cool:

GetDIBits( hDC, hbm, 0, iHeight, tempbuffer, &bmi, DIB_RGB_COLORS );

It returns the correct number of scan lines, but tempbuffer is filled
with black.  This means either the CreateDIBitmap() filled in the bitmap
with black, or the GetDIBits() failed somehow.  I can't figure out which
is the real culprit, but the bitmap is pretty much a black square.

Any suggestions on how to hunt this down?

Re: [GD-Windows] getmainwindow...

[gabor f. <xl...@po...>]

thanks,
but i'm in VCL ( borland's realm :-)

the idea was,
that the 'main' application would be nothing special...
like a console application or something like this...
and he would simply enumerate all the available viewports,
and use on ( the first one, the best one, by some kind of priority )..
the idea is that the main app (actually there is only one process,
it's just easier to call the main part as the main app ) doesn't
know about winapi and such.... he only tells a viewport to open
himself... it's the viewport's work... then he tells the viewport
to load in a mesh and some textures and whatever....

all the time the main app gets only interface-pointers...
the chosen viewport manages the system dependent stuff.

this isn't my idea of course :-)
look at the nebula device at www.radonlabs.de .. i borrowed
the ide from here...

the idea works... it this case the solution is that the viewport objects
calls CreateWindow.....

my problem was that i created a bit chaotic structure because of the
main app created the window, and i wanted the viewport to sit
in his client area....

i'll just give him the main-window-id ( the handle )..

thanks for your help,
bye
gabor

p.s: has anyone found out how to SEARCH the archives?

----- Original Message ----- 
From: "Leath Muller" <Lea...@en...>
To: <gam...@li...>
Sent: Thursday, December 06, 2001 12:39 AM
Subject: RE: [GD-Windows] getmainwindow...


I missed the start of this thread -- are you after the main application
window? If your in MFC, why not AfxGetMainWnd(), or if not, maybe look
at the MFC source for that call?

> Or call EnumWindows to iterate over all top-level windows and 
> look for a
> window whose process id matches GetCurrentProcessId().  Or an instance
> handle that matches your current instance handle.  Or...we 
> could just go
> on all day like this, couldn't we!

Leathal.


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] getmainwindow...

[Leath M. <Lea...@en...>]

I missed the start of this thread -- are you after the main application
window? If your in MFC, why not AfxGetMainWnd(), or if not, maybe look
at the MFC source for that call?

> Or call EnumWindows to iterate over all top-level windows and =

> look for a
> window whose process id matches GetCurrentProcessId().  Or an instance
> handle that matches your current instance handle.  Or...we =

> could just go
> on all day like this, couldn't we!

Leathal.

RE: [GD-Windows] getmainwindow...

[Brian H. <bri...@py...>]

> for example maybe i'll port this code to a different platform....

Cross platform programming isn't about NOT using an API, it's about
isolating API specific features in appropriate places and abstracting
things to a higher level so that your core games.

Not keeping your app's HWND around for a Windows app is NOT the way to
go -- my code is very cross platform, but my Windows-centric portion
still knows what the HWND is.  You should probably try to structure
things similarly.

Brian

RE: [GD-Windows] getmainwindow...

[Brian S. <bs...@mi...>]

Or call EnumWindows to iterate over all top-level windows and look for a
window whose process id matches GetCurrentProcessId().  Or an instance
handle that matches your current instance handle.  Or...we could just go
on all day like this, couldn't we!

--brian

-----Original Message-----
From: Brian Sharon [mailto:bs...@mi...]=20
Sent: Wednesday, December 05, 2001 1:43 PM
To: gabor farkas; gam...@li...
Subject: RE: [GD-Windows] getmainwindow...

If you have a child window handle, you can repeatedly call GetParent()
until it returns NULL.

Don't know if that's the "authorized" way, but it works for me.

--brian

-----Original Message-----
From: gabor farkas [mailto:xl...@po...]=20
Sent: Wednesday, December 05, 2001 1:19 PM
To: gam...@li...
Subject: [GD-Windows] getmainwindow...

hi,

is there in winapi something like getmainwindow()?.

i want to get somehow the window-handle of the main-window of the
application...

thanks,
gabor farkas


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

Re: [GD-Windows] getmainwindow...

[gabor f. <xl...@po...>]

i just wanted to cut winapi appearance to minimum..

it doesn't matter for me if the code for a specific kind of viewport
knows about winapi,
and i can live with the fact that the main-window-code knows
about winapi too,

but i don't want to pass around winapi-related-structures between these
object

for example maybe i'll port this code to a different platform....

i know that maybe for a commercial game project it doesn't pay
off to try to be cross platform,
but this is a free-time/university project... :-)

just to be a bit modular....

and i don't like seeing winapi-code everywhere....
the same for opengl or directx....:-)

btw. findwindow...nice, but you need the window-class too... :-(

i think i'll just define a window-id datatype and cast the WindowHandle to
it and back.
type-safety rules...:-)


bye,
gabor farkas


----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Wednesday, December 05, 2001 10:30 PM
Subject: RE: [GD-Windows] getmainwindow...


> You could use FindWindow(), but why aren't you just caching your app's
> hWnd in a global somewhere?
>
> Brian
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

RE: [GD-Windows] getmainwindow...

[Brian S. <bs...@mi...>]

If you have a child window handle, you can repeatedly call GetParent()
until it returns NULL.

Don't know if that's the "authorized" way, but it works for me.

--brian

-----Original Message-----
From: gabor farkas [mailto:xl...@po...]=20
Sent: Wednesday, December 05, 2001 1:19 PM
To: gam...@li...
Subject: [GD-Windows] getmainwindow...

hi,

is there in winapi something like getmainwindow()?.

i want to get somehow the window-handle of the main-window of the
application...

thanks,
gabor farkas


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] getmainwindow...

[Jeffrey K. <JK...@nv...>]

If you app is active, you can use GetForegroundWindow().

Jeff Kiel


-----Original Message-----
From: Brian Hook [mailto:bri...@py...]
Sent: Wednesday, December 05, 2001 4:30 PM
To: gam...@li...
Subject: RE: [GD-Windows] getmainwindow...


You could use FindWindow(), but why aren't you just caching your app's
hWnd in a global somewhere?

Brian


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] getmainwindow...

[Brian H. <bri...@py...>]

You could use FindWindow(), but why aren't you just caching your app's
hWnd in a global somewhere?

Brian

[GD-Windows] getmainwindow...

[gabor f. <xl...@po...>]

hi,

is there in winapi something like getmainwindow()?.

i want to get somehow the window-handle of the main-window of the
application...

thanks,
gabor farkas

RE: [GD-Windows] Opening a browser window

[Andrew G. <And...@ho...>]

Beware! 

With ShellExecute, the operation string must correspond to one of the valid
operations listed for that file type in the registry (stored in
HKEY_CLASSES_ROOT, in this case HKEY_CLASSES_ROOT\htmlfile). If you specify
an operation that is not listed there, then ShellExecute will fail. This may
be the case with Opera/Mozilla or older versions of IE.

Since I don't use them, I really have no idea whether this is the case, but
it's a heads-up for something to watch for. Perhaps it wouldn't be a bad
idea to test the return of ShellEx with 'opennew' and if that fails, fall
back to 'open'

Andrew Grant
Hothouse Creations 



> -----Original Message-----
> From: Ed Sinjiashvili [mailto:ed...@sw...]
> Sent: 04 December 2001 07:40
> To: gam...@li...
> Subject: Re: [GD-Windows] Opening a browser window

> The following works for me (tested on W98/IE4 only):
> ShellExecute(NULL, "opennew", 
>              "http://your_page_here.html", NULL, NULL, SW_SHOWNORMAL);
> 
> --
> Ed
> 


This email is covered by the following disclaimer, please read before
accepting this email. http://www.hothouse.org/disclaimer/

Re: [GD-Windows] Opening a browser window

[Ed S. <ed...@sw...>]

Brian Hook <bri...@py...> writes:

> Right now I'm opening a browser window using:
> 
>     ShellExecute( NULL, 
>                   "open", 
>                   "http://www.pyrogon.com", 
>                   NULL, 
>                   NULL, 
>                   0 );
> 
> This works fine, however it has a notable problem in that it usurps
> existing open browser windows.  While annoying, it's also really bad
> when you accidentally take over a pop up ad which may have a reduced set
> of functionality (no scroll bars, no resizing) and which may also be
> instinctively closed without realizing that it's no longer a popup ad.
> 
> I'd like to be able to force open a new browser window altogether
> without having to know the name of the app they use for their browsers.
> I suppose that in the worst case I could query what app they use for
> file type URL and then use that...but damn, that seems nasty.  Is there
> a simpler way?
The following works for me (tested on W98/IE4 only):
ShellExecute(NULL, "opennew", 
             "http://your_page_here.html", NULL, NULL, SW_SHOWNORMAL);

--
Ed

[GD-Windows] izfree Windows Installer tools migrating to sourceforge.net

[Rich <leg...@xm...>]

Hi,

Anyone using Windows Installer for their installation may find this of
interest.  (If anyone has coded DirectX Setup in their WI-based
installation, please email me so I can compare notes.)

I'm in the process of migrating my MSI database tools to
sourceforge.net under the project name "izfree".  (See if you can
figure out the satire in that name.)  The existing release of the
tools is available at <http://www.xmission.com/~legalize/installer/>.

<http://sourceforge.net/projects/izfree/> is the project home page.
There isn't much there yet except a task list and a feature request
survey.

In the near future I will move my database tools from my home page
over to there.  I decided not to call it "msidb" anymore as Stefan
Krueger pointed out that there is already a tool by that name included
with the MSI SDK.

Please do fill out the feature request survey, but keep in mind the
following:

- I have very limited time right now to work on this project as I need
  to finish my book first.  However, a coworker (a fellow
  InstallShield victim) has more free time than I and he is working on
  the GUI dialog editor.

- The tools are intended to initially augment Orca instead of
  replacing it, as I am uninterested in re-inventing the wheel when we
  are still two horses shy of a cart and two horses.

- These tools are intended to get the job done, not look like a GUI
  designer's wet dream.  The emphasis is on function and ease of use,
  but not cosmetic sugar.

The tools and source will be placed under GPL to ensure that the work
remains available to all developers.
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book http://www.xmission.com/~legalize/book/
    Don't Support Spammers!  Boycott Fractal Painter 7!
     http://www.xmission.com/~legalize/spammers.html

RE: [GD-Windows] Opening a browser window

[Brian S. <bs...@mi...>]

You could do it with a bit of JavaScript hackery.

A link like this will launch your url in a new window:

	javascript:open("http://www.pyrogon.com","brians_new_window")

Of course to be really clever you probably want to execute some more
javascript to have the first window go back to the page it was on
(because you wouldn't want the user to lose the X10.com ad that had
popped up).   And at that point, you're probably talking about writing
your Javascript to a file and viewing that in the browser instead of a
one-liner. =20

But it's a start...

--brian

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Monday, December 03, 2001 1:01 PM
To: gam...@li...
Subject: [GD-Windows] Opening a browser window


Right now I'm opening a browser window using:

    ShellExecute( NULL,=20
                  "open",=20
                  "http://www.pyrogon.com",=20
                  NULL,=20
                  NULL,=20
                  0 );

This works fine, however it has a notable problem in that it usurps
existing open browser windows.  While annoying, it's also really bad
when you accidentally take over a pop up ad which may have a reduced set
of functionality (no scroll bars, no resizing) and which may also be
instinctively closed without realizing that it's no longer a popup ad.

I'd like to be able to force open a new browser window altogether
without having to know the name of the app they use for their browsers.
I suppose that in the worst case I could query what app they use for
file type URL and then use that...but damn, that seems nasty.  Is there
a simpler way?

Brian


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows