I have a general question regarding a variable I'm trying to maintain a value for that is changing ambiguously throughout my program.
Here's a brief outline of how my program is doing the assignment/retrieval:
I set the value using MyClass::setMyVal(setThis); and later I retrieve the value using MyClass::getMyVal();.
static LPCTSTR myVal;
static void setMyVal(CString setVal)
myVal = setVal;
static LPCTSTR getMyVal()
Even further in my program, I want to access the value again and do so in the same way (getMyVal()). However, the value is no longer the same. There have been no other calls to the setMyVal method, so I'm wondering if I have a memory issue and the memory location containing this value is being overwritten with a new value?
I can't really post all the code I'm using for confidentiality reasons, but I was hoping someone might be able to recognize a misstep in my pattern. I have been able to identify where the value changes, but it's a completely arbitrary location with no reference to anything in this class, so I don't understand why it's changing.
If you need any more info, let me know. And thanks for reading through this, if anything. =]
Compiler: Microsoft Visual Studio 6.0
O/S: Windows XP
I overcame the issue simply by calling getMyVal and assigning it to a local variable at the beginning of every function that requires it, then before the function exits simply re-assigning this local value to setMyVal. Obviously this is a cheap method and still leaves the main issue unaddressed (i.e. why it's doing this). Before I did so, each successive function that called getMyVal arbitrarily changed the value of the variable in MyClass to a value that that function had (at seemingly random, although I noticed it was one of the first values that the functions worked with it all cases).
Edit2: The above solution worked because I kept the volatile LPCTSTR pointing to a CString object that I kept re-initializing in memory. While it worked okay, it wasn't a very efficient way of maintaing the value I wanted and wasn't guaranteed to work (since any function I didn't call it in that wrote over that memory location would screw up the LPCTSTR value).