Re: 0xFEEEFEEE
So basically, you're own sort of garbage collector. I do something similar
with objects that are owned by threads. Instead of inserting or deleting
objects I just flag them as no longer needed and eventually the thread
releases them. However, unless you delete all of the uses of the pointer
before deleting the pointer there will always be a window of opportunity for
it to get used when you didn't intend it to. I think that is what you are
saying here (mark it deleted, but don't actually delete it until the other
stuff is fixed up first). This sounds like a good plan if the tree is not
accessible.
Tom
"AliR (VC++ MVP)" <AliR@online.nospam> wrote in message
news:ftb4k.1213$LG4.996@nlpi065.nbdc.sbc.com...
I'm assuming that where you delete the item you don't have access to the
tree control.
The way I normally handle something like this is when an object that is
referenced in multiple places is getting deleted, I put the pointer in a
DeletedItemsList (this can be a list, vector, CList, CArray....) and I
signal that UI objects that they need to refresh themselves. At that
point they would first check their items against the DeleteItemsList and
if there is a match they would delete their UI item (tree item, list
item....) before refreshing anything else. And then clear the deleted
list.
AliR.
"GT" <ContactGT_removeme_@hotmail.com> wrote in message
news:0015424d$0$2882$c3e8da3@news.astraweb.com...
I have a CTreeCtrl derived class. When I populate the tree, I create (new)
an object and point the treeitem's LParam at the new object. The object
that I create is basically a struct and holds some numerical information
and a pointer to another object - a 'Worker' object.
At some point in time, the Worker object is deleted from the system. This
is expected and normal behaviour. At some point in time following the
Worker delete, the appropriate redraw method is automatically triggered
and I then cycle round my tree and check that all nodes are in the
correct place. When I reach the nodes that have LParams pointing to an
object that points to a deleted Worker, I have a problem. When I retreive
my tree's pointer to the deleted Worker, it is not a NULL pointer, but
points to what appears to be a valid object (memory location looks
normal). I know that (in debug mode) this memory location is not valid,
but if I try to do anything to what appears to be a normal object, then I
get a crash - accessing 0xfeeefeee error - accessing a memory location
that has been erased.
I understand why I am seeing this crash - I am using an area of memory
that has gone! But I need help with the code required to test for this
situation!
Just to recap - My CTreeCtrl items hold a pointer to an object, which in
turn holds a pointer to a Worker object that has been deleted. That
Worker pointer looks OK (valid memory address), so testing against NULL
is useless, but when I try to do anything to the object it I get a crash
(due to it being deleted). How do I test for this?
I have tried calling an operation on the Worker object inside a try-catch
loop, so that I can deal with the problem in the catch area, but it still
just crashes before hitting the catch(...) line.
Thanks,
GT