I've been trying to write into the registry some data not related to the application in case.
As it happens CWinApp functions are not intended for such usage -- they are intended to write the registration data of the running application. In that case the correct usage is as follows:
1. Place call to the SetRegistryKey function in the "InitInstance". For example,
If you used the application wizard to start your application building, and you specified that you were building an MFC application... then you should already have a CWinApp derived class somewhere in your project. Don't redefine the call, just call it from somewhere in there (if you redefine you'll override the original call).
And you can only the CAux::SetRegistryKey(); method without initializing an object if the call is static (something you don't want to do anyway).
Sorry, it doesn't work either.
I do have a CWinApp derived class in my project (refer to my previous reply).
It is a simple dialog application. I need to write to the registry some value
and -- before using WriteProfileString -- I try to call SetRegistryKey.
There is the code snippet:
I'd tried various approaches until I found an excellent C++ Tutorial (http://www.learncpp.com/) and got the understanding that my problem is related to the inheritance subject. As it is clearly stated in the tutorial:
2. The protected access specifier allows derived classes to directly access members of the baseclasswhile not exposing those members to the public.
I see now that I have to make call within but my derived class. It does work except that there reveals another problem -- WriteRegisterString needs an access to the m_pszRegistryKey variable which is an attribute of CWinApp class. IAE, I have to learn a bit more on the subject.
The discussion was very helpful and I thank you for the time you spent on it.
Trying to convert a very old C program to Microsoft Visual Studio 2010. After some warnings, including some extern "C"'s and all that, everyting compiles. However, the linker keeps calling that is misses an external symbol "_VERSION". I have been looking through all code and can't find any reference to it. I included a char * _VERSION somewhere in my main source (within and outside the extern "C") Still complains.
Does anyone have an idea how I could find out where the linker finds the call of this reference? Is there som option that can persuade the linker to provide me with much more information or something like that?
This is getting extremely frustrating, since everything else seems to work as expected. Just this @!$@! _VERSION....
Well, the point is that the software calls some other C modules. I did scan all sources for as far as I can see, but they are not all included in the VS2010 solution so I had to so that by hand. However, I would have expected to at least get rid of the linker's complaint by adding a variable _VERSION in my own source code. Possibly with a wrong type, but then I would expect another complaint from Microsoft somewhere....
I fully agree with you all. Point however is that I need to find-out where my code is using it anbd even more: when I simply introduce a global variable _VERSION, I would no longer expect an "unresolved external" for _VERSION.
Well you do have a point there. The linker complains about a straight _VERSION. As far as I know, it would complain about something including the name mangling normally. It does however mean that - if I introduce a variable named _VERSION - that will probably be called differently internally. I have been looking into a way to remove the name mangling from a particular variable, but have not yet found anything.
the extern C removes name mangling... so there may be some definition that you need to wrap with that somewhere in your source... you just have to find it (on a related note, wish linkers gave better error information, lol)
I didn't realise from the original post that the name _VERSION was the name given by the linker, and is mangled.
The unmangled name is VERSION, so that's what we're looking for here. Also, see my other post.
Can't remember off the top of my head, but I don't think it does... remember that the linker works with the compiler output... so it doesn't necessarily have an association between an unfound object and where it was referenced in source (although it may, this is more of a linker design feature).