| mekkatorqu (242) | |||||||
ok so I have main dialog with 5 tabs (child dialogs) and I want to capture left mouse click in first tab (TabOneDlgProc/IDD_ONE), however the wndproc is not even processing lbuttondown in my case, I've tried it in main window and it's working (when I click to main window, so somewhere outside the tab dialog), everything else related to tab one dialog is workign fine
| |||||||
|
Last edited on
|
|||||||
| mekkatorqu (242) | |
| someone? | |
|
|
|
| andywestken (1966) | ||
|
I think the problem is that your DialogProc -- TabOneDlgProc -- is calling DefWindowProc. With a DialogProc you should just return TRUE if you handle a message, or FALSE it you don't. You should not call DefWindowProc. From the MSDN entry "DialogProc call back function"
By returning to DefWindowProc you are probably disrupting the dialog manager's own message handling. Andy PS I also assume that you're adding a set of tabs to part of a window, rather than the whole of it. If it's the latter case, you should check out the PropertySheet function. | ||
|
Last edited on
|
||
| mekkatorqu (242) | |
| yup returning false works fine, also Ididn't really understand propertysheet, what does it do? how can it be used? only function of the function is not gonna help me (msdn) | |
|
|
|
| andywestken (1966) | |
|
PropertySheet() creates a set of PropertyPages, which are basically the same as your child dialogs. in one go, and handles the tabs, etc. for you. That is, it's a tabbed dialog. A lot of apps use a property sheet for their options, inc. Outlook and Word. Property Sheet (Windows) http://msdn.microsoft.com/en-us/library/windows/desktop/bb774540%28v=vs.85%29.aspx | |
|
|
|
| mekkatorqu (242) | |
| and in what aspects is propertysheet better than dialogs? since with dialogs I can handle their messages with wndproc, which is good so I can customize app better and also it's easier to find errors and code it etc since I have wndproc for each tab :P | |
|
|
|
| andywestken (1966) | |
|
Depends on what you want to do. Property sheets are better when you want to create an multi-tabbed options dialog or a wizard. They do a bit of the work for you, cf. custom dialogs. The (embedded) dialog approach allows you to customise more. Note that each property page has its own dialogproc. Plus you can provide a callback function for the whole property sheet. Andy | |
|
|
|
| mekkatorqu (242) | |||
|
thanks, but I'll just stick to my dialogs for now :P anyway, R/LBUTTONDOWN is not working when I click on any control (except edit, this one has its own menu that appears), how do I fix this? also is there any way to change the menu of edit control or do I have to subclass it? edit: also how do I get ID of control my mouse is currently at? I've found only "GetCapture" but it's returning 0 when I click on my tab dialog (real ID is 102)
| |||
|
Last edited on
|
|||
| andywestken (1966) | |
|
(I think the main reason PropertySheet was introduced was to make it easier to code tabbed dialogs with a consistent look. Not sure it's easier overall.) #1 WM_LBUTTONDOWN works for me with static controls (I based my code on that which you posted, assuming that that MainDlgProc was the app's main (dialog) window). But not for buttons, combo boxes, etc. This will require subclassing, which could be tricky to do for some controls (e.g. the combo box) without upsetting the normal behaviour (see GetComboBoxInfo) #2 For the Edit control context menu, yes, you've got to subclass it. #3 GetCapture tells you who's captured the mouse. i.e. the window which called SetCapture() #4 To find out if a point is on a control you can: 1. Call ChildWindowFromPoint to get the handle of the window whose rect contains the point. Then compare the handle returned against the handles of the various controls. 2. Get the client rect of each control (GetClientRect), map it to the parent windows coordinates (MapWindowPoints), and then hittest it (PtInRect). In both cases, if you want to test your static controls you'll have to give them all a unique ID, rather than just use IDC_STATIC. Andy PS Is WM_CONTEXTMENU worth looking at? | |
|
Last edited on
|
|
| mekkatorqu (242) | |||||
|
#1 when I use WM_RBUTTONDOWN in MainDlgProc (I use this dialog only to handle tabs and tab dialogs, the other things are in TabOneDlgProc and other TabDialogs) it works only when I click on main dlg area (screen below) when I use it in TabOneDlgProc it works only if I click to blank area (clicking on static or any other control does nothing, I have SS_NOTIFY enabled (I use LBUTTON (WM_NOTIFT or how's that message called) to create another dialogs to change stuff, I want to use RBUTTON to change settings of those stats (str, int, agi, hero image etc)) using WM_CONTEXTMENU works on everything except edit control (yes even on buttons) http://filebeam.com/8e493ce70c40520c63399cbb0e6f634c.jpg #2 how exactly does subclassing works? I know what it does, but how does the proc works? will something like this work (this is not actual code, just something I think of that it works like) // subclassing editcontrol and own menu
none of them is working, did I do something wrong? // I tried HIWORD and LOWORD with wParam to get IDC_HEROIMAGE, same result... but when I have only WM_CONTEXTMENU and I click on static control it works and brings message box | |||||
|
Last edited on
|
|||||
| andywestken (1966) | |
|
#1 The behaviour you describe makes sense to me, with the exception of the static controls. That works for me. The WM_RBUTTONDOWN and WM_LBUTTONDOWN message are generated in TabOneDlgProc when I click on a static control (and I've added a hittest using ChildWindowFromPoint to confirm I've clicked in the right place). If you want MainDlgProc to handle all the (e.g.) WM_RBUTTONDOWN, then get TabOneDlgProc to relay the message to MainDlgProc using SendMessage. #2 The catch with WM_CONTEXTMENU is that the point it gives you is in scren coordinates, so you've got to convert it to client coords before you hittest (with ScreenToClient function). #3 I don't see you doing the actual subclassing. Are you calling SetWindowLongPtr with GWLP_WNDPROC to set the new WndProc? And then using GWLP_WNDPROC to call on to the old WndProc from the subclass proc? Andy | |
|
|
|
| andywestken (1966) | |||||||
|
A stripped down test for subclassing. Andy
| |||||||
|
Last edited on
|
|||||||
| mekkatorqu (242) | |||||||||||
|
looks like I kinda explained it wrong, so I'll try to make it as clear as possible :P #1 I'm using SS_NOTIFY for every static control I want to work with
now I want to bring messagebox ONLY when I click on IDC_HEROIMAGE with RBUTTON, since RBUTTONDOWN is not working I'm using CONTEXTMENU, instead of
(used to find if CONTEXTMENU works) I use
which is not working (it never displays messagebox), even when I try HI or LO WORD I tried to add
but this gives me kinda random number, not actual ID of control MSDN:
so what I need is a way to find if "CONTEXTMENU" is called while clicking on IDC_HEROIMAGE (except the coords thing) EVERYTHING I do, I do in TabOneDlgProc
edit: didn't notice your code, gonna try to modify mine to match yours "window" finding, will report soon edit2: okay, looks like everything I was doing wrong with coords was not using "&p" but "p" as second argument in ScreenToClient function, anyway I'm still curious about first problem (#1) in this post | |||||||||||
|
Last edited on
|
|||||||||||
| andywestken (1966) | |||
|
#1 The wParam is the window handle, not the control ID. So, sorry, I was being a bit dopey. You can test this wParam value against GetDlgItem with IDC_HEROIMAGE. (there are situation where the other approach ight be needed, but prob. not here). #2 Here, you need to use the address-of operator (&)
(this trick is required for a number of other Win32, like GetClientRect) | |||
|
Last edited on
|
|||
| mekkatorqu (242) | |||
|
I already did that (edited my post :P) I'm just curious now about the first problem, with wParam, getting control without coords #2 when creating menu I have to use this to get sub menu
what do I have to use when I actually want to show whole menu ? let's say my menu looks like this: File: -Open -Close Tools: -Tool1 -Tool2 when I usse submenu it will only show Open+Close or Tool1+Tool2 (depends on which submenu I chose) but how do I show File/Tools where you can mouseover and it will popup (with >) Open/Close or Tool1/2 just like when you go to start > all programs ... I hope u udnerstand :P do I have to create submenu in submenu or is it possible to actually show whole menu? edit: acutally I was testing it like tht at first, but it didn't work because error C2446: '==' : no conversion from 'HWND' to 'WPARAM'I just now realized that (HWND)wParam works fine :/ | |||
|
Last edited on
|
|||
| andywestken (1966) | ||||||
|
How is your menu defined? Like this?
TrackPopupMenu only works with popups From MSDN
So, this should work (if you use hSubMenu)
Andy | ||||||
|
Last edited on
|
||||||
| mekkatorqu (242) | |||
I have this
which is working fine, when I want to call test1/test2 I use submenu 0 and submenu 1 for test3, I was just curious if I can call WHOLE menu just like you create it for window, but it's not important at all, thanks as usual! | |||
|
|
|||