-
April 2nd, 2004, 05:51 PM
#16
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
-
April 2nd, 2004, 05:55 PM
#17
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.
Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
Convenience and productivity tools for Microsoft Visual Studio:
FeinWindows - replacement windows manager for Visual Studio, and more...
-
April 2nd, 2004, 08:35 PM
#18
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
-
April 2nd, 2004, 10:14 PM
#19
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..
Wakeup in the morning and kick the day in the teeth!! Or something like that.
"i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."
-
April 2nd, 2004, 10:16 PM
#20
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.
Wakeup in the morning and kick the day in the teeth!! Or something like that.
"i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."
-
April 3rd, 2004, 12:43 AM
#21
Re: How to make sure if a pointer is still good
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...
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
April 6th, 2004, 12:12 PM
#22
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
-
April 6th, 2004, 12:15 PM
#23
Re: Re: How to make sure if a pointer is still good
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
-
April 6th, 2004, 12:17 PM
#24
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
-
April 6th, 2004, 12:18 PM
#25
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
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|