NickRepin
asked on
Detecting dialog controls from point
I need to obtain dialog control handle from screen coordinates to display context help for it.
When user right-clicks on dialog item, I process WM_CONTEXTHELP. I have cursor coordinates of clicked area.
Next, I try to detect which item has been clicked.
I call WindowFromPoint. It returns right handles, EXCEPT for static and groupbox controls - in this case it returns dialog handle.
I try to call ChildWindowFromPoint. It returns only groupbox handles even if user clicks on item inside of groupbox (eg, button, static control, etc).
I try to call ChildWindowFromPointEx with all flags - SKIPTRANSPARENT, SKIPDISABLED - it produces the same result.
I cannot use the combination of WindowFromPoint and ChildFromPoint because I cannot obtain static control handle.
I don't want to use WinHelp(... CONTEXTHELP..).
Is there any way to solve this problem except of enumerating all childs, retrieving its coordinates...?
When user right-clicks on dialog item, I process WM_CONTEXTHELP. I have cursor coordinates of clicked area.
Next, I try to detect which item has been clicked.
I call WindowFromPoint. It returns right handles, EXCEPT for static and groupbox controls - in this case it returns dialog handle.
I try to call ChildWindowFromPoint. It returns only groupbox handles even if user clicks on item inside of groupbox (eg, button, static control, etc).
I try to call ChildWindowFromPointEx with all flags - SKIPTRANSPARENT, SKIPDISABLED - it produces the same result.
I cannot use the combination of WindowFromPoint and ChildFromPoint because I cannot obtain static control handle.
I don't want to use WinHelp(... CONTEXTHELP..).
Is there any way to solve this problem except of enumerating all childs, retrieving its coordinates...?
Why not WindowFromPoint or ChildWindowFromPoint API/CWnd-members
These don't require a loop
These don't require a loop
ASKER
snoegler, I'm sorry, but I should reject your answer. And that is why:
1) 'except of enumerating all childs, retrieving its coordinates' - from my question, see above
2) The loop will not so simple because of the group boxes will be retrieved before controls inside this groupboxes. And your loop will always return group box handles, not handles of controls the user really clicked on. Again, I can write this loop but I looking for more easy and fast solution.
answers2000, please, see full text of my question. Window/ChildFromPoint doesn't work.
1) 'except of enumerating all childs, retrieving its coordinates' - from my question, see above
2) The loop will not so simple because of the group boxes will be retrieved before controls inside this groupboxes. And your loop will always return group box handles, not handles of controls the user really clicked on. Again, I can write this loop but I looking for more easy and fast solution.
answers2000, please, see full text of my question. Window/ChildFromPoint doesn't work.
ASKER
To retrive correct results, the loop must be like following:
child=GetWindow( GW_CHILD)
child=GetWindow(child,GW_L
while(child) {
...
child=GetWindow(child,GW_P
}
ChildWindowFromPoint uses 'forward direction' loop.
But what about strange behavior of WindowFromPoint?
child=GetWindow( GW_CHILD)
child=GetWindow(child,GW_L
while(child) {
...
child=GetWindow(child,GW_P
}
ChildWindowFromPoint uses 'forward direction' loop.
But what about strange behavior of WindowFromPoint?
>> answers2000, please, see full text of my question. Window/ChildFromPoint doesn't work.
sorry about that, I read the Q and then go so absorted in snoeggler's efforts, I forgot half the Q!
WindowFromPoint is documented as ignoring certain windows
(begin quote)
WindowFromPoint does not retrieve a hidden, disabled, or transparent window, even if the point is within the window. An application should use the ChildWindowFromPoint member function for a nonrestrictive search.
(end quote)
Dialog's seem to have special knowledge of statics (and for all I know group boxes, quite likely given their effect on tabbing) which is probably why it screws up. I am fairly sure Windows dialog manager's dialog class takes over painting the statics (not the static controls themselves) at least to some extent so this is probably something to do with it.
>> ChildWindowFromPoint uses 'forward direction' loop.
You are right it is documented as doing so
sorry about that, I read the Q and then go so absorted in snoeggler's efforts, I forgot half the Q!
WindowFromPoint is documented as ignoring certain windows
(begin quote)
WindowFromPoint does not retrieve a hidden, disabled, or transparent window, even if the point is within the window. An application should use the ChildWindowFromPoint member function for a nonrestrictive search.
(end quote)
Dialog's seem to have special knowledge of statics (and for all I know group boxes, quite likely given their effect on tabbing) which is probably why it screws up. I am fairly sure Windows dialog manager's dialog class takes over painting the statics (not the static controls themselves) at least to some extent so this is probably something to do with it.
>> ChildWindowFromPoint uses 'forward direction' loop.
You are right it is documented as doing so
ASKER
I think only MS knows the answer.
Groupboxes and statics are not disabled,invisible or transparent windows. And WindowFromPoint should not ignore them.
As to painting, you are right,
groupbox paints its border, but doesn't paint background. Nevertheless, its not transparent, and WindowFromPoint should return its handle. It seems it's one more Windows bug.
The only solution is a loop with backward child enumeration.
Groupboxes and statics are not disabled,invisible or transparent windows. And WindowFromPoint should not ignore them.
As to painting, you are right,
groupbox paints its border, but doesn't paint background. Nevertheless, its not transparent, and WindowFromPoint should return its handle. It seems it's one more Windows bug.
The only solution is a loop with backward child enumeration.
>> Groupboxes and statics are not disabled,invisible or transparent windows.
Aren't they transparent ? The parent window determines the color (WM_CTLCOLOR messages)
Aren't they transparent ? The parent window determines the color (WM_CTLCOLOR messages)
side question.... Are the statics and group boxes in question happening to use -1 for their control id?
if so, give them a real value instead of -1 like 109, 110, etc
if so, give them a real value instead of -1 like 109, 110, etc
ASKER
I think the transparent window is the one which has EX_TRANSPARENT style. WM_CTLCOLOR also sends to buttons, listboxes, etc, but their handles WindowFromPoint returns.
duneram, all my controls have different real values.
duneram, all my controls have different real values.
So would I, but there is definitely something funny in the dialog manager
as you say only MS knows the answer
as you say only MS knows the answer
Hi, it is well-nown problem in Win31/Win95! There is no way
to solve its problem, exept numerate all windows,
get all Rect and other, as you write in Comment.
Some times ago we test all other ways, but ....
I don't now is it reply for you question, but no other!
Alex
to solve its problem, exept numerate all windows,
get all Rect and other, as you write in Comment.
Some times ago we test all other ways, but ....
I don't now is it reply for you question, but no other!
Alex
ASKER
AlexVirochovsky,
you made me to make hard decision. Formally you are right, it's the answer. But it's unfairly to Answers2000 and snoegler to give you points. This answer was mentioned before in my and Answers2000's comments.
Sorry.
you made me to make hard decision. Formally you are right, it's the answer. But it's unfairly to Answers2000 and snoegler to give you points. This answer was mentioned before in my and Answers2000's comments.
Sorry.
Nick - reading you last comment I'm not sure how you'd like to procede
Would you like to give (a) snoegler the pts, or (b) me the pts ? or (c) keep the Q open
Would you like to give (a) snoegler the pts, or (b) me the pts ? or (c) keep the Q open
ASKER
Answers200, I think the keeping the Q opened is useless.
Answer it, and I'll give you 350 pts.
Answer it, and I'll give you 350 pts.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Am I wrong or is that I just wasted 35 points for an absolutely useless answer - what a joke
The answer to this question is around - why ? Because SPY++ and a number of other spy type programs actually do exactly what NickRepin was (and I am) looking for
Nick did you ever find a solution ?
The answer to this question is around - why ? Because SPY++ and a number of other spy type programs actually do exactly what NickRepin was (and I am) looking for
Nick did you ever find a solution ?
ASKER
I looked for solution for my particular case (context help in the dialog box) and I already knew about the solution when I asked the question. I asked it just to be sure.
The only answer is that you have to enumerate all windows yourself.
Here is my function which works fine.
HWND FindDialogControl(HWND dlg,POINT p)
{
HWND w=GetWindow(dlg,GW_CHILD);
if(w) {
w=GetWindow(w,GW_HWNDLAST)
while(w) {
if(IsWindowVisible(w)) {
RECT r;
GetWindowRect(w,&r);
if(InRect(&r,p))
return w;
}
w=GetWindow(w,GW_HWNDPREV)
}
}
return 0;
}
But if you want to do what spies do,
well, I think that you have to call WindowFromPoint() first, then recursively enumerate all childs, childs of childs etc using the function above. The most grand-grand...-grandchild containing the point is the right window.
The only answer is that you have to enumerate all windows yourself.
Here is my function which works fine.
HWND FindDialogControl(HWND dlg,POINT p)
{
HWND w=GetWindow(dlg,GW_CHILD);
if(w) {
w=GetWindow(w,GW_HWNDLAST)
while(w) {
if(IsWindowVisible(w)) {
RECT r;
GetWindowRect(w,&r);
if(InRect(&r,p))
return w;
}
w=GetWindow(w,GW_HWNDPREV)
}
}
return 0;
}
But if you want to do what spies do,
well, I think that you have to call WindowFromPoint() first, then recursively enumerate all childs, childs of childs etc using the function above. The most grand-grand...-grandchild containing the point is the right window.
Darrin,
Since the asker only gave a 'D' grade, that should have clued you in on the quality of the answer...
But thats the way life gets thrown at you...
If you want to see something weird check out http://www.duneram.com/cam/index.html (that's live!)
Since the asker only gave a 'D' grade, that should have clued you in on the quality of the answer...
But thats the way life gets thrown at you...
If you want to see something weird check out http://www.duneram.com/cam/index.html (that's live!)
Nick - thanks for the feed back - is
InRect(&r,p)
a helper function of your own ? Can I see it (please)
MTIA
Duneram - nice picture - is there any resemblance between the flash and you ?
DarrinE
InRect(&r,p)
a helper function of your own ? Can I see it (please)
MTIA
Duneram - nice picture - is there any resemblance between the flash and you ?
DarrinE
LOL.... now thats a good laugh...
Hi,
Unless anyone has any objections, I am going to remove this PAQ as it is not a good question to have in the archives since it has no answer.
Speak up if you dont agree.
Ian
Community Support @ Experts Exchange
Unless anyone has any objections, I am going to remove this PAQ as it is not a good question to have in the archives since it has no answer.
Speak up if you dont agree.
Ian
Community Support @ Experts Exchange
Since there is a code solution in it, just make it a free PAQ
Good Idea.
Ian
Ian
ASKER
inline bool InRect(const RECT* r,int x,int y)
{ return x>=r->left && x<r->right && y>=r->top && y<r->bottom; }
inline bool InRect(const RECT* r,POINT p)
{ return p.x>=r->left && p.x<r->right && p.y>=r->top && p.y<r->bottom; }
inline bool InRect(const RECT* r,LPARAM l)
{ return LOWORD(l)>=r->left && LOWORD(l)<r->right && HIWORD(l)>=r->top && HIWORD(l)<r->bottom; }
{ return x>=r->left && x<r->right && y>=r->top && y<r->bottom; }
inline bool InRect(const RECT* r,POINT p)
{ return p.x>=r->left && p.x<r->right && p.y>=r->top && p.y<r->bottom; }
inline bool InRect(const RECT* r,LPARAM l)
{ return LOWORD(l)>=r->left && LOWORD(l)<r->right && HIWORD(l)>=r->top && HIWORD(l)<r->bottom; }
thanks Nick - have a good one (Eatser Egg that is <s>)
ASKER
Thanks, you too.
// 'pntMouse' should contain the screen coordinates of the mouse pointer
RECT rcItem;
HWND hwndCur=GetWindow(hDlg,GW_
for(;;) {
if(hwndCur==NULL) break;
GetWindowRect(hwndCur,&rcI
if(PtInRect(&rcItem,pntMou
hwndCur=GetWindow(hwndCur,
}
// hwndCur==NULL: no hit, hwndCur!=NULL -> dialog control with mouse in it
Hope this helped :)