Changing Address of Variable in Class

[wdolson]

I'm incorporating a Dialog Bar into my application. I'm getting some very weird behavior for one of the member variables.

I have a boolean called m_bBarEnabled. The constructor for the class initializes it to FALSE. At that point, the address of m_bBarEnabled is 0x3d62d0. I have &m_bBarEnabled set as a watch. After the program's documents have loaded in OnNewDocument, I want to enable the bar so some further initializing can happen (which need the loaded data from the Doc). So OnNewDocument calls the Dialog Bar's member function EnableBar() before quitting. All EnableBar does is set m_bBarEnabled to TRUE. When I put a break point in EnableBar, the address of m_bBarEnabled is 0x88ce50! It sets that address to TRUE and returns.

Next I put a break in the OnUpdateCmdUI of the Dialog Bar and when that is called, the address of m_bBarEnabled is back to 0x3d62d0 and is set to FALSE (because when EnableBar was called, it was at a different address).

What's going on? There is only one instance of the Dialog Bar in the program. I double checked that before writing. Why is this variable moving in memory? I've never seen this behavoir before.

More Information: I put in some more breakpoints. The constructor for the dialog bar was being called before the Create in the MainFrame. I moved the initialization to OnCreate and the address for m_bBarEnabled changed to 0x88ce50. However, when OnUpdateCmdUI is called after initialization, the address of m_bBarEnabled is still 0x3d62d0 and it's not set correctly.

There seems to be a second instance of the dialog bar created. This is mostly code ported from VC 6 to VC 2005. I found some other changes that I had to make to get the thing to compile. This mechanism worked fine in VC 6.

Is there anyone who has a clue what's I'm missing here?

Bill

[Alex F]

Set breakpoint to constructor to test how many times class is created.
In the place where &m_bBarEnabled is incorrect, check "this" value. Maybe function is called by corrupted or uninitialized pointer.

[wdolson]

The class is only created once.

When OnCreate is called, this points to 0x3d6074
When EnableBar is called, this points to 0x88cbf4
When OnUpdateCmdUI is called, this points to 0x3d6074

Bill

[Alex F]

I mean: see all class fields in the Watch window, using "this" pointer. Is instance valid or looks like junk?
How many times class constructor is called?

[Skizmo]

How many times class constructor is called?

Constructors can only be called once, and that is when the class is created.

[Thu]

Constructors can only be called once, and that is when the class is created.

It is called whenever you inititilize an instance of it. Code bloat is a phenom of redundancy, of course out of....interest Take nice care of yourself, don't make your code lamer please...

[Skizmo]

It is called whenever you inititilize an instance of it.

That's what I said... as soon as it is created.

[Khiem]

I am on my way, read what I posted

[wdolson]

Looks like some kind of old feud or something here.

Anyway, the solution to my problem in case anybody runs into this again:

When I first set this up, AfxGetMainWnd() was returning NULL. I did some searches on the web and found somewhere (don't think it was on codeguru) where someone suggested using AfxGetApp() instead. That returned a value, so I used it.

When I was getting down the the call to the Dialog Bar, on a mouse over, I noticed that the hWnd for the Dialog Bar was zero. It stilled called the Dialog Bar. It appears that it sort of pseudo created another instance. Why I didn't get an Assert is a mystery, but it was allowed. Maybe something in Microsoft's implementation of CDialogBar that is incomplete?

Anyway, I eliminated the EnableBar() call completely and found another way to initialize the bar. I set up some booleans that are set False at creation and True after the control initializes. The code that checked for these flags also had to check for the hWnd of the controls to be non-zero. It would try to run before the controls were there otherwise.

This mechanism works fine and I was able to complete the Dialog Bar without further problems shortly after getting past this stumbling block.

Thanks for the help, it did get me thinking about the problem in a different way which led to the solution.

Bill