Loading .wav files to resource

I am trying to load a .wav file using a .rc file, and play it using the play sound function, but when the program calls for the sound to be played, I get an error saying that the program stopped working. here is my code

Code:

#include "Resource.h"

//Icon
IDI_DUCKHUNT ICON "Res\\DuckHunt.ico"
IDI_DUCKHUNT_SM ICON "Res\\DuckHunt_sm.ico"

//Bitmap
IDB_DUCK BITMAP "Res\\Duck.bmp"
IDB_BACKDUCK BITMAP "Res\\BackDuck.bmp"
IDB_BACKGROUND BITMAP "Res\\Background.bmp"
IDB_MENUSCREEN BITMAP "Res\\MenuScreen.bmp"

//WAV
IDW_GUNSHOT WAVE "Res\\GunShot.wav" /*in the IDE, "WAVE" isn't highlighted like the other resources */

//Cursor
IDC_CROSSHAIR CURSOR "Res\\CrossHair.cur"

Code:

//incon range: 1000 - 1999
#define IDI_DUCKHUNT 1000
#define IDI_DUCKHUNT_SM 1001

//Bitmap range: 2000 - 2999
#define IDB_DUCK 2000
#define IDB_BACKDUCK 2001
#define IDB_BACKGROUND 2002
#define IDB_MENUSCREEN 2003

//WAV sound range: 3000 - 3999
#define IDW_GUNSHOT 3000

//Cursor range: 4000 - 4999
#define IDC_CROSSHAIR 4000

Code:

PlaySound((LPSTR)IDW_GUNSHOT, g_hInstance, SND_ASYNC | SND_FILENAME);

Thanks.


P.S
When I use "Res\\GunShot.wav" in the play sound function, it works just fine.

Wrong PlaySound flag, bub. You want SND_RESOURCE instead of SND_FILENAME.

Oops, I feel really stupid for missing that, thanks.

Originally Posted by SMurf

Wrong PlaySound flag, bub. You want SND_RESOURCE instead of SND_FILENAME.

And since he's using numberical resource values he also needs to run the IDC number through MAKEINTRESOURCE first...

Of course he could eliminate that step entirely by naming things instead of numbering them...

Code:

// in resources
GUNSHOT WAVE "Res\\GunShot.wav" 

// in main code
PlaySound("GUNSHOT",g_hInstance,SND_ASYNC | SND_RESOURCE);

No headers or conversions required...

I did notice that, but checking the MAKEINTRESOURCE macro...

Code:

#define MAKEINTRESOURCE(i)  (LPTSTR) ((DWORD) ((WORD) (i)))

bjan311 has already cast it to LPSTR, not spectacularly tidy but it wouldn't cause the error described.

I think you miss my point...

If you use resource names instead of numbering things, you don't need to do the conversion through the header file at all. I seldom have a resources.h file in my projects because I give my resources text names which is Windows native way of acessing resources.

When I first started with C (after pascal and a very short stint with Delphi) I was surprised to see that almost every source I studied was using resource identifiers instead of names. Pelles C even generates these "translation" headers automatically... It's an extra step and in code that is resource intensive (lots of dialogs and bitmaps for example) there is a noticeable degredation in performance because of it.

Of course the method using MAKEINTRESOURCE works... but it's needlessly complex and a fair bit slower than going directly to a named resource.

Unless your resources names are one character long they take more space to store than an ID and, from looking at BaseDllMapResourceIdW in kernel32.dll / kernelbase.dll, every lookup with a string resource name incurs a heap allocation and uppercasing of the string into the copy, while integral ids are returned from it verbatim.

During the actual resource directory lookups in LdrpCompareResourceNames_U (ntdll.dll), string names are compared with wcsncmp, while ordinals are compared with a subtraction. With all of that going on, I wouldn't say that makes for a performance increase from using names.

Examination of Windows dll's shows named resources take up about 8% of the total resources in executable modules. OSResCount.cpp in that linked directory is the program that collected the results, and the text files are the results for that OS.

Wow... nothing like thinking it to death.

I do it the way I do it because it's far simpler (in standard C-99 anyway) to just call resources by name which is the way most windows functions --LoadIcon, LoadCursor, PlaySound, CreateDialog etc--naturally access these items.

The only numbered resources I use are stringtables and I do that mainly because the LoadString function wants a number.

Originally Posted by CommonTater

I do it the way I do it because it's far simpler (in standard C-99 anyway) to just call resources by name which is the way most windows functions.

I always use numbers.

One reason is that I can align them to manipulate a series of controls in a loop.

for(int i=;i<(IDC_LASTCTRL-IDC_FIRSTCTRL);i++)
SetDlgItemText(hWnd, i+IDC_FIRSTCTRL, array[i].m_Some_DB_Field);

Originally Posted by novacain

I always use numbers.

One reason is that I can align them to manipulate a series of controls in a loop.

for(int i=;i<(IDC_LASTCTRL-IDC_FIRSTCTRL);i++)
SetDlgItemText(hWnd, i+IDC_FIRSTCTRL, array[i].m_Some_DB_Field);

Control identifiers inside a dialog are actually numbers so there's not much choice in the matter. (These are actually the same numbers returned by the "hMenu" parameter of CreateWindow in WM_COMMAND messages)

That's all fine and good... but it's not what I was talking about.

I'm talking about the difference between:

Code:

CreateDialog(Inst,MAKEINTRESOURCE(IDC_MYDIALOGTEMPLATE),MainWind,&TosserFunc);

and

Code:

CreateDialog(Inst,"MYDIALOG",MainWind,&TosserFunc);

Others...
LoadIcon(Inst,"MAINICON");
LoadCursor(Inst,"MYCURSOR");
LoadMenu(Inst,"MAINMENU");

Look in the various resource involving functions. Even RegisterClass asks for the name of the main menu... not it's number.

That's because if the functions were typed to take USHORTs you'd have no way of specifying a string, vice-versa you can use all three conventions. I'd wager if they were created today the argument would be ULONG_PTR or similar.

The method you use is your choice, but giving patently and demonstrably incorrect information in support of it to people who may not know better benefits nobody.

Originally Posted by adeyblue

The method you use is your choice, but giving patently and demonstrably incorrect information in support of it to people who may not know better benefits nobody.

Thank you, I really needed to be called a liar today.

Originally Posted by CommonTater

Control identifiers inside a dialog are actually numbers so there's not much choice in the matter. (These are actually the same numbers returned by the "hMenu" parameter of CreateWindow in WM_COMMAND messages)

The HMENU param of the CreateWindow() is cast to be the window's ID number if you use the WS_CHILD style.

Originally Posted by CommonTater

Look in the various resource involving functions. Even RegisterClass asks for the name of the main menu... not it's number.

They ask for either a null terminated string or an int (with the high order word set to zero).


I am pointing out that using numbers everywhere appears to me to be a much more consitent and logical approach because you can use int IDs for all of these calls (but you can not use strings for all of these calls).

What about consuming the messages generated by events in your application?

Event messages like WM_COMMAND, WM_NOTIFY etc supply the ID number and HANDLE

Originally Posted by novacain

The HMENU param of the CreateWindow() is cast to be the window's ID number if you use the WS_CHILD style.

What about consuming the messages generated by events in your application?

Event messages like WM_COMMAND, WM_NOTIFY etc supply the ID number and HANDLE

Those are numerical references, so, naturally, I handle them numerically...

Please read what I wrote initially and my clarifications... I am only talking about loading certain items ( icons, cursors, wave files, menus, dialog templates, etc) from a program's resources. This has nothing to do with message tossing...