Broblem with resources

[Otto]

Well, I borrowed a DirectX Trainer book from library, originally for learning DirectDraw, it was published at the time of DX 7.

There was a code of how to get a pointer to the resource's first byte, but it dosn't seem to work in my compiler. (I'm using MS Visual C++ 2008 Express edition, that was compiled with older MS VC.)

The code was similiar to this:

BYTE *data;
data=LockResource(LoadResource(NULL,FindResource(NULL,IDR_MYRESOURCE,"TYPE")));

I searched the web and headers, find some answers how to fix this, and now it looks like this:

LPVOID data;
data=LockResource(LoadResource(NULL,FindResource(NULL,IDR_MYRESOURCE,L"TYPE")));

Still I get some warnings, that I want to get rid of and when I check if "data" is NULL, it is!

So, If you have answers, please post.

Thanks,
Otto

[exception]

(a) Don't use 'NULL' in C++ programs. Microsoft does it, true. One more reason not to do it. Quoting Stroustrup:

In C, it has been popular to define a macro NULL to represent the null pointer. Because of C++'s tighter type checking, the use of plain 0, rather than any suggested NULL macro, leads to fewer problems. If you feel you must define NULL, use
const int NULL = 0;

(b) Well, DirectX 7 is like, 10 years old by now? You could expet this working if it were a POSIX-System, but with Windows problems seem to be unavoidable.
(c) (Why not use OpenGL anyways? Or, if you feel DirectX is better suited for Windows, a wrapper library like SDL? This way, your code will at least have the chance to be portable. And if you want to write a game, what it looks like to me, then you might someday want such cool functions like realtime-scheduling, which is available under Linux, but AFAIK not windows. Plus, you have way better networking support. Again, it is true that most games are written for Windows, but also again, this is not a technical decision)
(d) Any further and possibly helpful suggestions can be made if and only if you post the errors and warnings of your compiler and the sourcecode context which produces them.

[guestgulkan]

The:
1. Find it
2. Load it
3. Lock it
is the usual way to do work with resources.

The current way:

LPVOID data;
data=LockResource(LoadResource(NULL,FindResource(NULL,IDR_MYRESOURCE,L"TYPE")));

is basically the same as the old way (except that the return type from LockResource has changed as you have noticed.

The usual problem is the FindResource function.
Usually You should specify as the second parameter the name (string) of the resource and the type of resource as a text string as the third parameter:
here is a snippet from the HELP section of Visual Studio :

HRSRC FindResource(
HMODULE hModule,
LPCTSTR lpName,
LPCTSTR lpType
);

Parameters

hModule
[in] Handle to the module whose executable file contains the resource.
A value of NULL specifies the module handle associated with the image file
that the operating system used to create the current process.
lpName

[in] Specifies the name of the resource. For more information,
see the Remarks section below.
lpType
[in] Specifies the resource type. For more information,
see the Remarks section below. For standard resource types,
see Resource Types.

Return Value

If the function succeeds, the return value is a handle to the specified
resource's information block. To obtain a handle to the resource, pass this
handle to the LoadResource function.
If the function fails, the return value is NULL. To get extended error
information, call GetLastError.

Remarks

If IS_INTRESOURCE(x) is TRUE for x = lpName or lpType, x specifies the
integer identifier of the name or type of the given resource. Otherwise, those parameters are long pointers to null-terminated strings.
If the first character of the string is a pound sign (#), the remaining
characters represent a decimal number that specifies the integer identifier
of the resource's name or type. For example, the string "#258" represents
the integer identifier 258.

To reduce the amount of memory required for a resource, an application should refer to it by integer identifier instead of by name.

An application can use FindResource to find any type of resource, but this
function should be used only if the application must access the binary
resource data when making subsequent calls to LockResource.

[Otto]

Thanks, I saw that code, but I didn't first understand it.
Now I did.

It works now, I wrote:

LPVOID data;
data=LockResource(LoadResource(NULL,FindResource(NULL,L"#139",L"MAP")));

Now I come up with problems on converting from LPVOID to unsigned char*, so that I could read bytes from that file.

So, how can I convert from LPVOID to unsigned char*?
(I tried byte1 = (unsigned char*)data;, but my compiler says "There is no context in which this conversion is possible").

[guestgulkan]

What you are doing is trying to convert the pointer itself.

You need to dereference it so:

byte1 = *(unsigned char*)data;

[guestgulkan]

As a matter of fact just convert the LPVOID returned from LockResource to a char* to beign with - it will save a lot of casting about later on.

char *data;
data=(char*) LockResource(LoadResource(NULL,FindResource(NULL,L"#139",L"MAP")));

[Otto]

Thanks alot, that helped much.