|
Use EnumWindows to enumerate the windows.
Use GetWindowRect to get the rectangle of the window.
Then use PtInRect to check if the point of interest lies within the window rectangle.
|
|
|
|
|
Additionally to what the others have said, the "get the rectangle and check if the point is inside it" method might not work with non-rectangular windows (layered windows with per-pixel alpha (see here[^]) or windows with a non-rectangular window region (see here[^]). I wonder if sending these kinds of windows the WM_NCHITTEST[^] message could tell you if the point is on the window or not.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
That's what RealChildWindowFromPoint handles.
/* Charles Oppermann */
http://weblogs.asp.net/chuckop
|
|
|
|
|
Load and Display a Dialog Box from Simple Win32 DLL with No MFC support
|
|
|
|
|
Don't you like DialogBox function[^]?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I have declared a global coblist in my Snapshot.CPP file on the top of the file.
CObList SnapList;
void CSnapShot::OnDelete()
{
int index = 2; //Want to delete some item from the list
pos = SnapList.FindIndex(index);
CSnp *pSnp = (CSnp*)SnapList.GetAt(pos);
SnapList.RemoveAt(pos);
delete pSnp;
}
My question is: Is it a must to delete the object after removing the pos from the SnapList using the statement:
SnapList.RemoveAt(pos); delete pSnp;
or
we can just remove the statement
delete pSnp;
from the above code.
|
|
|
|
|
manoharbalu wrote: Is it a must to delete the object after removing the pos from the SnapList
Yes, when the list is the owner (single holder) of its entries 
They sought it with thimbles, they sought it with care;
They pursued it with forks and hope;
They threatened its life with a railway-share;
They charmed it with smiles and soap.
|
|
|
|
|
What Eugen said is correct: it depends who is considered the 'owner' of this object, i. e. for allocating and deallocating the required resources.
If you have references to that same object outside the list, then you must make sure that either these are not being used after deleteing your object, or you must choose another owner, because in this case the list must not delete its elements! But that means that whatever other object (or function) owns the elements, it is that object (or function) which is responsible for deleting the objects to prevent memory leaks.
|
|
|
|
|
Sorry... I didnot get your point.
In my example, I am going to remove the element from the list, becaue I dont need the element anymore in future.
My only question is....
Is it enough that I just remove the element just by using
SnapList.RemoveAt(pos);
or
Should I Save the old pointer for deletion and remove the element from list and then delete the object as below in 3 steps.
CSnp *pSnp = (CSnp*)SnapList.GetAt(pos);
SnapList.RemoveAt(pos);
delete pSnp;
Pl tell me which one is correct... the first one with one step or the second one with 3 steps.
|
|
|
|
|
If you create an object on the heap using new, then you must call delete on it at some point. So, to answer your question, the second option is correct. The first option will only remove the pointer from the list, making it inaccessible - but the object will still exist on the heap. Option 2 is not the only option though, and that is why I talked about the concept of 'owner' and suggested alternate ways.
Regarding the concept of 'ownership':
As a general rule, to minimize the risks of memory leaks or memory corruption, you should always make sure that each object created on the heap 'belongs' to some function or other object. What this means is, in case of a function 'owner', you make sure that at the end of that function you delete the created object; or, in case of another object, you call delete on the created object inside the destructor of the owner object.
By following this rule you will always be able to find the delete statement belonging to a new very quickly, and that way you can make sure it's not gone missing!
|
|
|
|
|
|
Hi,
I assume in your code you instantiated a CSnp object and added a pointer to it to the Snaplist. The Snaplist just contains the pointer, calling removeAt on it will remove the pointer but not the allocated memory that it points to. So yes you will need to manually call delete on it! Or else you will get a memory leak.
|
|
|
|
|
It's syntax that we have to put '&' right before pointer to member function.
For example here.
class Test;
typedef void (Test::*fpop)();
class Test
{
public:
void Op1(){}
};
int main(){
fpop pFunc;
pFunc = &Test::Op1;
return 0;
}
However, when I take a look at ON_COMMAND(or any other messages) in MFC, it seems a bit different from what I think is right.
VS6.0 is okay. It follows the right syntax as you see below.
You can clearly see & before memberFxn.
#define ON_COMMAND(id, memberFxn) \
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSig_vv, (AFX_PMSG)&memberFxn },
But in VS2008, it goes a bit weird. There is no & before memberFxn.
#define ON_COMMAND(id, memberFxn) \
{ WM_COMMAND, CN_COMMAND, (WORD)id, (WORD)id, AfxSigCmd_v, \
static_cast<AFX_PMSG> (memberFxn) },
Moreover, in spite of the fact that there is no & before memberFxn,
each line below works perfectly.
1. ON_COMMAND(ID_APP_ABOUT, CSingleApp::OnAppAbout) // &
2. ON_COMMAND(ID_APP_ABOUT, &CSingleApp::OnAppAbout) // no &
I tried to find why, and I was curious if it could be because of static_cast<> but it turned out that static_cast has nothing to do with it.
So I am wondering why in VS2008 I have 2 choices where I put & or I don't have to put &.
|
|
|
|
|
It goes waaaay back to the original C language of the 1970's. In the first edition of "The C Programming Language",
Kernighan and Ritchie wrote: ... an identifier which is declared "function returning ...", when used except in the function-name position of a call, is converted to "pointer to function returning ...".
In the second edition, the wording has changed to
... and expression of type "function returning T," except when used as the operand of the & operator, is converted to "pointer to function returning T."
In other words, the & has always been optional.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
First of all, Thanks you so much for answering my question.
However,
I think that case that you mentioned is about just "pointer to function."
Peter_in_2780 wrote: the & has always been optional.
But when using "pointer to MEMBER function", the & is not optional, but necessary as you see below.
class Test;
typedef void (Test::*fpop)();
class Test
{
public:
void Op1(){}
};
int main(){
fpop pFunc;
pFunc = Test::Op1; return 0;
}
I know that MFC's message pump consists of Pointer to member function, which needs the &.
Could you explain why?
Thanks.
|
|
|
|
|
Digging a bit deeper, I came across this[^] right here on CP. Seems VC6 and VC7 break the rules as you noticed... See just after the second code block below the heading "Member Function Pointers".
Way too much information in that article for me! But if I ever need to go there...
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
That looks like a great article... Looks like I have some reading ahead of me...
|
|
|
|
|
It's a simple problem.
At First, the massage map is implemented by an array with a structure.
Secondly, the syntax error is actually a kind of warning.
Third and finally, The massage map function starts with disabling the warning by a macro PTM_WARNING_DISABLE
So, you may assign the function to a pointer without reference operator &.
Here is an example,
PTM_WARNING_DISABLE
fpop pFunc[1] = {Test::Op1};
PTM_WARNING_RESTORE
However, an interest problem occurs when you call the function with the function pointer.
And the problem is all yours.
modified on Wednesday, August 31, 2011 5:42 AM
|
|
|
|
|
did you mean to send this message to the OP? ...because I didn't ask the question...
|
|
|
|
|
Hi,
GetCharABCWidthsFloat returns different values on XP, Vista and Windows 7. How can I solve this problem?
Is there a workaround method to handle this?
Best,
|
|
|
|
|
The size of characters can depend on a lot of things, how the given system renders the fonts, the DPI settings, what font you use of course, display drivers probably, and who knows what else. I supose the GetCharABCWidthsFloat is made to give the sizes based on the current "configuration", which is probalby not the exact same on those systems. Why is that a problem for you?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
I used same "configuration." GetCharABCWidthsFloat returns different values on XP, Vista and Windows.
You can have a test run. You will see it.
Is there any GDI function call can do the same job?
Thanks,
|
|
|
|
|
Just have a test run, you will see it. It will be a problem for you also.
Thanks
|
|
|
|
|
I don't doubt that it returns different sizes, i don't understand why you say it is a problem. I don't see the documentation stating that it will return the very same values "everywhere", it might return different values on the same operating system in different DPI settings. It is kind of like saying that GetVersionEx has a problem because it returns different values under different operating systems.
Or i am completely missing your point here...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Yes, you completely miss my point here.
Forget it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
