{"id":107928,"date":"2023-03-13T07:00:00","date_gmt":"2023-03-13T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107928"},"modified":"2023-03-10T17:52:33","modified_gmt":"2023-03-11T01:52:33","slug":"20230313-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230313-00\/?p=107928","title":{"rendered":"What is the expression language used by the Resource Compiler for non-preprocessor expressions?"},"content":{"rendered":"

I noted some time ago that the Resource Compiler’s preprocessor is not the same as the C preprocessor<\/a>: Although it supports the same expression language, it does not support directives like #pragma<\/code>.<\/p>\n

There is a second expression language used by the Resource Compiler, and that’s the one used to define resources. Surprisingly, this expression language is different from the preprocessor expression language.<\/p>\n

For one thing, it has a much reduced set of operators, and no operator precedence. All binary operators are left-associative, and parentheses can be used for grouping.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
+<\/code>a<\/var><\/td>\nUnary plus<\/td>\n<\/tr>\n
-<\/code>a<\/var><\/td>\nUnary minus<\/td>\n<\/tr>\n
~<\/code>a<\/var><\/td>\nUnary bitwise negation<\/td>\n<\/tr>\n
a<\/var> +<\/code> b<\/var><\/td>\nBinary addition<\/td>\n<\/tr>\n
a<\/var> -<\/code> b<\/var><\/td>\nBinary subtraction<\/td>\n<\/tr>\n
a<\/var> |<\/code> b<\/var><\/td>\nBinary bitwise OR<\/td>\n<\/tr>\n
a<\/var> &<\/code> b<\/var><\/td>\nBinary bitwise AND<\/td>\n<\/tr>\n
a<\/var> | NOT<\/code> b<\/var><\/td>\nBinary bit clear (a<\/var> & ~<\/code>b<\/var>)<\/td>\n<\/tr>\n
0x<\/code>dddd<\/var><\/td>\nHexadecimal constant<\/td>\n<\/tr>\n
0o<\/code>dddd<\/var><\/td>\nOctal constant<\/td>\n<\/tr>\n
dddd<\/var><\/td>\nDecimal constant<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The NOT<\/code> operator looks weird, but the idea is that you can write something like<\/p>\n

WS_OVERLAPPEDWINDOW | NOT WS_MINIMIZEBOX\r\n<\/pre>\n
The WS_OVERLAPPED\u00adWINDOW<\/code> style is a composite style:<\/p>\n
#define WS_OVERLAPPEDWINDOW (WS_OVERLAPPED     | \\\r\n                             WS_CAPTION        | \\\r\n                             WS_SYSMENU        | \\\r\n                             WS_THICKFRAME     | \\\r\n                             WS_MINIMIZEBOX    | \\\r\n                             WS_MAXIMIZEBOX)\r\n<\/pre>\n
Appending a | NOT WS_MINIMIZEBOX<\/code> means that you want all of the styles that come with WS_OVERLAPPED\u00adWINDOW<\/code> except for WS_MINIMIZE\u00adBOX<\/code>.<\/p>\n
Note that all operators have equal precedence, so 1 | 1 - 1<\/code> parses as (1 | 1) - 1<\/code>, which is 0. On the other hand, in C, the -<\/code> operator has higher precedence than |<\/code>, so the C expression 1 | 1 - 1<\/code> parses as 1 | (1 - 1)<\/code>, which is 1.<\/p>\n
Since the preprocessor directives follow C expression rules, you can get into an odd situation where the same expression comes out to a difference value depending on the context in which you use it:<\/p>\n
#if 1 | 1 - 1\r\nDLG_MYDIALOG DIALOG 1 | 1 - 1, 0, 42, 42\r\nBEGIN\r\nEND\r\n#endif\r\n<\/pre>\n
The 1 | 1 - 1<\/code> in the #if<\/code> statement is a preprocessor directive, and it evaluates to 1, so the #if<\/code> condition is truthy, and the contents generate a dialog resource. On the other hand, when the compiler sees the 1 | 1 - 1<\/code> in the DIALOG<\/code> statement, it is evaluated as a resource constant, which produces zero.<\/p>\n
Note also that the resource expression language lacks many operators, most notably multiplication.<\/p>\n
Another oddity is that the resource expression language uses 0o<\/code> as the octal prefix rather than a simple 0<\/code> like in C. This means that 010<\/code> evaluates to 8 when used in a preprocessor expression, but it evaluates to 10 when used in a resource expression. This is particularly troublesome if you put the definition in a header file that is shared with C\/C++ code:<\/p>\n
\/\/ resource.h\r\n#define DLG_AWESOME 010\r\n\r\n\/\/ contoso.rc\r\n#include \"resource.h\"\r\n\r\nDLG_AWESOME DIALOG ...\r\n\r\n\/\/ contoso.cpp\r\n#include \"resource.h\"\r\n\r\nDialogBox(instance, MAKEINTRESOURCE(DLG_AWESOME), ...);\r\n<\/pre>\n
Even though they are both using DLG_AWESOME<\/code>, the resource compiler sees it as a resource expression, and the 010<\/code> is the decimal constant 10. On the other hand, the C++ compiler sees it as as a C++ expression, and the 010<\/code> is an octal constant which evaluates to 8.<\/p>\n
Moral of the story: Don’t use leading zeroes.<\/p>\n
There’s another quirk of the resource compiler expression language, and that’s the concept of the “initial value”.<\/p>\n
In many cases, the value you are specifying comes with an initial value, and the expression you provide is implicitly treated as combining with the initial value as if by logical “or” (|<\/code>). In other words, if you write some expression e<\/code>, the Resource Compiler acts as if you had actually written<\/p>\n
initial | e\r\n<\/pre>\n
Note the absence of parentheses around the e<\/code>.<\/p>\n
Here is the table of initial values for various control types:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Control<\/th>\nUnderlying control<\/th>\nWith initial style<\/th>\n<\/tr>\n
PUSHBUTTON<\/code><\/td>\nButton<\/td>\nBS_PUSHBUTTON<\/code><\/code><\/td>\n| WS_TABSTOP<\/code><\/td>\n<\/tr>\n
DEFPUSHBUTTON<\/code><\/td>\nButton<\/td>\nBS_DEFPUSHBUTTON<\/code><\/code><\/td>\n| WS_TABSTOP<\/code><\/td>\n<\/tr>\n
CHECKBOX<\/code><\/td>\nButton<\/td>\nBS_CHECKBOX<\/code><\/code><\/td>\n| WS_TABSTOP<\/code><\/td>\n<\/tr>\n
AUTOCHECKBOX<\/code><\/td>\nButton<\/td>\nBS_AUTOCHECKBOX<\/code><\/code><\/td>\n| WS_TABSTOP<\/code><\/td>\n<\/tr>\n
STATE3<\/code><\/td>\nButton<\/td>\nBS_3STATE<\/code><\/code><\/td>\n| WS_TABSTOP<\/code><\/td>\n<\/tr>\n
AUTO3STATE<\/code><\/td>\nButton<\/td>\nBS_AUTO3STATE<\/code><\/code><\/td>\n| WS_TABSTOP<\/code><\/td>\n<\/tr>\n
RADIOBUTTON<\/code><\/td>\nButton<\/td>\nBS_RADIOBUTTON<\/code><\/td>\n<\/tr>\n
AUTORADIOBUTTON<\/code><\/td>\nButton<\/td>\nBS_AUTORADIOBUTTON<\/code><\/td>\n<\/tr>\n
GROUPBOX<\/code><\/td>\nButton<\/td>\nBS_GROUPBOX<\/code><\/td>\n<\/tr>\n
PUSHBOX<\/code><\/td>\nButton<\/td>\nBS_PUSHBOX<\/code><\/code><\/td>\n| WS_TABSTOP<\/code><\/td>\n<\/tr>\n
LTEXT<\/code><\/td>\nStatic<\/td>\nSS_LEFT<\/code><\/code><\/td>\n| WS_GROUP<\/code><\/td>\n<\/tr>\n
RTEXT<\/code><\/td>\nStatic<\/td>\nSS_RIGHT<\/code><\/code><\/td>\n| WS_GROUP<\/code><\/td>\n<\/tr>\n
CTEXT<\/code><\/td>\nStatic<\/td>\nSS_CENTER<\/code><\/code><\/td>\n| WS_GROUP<\/code><\/td>\n<\/tr>\n
ICON<\/code><\/td>\nStatic<\/td>\nSS_ICON<\/code><\/code><\/td>\n<\/tr>\n
EDITTEXT<\/code><\/td>\nEdit<\/td>\nES_LEFT | WS_BORDER<\/code><\/code><\/td>\n| WS_TABSTOP<\/code><\/td>\n<\/tr>\n
LISTBOX<\/code><\/td>\nListBox<\/td>\nLBS_NOTIFY | WS_BORDER<\/code><\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
These initial styles are documented in the Resource Compiler documentation. For each control, look at the section of the documentation that says “If you do not specify a style, the default style is\u2026” That default style is the value that your custom style is combined with.<\/p>\n
It didn’t fit in the above table, but dialogs themselves have an initial style of WS_CAPTION<\/code> if you gave the dialog a CAPTION<\/code>.<\/p>\n
The “initial value” trick makes the NOT<\/code> behavior a little more comprehensible, because it lets you write things like<\/p>\n
    LTEXT \"Hello\", -1, 4, 80, 160, 10, NOT WS_GROUP<\/span> | SS_SUNKEN\r\n<\/pre>\n
The NOT WS_GROUP<\/code> combines with the initial value to produce a net result of<\/p>\n
SS_LEFT | WS_GROUP | NOT WS_GROUP | SS_SUNKEN\r\n<\/pre>\n
Translating this into C, you get<\/p>\n
((SS_LEFT | WS_GROUP) & ~WS_GROUP) | SS_SUNKEN\r\n<\/pre>\n
which is SS_LEFT | SS_SUNKEN<\/code>. The NOT WS_GROUP<\/code> removes the WS_GROUP<\/code> style that came by default with the LTEXT<\/code> statement.<\/p>\n
Bonus chatter<\/b>: Why are there two different expression languages?<\/p>\n
The resource language is designed for use in resource statements. The NOT<\/code> syntax, in particular, is handy for removing styles from the initial styles that come with certain controls.<\/p>\n
The preprocessor language is designed for use in preprocessor statements. And the preprocessor language matches the C programming language because preprocessor statements commonly occur in header files which are consumed by both the Resource Compiler and the C\/C++ compiler. It would be a very difficult bug to track down if a #if<\/code> statement in a header file evaluated differently depending on whether you included it from a C\/C++ file or from a resource file.<\/p>\n","protected":false},"excerpt":{"rendered":"
Oddly different for a different audience.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-107928","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Oddly different for a different audience.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107928","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=107928"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107928\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=107928"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107928"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107928"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}