Please post a minimal but complete example. There's no point in us guessing what code or project settings you have.
Printable View
Hi,
Just checked this out myself, I see the same as you, i.e. expressions are not evaluated, so I looked at this note on the MSDN page you linked:
If a string or a numeric expression is expected, then the expression is not evaluated.
Since a resource ID can be either a string or a numeric expression, looks like that covers it.
Below is the rc file :
// Microsoft Visual C++ generated resource script.
//
#include "resource.h"
#define APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#include "dialogh2.h"
/////////////////////////////////////////////////////////////////////////////
#undef APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
// Français (France) resources
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_FRA)
#pragma code_page(1252)
/////////////////////////////////////////////////////////////////////////////
//
// Icon
//
// Icon with lowest ID value placed first to ensure application icon
// remains consistent on all systems.
IDI_CANCEL ICON "dialogh_bmp/cancel2.ico"
1 ICON "dialogh_bmp/AppIcon.ico"
resource.h :
#define IDC_OK 1
dialogh2.h
#define IDI_CANCEL (IDC_OK+20000)
Creating the file "dialog2.h" is needed (following MSDN method) as read-only file (rc editor will not modify it in any way).
result : IDI_CANCEL should be calculated and get 20001 value. But no, it is not calculated and get a 0 value (cancel2.ico became the application icon)
yes, but there is also
The environment will correctly interpret these calculated symbols as long as:
* The calculated symbols are placed in a read-only symbols file.
* Your resource file contains resources to which these calculated symbols are already assigned.
* A numeric expression is expected.
All this does not appear very clear ....
pascal_33 - I don't wish to seem disrespectful but week after week on this site we find ourselves strugglling to solve problems for newbies who are only willing to release small snippets of code that only tell part of the story. As has been pointed out earlier though, resource IDs can either be numbers or strings. In your case it looks as if an expression like (IDC_OK+20000) will get interpreted as a string, rather than a number which is what you were hoping for. If that doesn't seem to explain your problem, the only other way to solve it would be for you to upload a small (but buildable) example program. Only then will anyone be able to figure out if you've done something wrong.
The last reference uses a different name. Probably a typo in this here post, but just pointing out.
Just want to point out that the "read-only" ONLY refers to the fact that neither VC nor the resource compiler will modify the .h files listed here. They are "readonly" in use.
This does NOT mean that the file in question needs to have the read-only file attribute set or requires some other special rights to actually make it unwritable.
As already said multiple times, please post a sample project.
It could have several reasons. For example, we don't know how you are using those resource IDs in your code.
@ John E and Marc G
I fully understand that you request a full project. But it is very complicated because my app rely on OWLNET libraries (https://sourceforge.net/apps/mediawi...itle=Main_Page)
Nobody want to take hours to install and compile these libraries.
alanjhd08 did a test, and he got same results as me.
My main question is how do you understand this MSDN page ?
http://msdn.microsoft.com/en-us/library/zakskay9.aspx
No, you didn't understand! :(
No one here needs your "full project"!
We need a very small project that reproduces the same problem you do have now! A very very small! (Or you mean that without linking to "OWLNET libraries" you could not reproduce your problem? :confused:
pascal_33 - we all understand how frustrating it is to be constantly asked for a small sample project when you think you've already given us all the relevant information but the simple truth is that we've all been down this road, many times before.
Just last week I spent over two days trying to solve a newbie's question - only for him to admit that he'd found the problem in a completely different part of the code that he hadn't told anyone about!