• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1315
  • Last Modified:

LPCTSTR parameters in Windows API and MAKEINTRESOURCE usage


I previously answered a question about a dialog that won't display, because the calling function was specifying the dialog template name as a string. I remembered I had this problem quite a few times and only using MAKEINTERESOURCE(RESOURCE_ID) would solve the problem.

Wherever resources are involved through the API, LPCTSTR paramters are present in the functions that can receive either a string with the name of the resource (the Dialog Template __name__, in the case above) or the result of the MAKEINTERESOURCE macro.

Looking at the macro, it *seems* to convert the integer ID of a resource to a string, representing the resource name.
If this is the case, how this differs from sending the plain resource name to, let's say, DialogBox function?
When having a dialog with the resource ID of "IDD_DIALOG1", calling
DialogBoxA(hInstance,"IDD_DIALOG1",...) will fail, whereas
DialogBoxA(hInstance,MAKEINTRESOURCE(IDD_DIALOG1),...) will succeed.
The documentation for DialogBox states clearly that the template name can be used to identify the dialog box template. Isn't that the name in the resource? I tried to find the name "IDD_DIALOG1" in the binary resource but found nothing there (Unicode or ASCII) so I am a bit confused about this.

Can anybody shed a bit of light on this? I get the feeling that I am missing something very basic here...
  • 4
  • 2
1 Solution

If you see the MSDN you will find that
The MAKEINTRESOURCE macro is defined as follows:


remember resource id actually is an integer not a string
so this is #defined in the resource.h

in the following way

   #define IDD_DIALOG1   101

now if you see the defination of the MAKEINTRESOURCE you can realize that MAKEINTRESOURCE's return values is string of the (specified value in the low-order word and zero in the high-order word).


m aamir maniar

I have no answer to your question, sorry.
However, I'd like to add that after playing around with this the slightly fuller documentation for "FindResource()" doesn't appear to work as expected either.

In particular, specifying strings instead of ints, or strings that are converted to ints, does not appear to work:
E.g. FindResource(hInst, "IDD_FOO", "RT_DIALOG");
FindResource(hInst, "#IDD_FOO", RT_DIALOG);
or any combination of the above don't work.

I could find no examples which use a string instead of an id. The MFC code for dialogs loads the dialog into memory and calls one of the "CreateDlgIndirect()" type functions faking a modal dialog.

For what it's worth, I remember in the old days (and as it happens nowadays too) you could define a resource to have an id which was actually a string
"MyFunkyDialog" DIALOG 0, 0, 256, 84, etc....
and I assume that's what the string lookup is aimed at.

However it doesn't appear to work now. Possibly the move to unicode string storage in resources has broken the lookup, possibly it just isn't supported anymore, or probably I'm just missing something.

Not an answer, but maybe some resolution

NosfedraAuthor Commented:
Indeed, that's why I was making reference in the post to all functions that take the result of MAKEINTRESOURCE.

My wild guess is that in each such function there is an IF statement that handles the input string.
The result of MAKEINTRESOURCE is actually an address converted to a pointer to a string.
MAKEINTRESOURCE(101 /* IDD_DIALOG1 by default*/) would result in a pointer at 0x00000065. I really doubt that that memory address is used per se.

I wonder if this is what really happens and if this was an early hack of function overloading done in C...

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

MAKEINTRESOURCE converts 0x00000065 into string pointer and returns it. it wont return numeric value.
NosfedraAuthor Commented:
That's what *pointer at* 0x00000065 means.
NosfedraAuthor Commented:
Does anybody else have any other oppinions on this?
NosfedraAuthor Commented:
Thanks for your post WaffleSouffle, I appreciate your interest in it.
I am closing this question as apparently I can't get anymore feedback.


Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now