/////////////////////////////////////////////////////////////////////////////
//
// Icon
//
// Icon with lowest ID value placed first to ensure application icon
// remains consistent on all systems.
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.
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.
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.
"A problem well stated is a problem half solved. - Charles F. Kettering
Creating the file "dialog2.h" is needed (following MSDN method) as read-only file (rc editor will not modify it in any way).
The last reference uses a different name. Probably a typo in this here post, but just pointing out.
Originally Posted by pascal_33
Creating the file "dialog2.h" is needed (following MSDN method) as read-only file (rc editor will not modify it in any way).
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.
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.
yes, typo error, sorry.
About read-only , of course it is not related to the file attributes but to the method used to add it from the "resource include" dialog : "Read-only symbol directives" input
@ John E and Marc G
I fully understand that you request a full project.
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?
And where was this "typo": in the source code or in you posts? If the latter - then it one more reason to post a real working project instead of buggy "snippets" with a lot of "typos"
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!
"A problem well stated is a problem half solved. - Charles F. Kettering
Bookmarks