How to make sure if a pointer is still good

[NittiLin]

Originally posted by TheCPUWizard
Most of the (is valid pointers) simply check if the pointer points to:

1) A valid memory location
2) The start of a memory allocation unit
3) The start of a memory allocation unit of the correct size.

Which of the above it does depends on the function, see the docs.

There is ABSOLUTELY no way to (generically) tell if a (raw) pointer still points to the actual instance of a certain object that is was originally assigned to.

Yeah, that's what I'm worring about. System might reallocate memory and some pointers might point to an address that is using by other application.

Thanks,

Nitti

[VladimirF]

When you create your 'B' dialogs, use SetOwner() to set a back pointer to the 'A' dialog, then in the B's OnDestroy() send a message to its owner, passing B's HWND or ID, and have 'A' remove it from its list.

[TDM]

One thought would be to use a linked list. Each "node" in the list would be a a class derived from CDialog ('B' dialog). The "head" of the list would be in the 'A' class. Have a member in the 'B' dialog class that points to the next dialog in the list. Also have some type of identifier in the 'B' class to identify each node in the list (could just be an int). When you create the dialogs add a new node to the list ( a new B dialog) and assign it an identifier. When you destroy the dialog, go through the list and remove node matching the identifier that was destroyed. That way your list would only contain dialogs that are actually visible and would allow as many dialogs as the system resources would allow.

TDM

[souldog]

Originally posted by NittiLin
Yeah, that's what I'm worring about. System might reallocate memory and some pointers might point to an address that is using by other application.

Thanks,

Nitti

Well that can not happen. If you are at the application level, then
you can not (in theory) corrupt other applications.

I would use reference counted smart pointers, as has been
mentioned. There are so many ways to handle this problem.

If Dialog A will definitely exist for the life of the modeless dialogs
then just pass a pointer to it into the constructor for the modeless
dialogs, then you don't have to worry about owner/parent etc..

[souldog]

I also would not use a CArray or linked list. I would instead use
a std::map and have dialog A generate keys when modeless
dialogs are created. The modeless dialog can then use this key and the pointer to dialog A to be removed from the map when it
is closed.

[John E]

Originally posted by NittiLin
I have 'A' dialog, which creates multiple modeless 'B' dialogs. I use GetDesktopWindow() as 'B' dialogs' parent for some reason.

Just out of curiosity - what is the reason ?? Why can't the 'A' dialog be the parent? You could still use GetDeskTopWindow() for whatever you need to use it for...

[NittiLin]

Originally posted by souldog
Well that can not happen. If you are at the application level, then
you can not (in theory) corrupt other applications.

I would use reference counted smart pointers, as has been
mentioned. There are so many ways to handle this problem.

If Dialog A will definitely exist for the life of the modeless dialogs
then just pass a pointer to it into the constructor for the modeless
dialogs, then you don't have to worry about owner/parent etc..

So far, program still doesn't have any problems although the testing is still going on. Dialog A does exist for the life time of all the modeless dialogs.

Originally posted by souldog
I also would not use a CArray or linked list. I would instead use
a std::map and have dialog A generate keys when modeless
dialogs are created. The modeless dialog can then use this key and the pointer to dialog A to be removed from the map when it
is closed.

Thanks for the advise. I've never thought of this before. I'll do some research on it.

Thanks,

Nitti

[NittiLin]

Originally posted by John E
Just out of curiosity - what is the reason ?? Why can't the 'A' dialog be the parent? You could still use GetDeskTopWindow() for whatever you need to use it for...

I want dialog A to be top most only. If dialog A is the parent of all the dialog B, when I bring dialog A to topmost, all the dialog B will be on topmost as well. This is the reason that I can't use dialog A to be the parent of dialog B.

Thanks,

Nitti

[NittiLin]

Originally posted by TDM
One thought would be to use a linked list. Each "node" in the list would be a a class derived from CDialog ('B' dialog). The "head" of the list would be in the 'A' class. Have a member in the 'B' dialog class that points to the next dialog in the list. Also have some type of identifier in the 'B' class to identify each node in the list (could just be an int). When you create the dialogs add a new node to the list ( a new B dialog) and assign it an identifier. When you destroy the dialog, go through the list and remove node matching the identifier that was destroyed. That way your list would only contain dialogs that are actually visible and would allow as many dialogs as the system resources would allow.

TDM

I use CArray to do the similar thing. Since souldog suggested me not to use CArray, I'm gonne check out the way he suggested.

Thanks,

Nitti

[NittiLin]

Originally posted by VladimirF
When you create your 'B' dialogs, use SetOwner() to set a back pointer to the 'A' dialog, then in the B's OnDestroy() send a message to its owner, passing B's HWND or ID, and have 'A' remove it from its list.

Good ideas. Thanks a lot. I'll check it out.

Thanks,

Nitti