0

I have been learning Win32 GUI programming today and I have come across a question I have not found the answer to.

Why do resource.hpp files define resources with such high ID numbers? For instance, the tutorial I am following has 2 resources in resources.rc - A MENU and an ICON. The MENU has 3 MENUITEMs total.

Here is the tutorial's resource.hpp (which defines the int IDs for these resources):

    #define IDR_MYMENU               101    // MENU ID
    #define IDI_MYICON               102    // ICON ID
    #define ID_FILE_EXIT             40001  // MENUITEM 1 ID
    #define ID_STUFF_GO              40002  // MENUITEM 2 ID
    #define ID_STUFF_GOSOMEWHEREELSE 40003  // MENUITEM 3 ID

Why not instead use understandable IDs such as:

    #define IDR_MYMENU               1  // MENU ID
    #define IDI_MYICON               2  // ICON ID
    #define ID_FILE_EXIT             3  // MENUITEM 1 ID
    #define ID_STUFF_GO              4  // MENUITEM 2 ID
    #define ID_STUFF_GOSOMEWHEREELSE 5  // MENUITEM 3 ID

As more resources are added, you simply increase the count. I can understand a buffer to separate MENUITEMS from ICONS and so on; but why this much of a buffer with so few resources?

I also understand this resource.hpp file (tutorial's) was generated by a program, but the question still stands for me.

Could someone please enlighten me? Thank you.

TorbenC
  • 153
  • 1
  • 2
  • 9
  • 1
    It is arbitrary. The machine doesn't care nor does it think that 40000 is a special number. It doesn't use base 10 for numbers. If this was generated by a resource editor then the hint is that it doesn't deal with collisions very well. Few do. – Hans Passant Apr 22 '14 at 13:19

3 Answers3

3

It's fine that they are high because there is still no chance that you'll run out.

So, why are higher numbers better than low numbers?

You want IDs to be as unique as possible. Not just between each other, but when you see "40089" anywhere in your program, it's nice to have a good hint that it's a resource ID. This can help debugging.

I have seen a similar pattern in databases, where there is no type safety and every object has an ID. So for example if you see an ID of "20032" somewhere, you know already that it's an Employee.ID, while "22011" is most likely a Department.ID etc.

Personally I don't understand the point of separating icon resource IDs from menu items. They are all just resource IDs, and this distinction seems pretty arbitrary. Jumping from 100 to 40000 guarantees that you'll never run out of IDs for icons.

Of course this is not a complete answer. Why the specific pattern? Why the specific numbers? I doubt you'll find a real answer to this stuff; it's just how it's implemented.

tenfour
  • 36,141
  • 15
  • 83
  • 142
  • Thank you for explaining this, considering a few utilities made for creating resource files, I assume there is probably a "standard" of sorts for these numbers though. – TorbenC Apr 22 '14 at 13:37
  • The "standard" is whatever the Visual Studio resource editor gives you. Normally people don't write `resource.h` by hand. – tenfour Apr 22 '14 at 16:03
1

Please look in the windows headers. Very many IDs are predefined and have a specific meaning, many supported by the native APIs directly. Because MS defined those IDs, they are in their private space, which starts at the low end. You really don't want to redefine them and have to support code where you cannot be sure which definition counts now.

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
0

Programs get changed all the time. If you happen to add a menu command some year you really don't want to have to renumber all of the subsequent IDs. Numbers are free - leave some room for the future.

ScottMcP-MVP
  • 10,337
  • 2
  • 15
  • 15