Using rc.exe and porc.exe

[TimoVJL]

What we think to happen when compiling this with rc.exe/porc.exe ?
test.c

Code Select Expand

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#ifdef RC_INVOKED
LANGUAGE LANG_ENGLISH,SUBLANG_ENGLISH_US

1001 DIALOGEX DISCARDABLE 6, 18, 210, 142
STYLE DS_SHELLFONT|WS_POPUP|DS_MODALFRAME|DS_CONTEXTHELP|DS_3DLOOK|WS_CAPTION|WS_SYSMENU|WS_VISIBLE
CAPTION "Dialog"
FONT 8, "Tahoma", 0, 0, 1
{
  CONTROL "OK", IDOK, "Button", WS_TABSTOP, 160, 5, 45, 15
  CONTROL "Cancel", IDCANCEL, "Button", WS_TABSTOP, 160, 23, 45, 15
}
#endifEDIT: filename to test is something like test.c

[Vortex]

Hi Timo,

It looks like that the RC_INVOKED option is assumed to be activated for both of the resource compilers.

[frankie]

It's a predefined macro of resource compiler.
The scope is to filter parts of file (typically headers included in rc files) that could not, or must not, be compiled by resource compiler.
See http://msdn.microsoft.com/en-us/library/windows/desktop/aa381032(v=vs.85).aspx

[TimoVJL]

But why RC_INVOKED is omitted if filename ends .c ?
Any documentation for that ?

[frankie]

I don't understand your point.
You mean that if you create a .c file and feed it to porc or rc the symbol RC_INVOKED is omitted?
For both resource compilers?
I can only immagine that C compiler and resource compilers share the same preprocessor that in turn uses file extension to tune its own behaviour. Should be so it seems a kind of bug unless there is some more complicate and strange strategy due to visual programming (stdafx, MFC, ATL, etc).