|
I'm not sure where it's supposed to go. According to MSDN:
"If a window does not display a shortcut menu it should pass this message to the DefWindowProc function. If a window is a child window, DefWindowProc sends the message to the parent. Otherwise, DefWindowProc displays a default shortcut menu if the specified position is in the window's caption.
DefWindowProc generates the WM_CONTEXTMENU message when it processes the WM_RBUTTONUP or WM_NCRBUTTONUP message or when the user types SHIFT+F10. The WM_CONTEXTMENU message is also generated when the user presses and releases the VK_APPS key."
Well, I am not processing it, and it is being forwarded to the SCROLLBAR class's window procedure, which should process it and display the menu. But for some reason it is being returned to my window procedure.
So the message must be getting sent to the wrong window.
To test this I have created two scroll bars, both children to the same window. One is subclassed, but the subclassing does nothing but call the old procedure. Only the subclassed control recieves the message, yet they both send it.
Is there any way to find the window it's being sent to using spy++?
|
|
|
|
|
WalderMort wrote: To test this I have created two scroll bars, both children to the same window. One is subclassed, but the subclassing does nothing but call the old procedure. Only the subclassed control recieves the message, yet they both send it.
How do you know the scrollbar you haven't subclassed isn't getting the message if you haven't
subclassed it?
Based on the behavior you describe, it sounds like the default processing is handled by the
window containing the scrollbar, not by the scroll bar itself. What I mean is, with a basic
window (no subclass or anything) the SCROLLBAR class does nothing with the WM_CONTEXTMENU so it
passes it along to DefWindowProc which forwards it to the parent, the window containing the
scrollbar. The parent displays the scrollbar context menu. So, intercepting it in the
subclassed SCROLLBAR but doing nothing except letting the scrollbar handle it, it ends up back at
the parent window again.
|
|
|
|
|
Mark Salsbery wrote: How do you know the scrollbar you haven't subclassed isn't getting the message if you haven't
subclassed it?
Using Spy++ 
I also watched the messages in the parent window ( which is the same for both scrollbars ). With the NON-subclassed control the parent recieves a WM_ENTERIDLE while the menu is being displayed. With the subclassed control, the parent recieves a WM_CONTEXTMENU message, which I guess is sending back to the child. I must stress, the only difference between the two controls is that one is subclassed. All windows messages are ( or should be ) handled by the same window procedure.
|
|
|
|
|
Ok, so let me get this straight....
In your subclassed scrollbar wndproc you receive a WM_CONTEXTMENU message.
You pass that up to the scroll bar wndproc via CallWindowProc().
The parent window receives a WM_CONTEXTMENU message.
The subclassed scrollbar wndproc receives another WM_CONTEXTMENU message. (???)
|
|
|
|
|
Confusing I know...
The subclassed scrollbar sends a WM_CONTEXTMENU ( I guess to the parent ). The parent recieves a WM_CONTEXTMENU then sends a WM_CONTEXTMENU (I guess back to the child). The subclassed scrollbar then recieves a WM_CONTEXTMENU. All messages in the Subclassed WndProc are passed to the SCROLLBAR class's WndProc via CallWindowProc().
The default scrollbar sends a WM_CONTEXTMENU ( I don't know to where ). The parent recieves a WM_ENTERIDLE. The scrollbar and parent then recieve no further messages until the menu has been destroyed. All messages are handled internally by the SCROLLBAR class's WndProc.
|
|
|
|
|
WalderMort wrote: The parent recieves a WM_CONTEXTMENU then sends a WM_CONTEXTMENU (I guess back to the child).
That doesn't make sense  It's supposed to be a notification not a command. It should only
go up the window heirarchy, not back down. Nobody should be sending it except DefWindowProc
If you put something like this at the parent and the scroll bar:
if (Msg == WM_CONTEXTMENU)
{
TRACE( "WM_CONTEXTMENU received at scrollbar \n" );
}
then what is/would be the order of trace messages?
|
|
|
|
|
It doesn't make any sense what so ever. Here is the output from Spy++ for both the Subclassed and NON-subclassed controls, and the parent at the time of the Right button click.
The Subclassed scrollbar:
00110900 P WM_RBUTTONDOWN fwKeys:MK_RBUTTON xPos:3 yPos:176
00110900 S WM_NCHITTEST xPos:320 yPos:335
00110900 R WM_NCHITTEST nHittest:HTCLIENT
00110900 S WM_SETCURSOR hwnd:00110900 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
00110900 R WM_SETCURSOR fHaltProcessing:False
00110900 P WM_MOUSEMOVE fwKeys:MK_RBUTTON xPos:3 yPos:176
00110900 S WM_NCHITTEST xPos:320 yPos:335
00110900 R WM_NCHITTEST nHittest:HTCLIENT
00110900 S WM_SETCURSOR hwnd:00110900 nHittest:HTCLIENT wMouseMsg:WM_RBUTTONUP
00110900 R WM_SETCURSOR fHaltProcessing:False
00110900 P WM_RBUTTONUP fwKeys:0000 xPos:3 yPos:176
00110900 S WM_CONTEXTMENU hwnd:00110900 xPos:320 yPos:335
00110900 R WM_CONTEXTMENU
And the parent:
001B0914 S WM_PARENTNOTIFY fwEvent:WM_RBUTTONDOWN xPos:187 yPos:276
001B0914 R WM_PARENTNOTIFY
001B0914 S WM_MOUSEACTIVATE hwndTopLevel:001E084E nHittest:HTCLIENT uMsg:WM_RBUTTONDOWN
001B0914 R WM_MOUSEACTIVATE fuActivate:MA_ACTIVATE
001B0914 S WM_SETCURSOR hwnd:00110900 nHittest:HTCLIENT wMouseMsg:WM_RBUTTONDOWN
001B0914 R WM_SETCURSOR fHaltProcessing:False
001B0914 S WM_SETCURSOR hwnd:00110900 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
001B0914 R WM_SETCURSOR fHaltProcessing:False
001B0914 S WM_SETCURSOR hwnd:00110900 nHittest:HTCLIENT wMouseMsg:WM_RBUTTONUP
001B0914 R WM_SETCURSOR fHaltProcessing:False
001B0914 S WM_CONTEXTMENU hwnd:00110900 xPos:321 yPos:424
001B0914 R WM_CONTEXTMENU
001B0914 S WM_SETCURSOR hwnd:00110900 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
001B0914 R WM_SETCURSOR fHaltProcessing:False
The Non-subclassed scrollbar:
00130906 P WM_RBUTTONDOWN fwKeys:MK_RBUTTON xPos:8 yPos:254
00130906 S WM_NCHITTEST xPos:242 yPos:502
00130906 S WM_SETCURSOR hwnd:00130906 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
00130906 P WM_MOUSEMOVE fwKeys:MK_RBUTTON xPos:8 yPos:254
00130906 S WM_NCHITTEST xPos:242 yPos:502
00130906 S WM_SETCURSOR hwnd:00130906 nHittest:HTCLIENT wMouseMsg:WM_RBUTTONUP
00130906 P WM_RBUTTONUP fwKeys:0000 xPos:8 yPos:254
00130906 S WM_CONTEXTMENU hwnd:00130906 xPos:242 yPos:502
And the parent:
001B0914 S WM_PARENTNOTIFY fwEvent:WM_RBUTTONDOWN xPos:107 yPos:212
001B0914 R WM_PARENTNOTIFY
001B0914 S WM_MOUSEACTIVATE hwndTopLevel:001E084E nHittest:HTCLIENT uMsg:WM_RBUTTONDOWN
001B0914 R WM_MOUSEACTIVATE fuActivate:MA_ACTIVATE
001B0914 S WM_SETCURSOR hwnd:00130906 nHittest:HTCLIENT wMouseMsg:WM_RBUTTONDOWN
001B0914 R WM_SETCURSOR fHaltProcessing:False
001B0914 S WM_SETCURSOR hwnd:00130906 nHittest:HTCLIENT wMouseMsg:WM_MOUSEMOVE
001B0914 R WM_SETCURSOR fHaltProcessing:False
001B0914 S WM_SETCURSOR hwnd:00130906 nHittest:HTCLIENT wMouseMsg:WM_RBUTTONUP
001B0914 R WM_SETCURSOR fHaltProcessing:False
001B0914 S WM_SETCURSOR hwnd:001B0914 nHittest:HTCAPTION wMouseMsg:0000
001B0914 R WM_SETCURSOR fHaltProcessing:False
001B0914 P WM_MOUSEMOVE fwKeys:0000 xPos:241 yPos:360
001B0914 S WM_ENTERIDLE fuSource:MSGF_MENU hwnd:00090854
001B0914 R WM_ENTERIDLE
|
|
|
|
|
I doesn't look like I am going to be able to solve this in a hurry, it's already 4:30am  Do you know of any way to get ahold of the default context menu for scroll bars? I will have to resort to displaying the darned thing myself.
|
|
|
|
|
I still didn't get this figured out. I have ever tried using the return value from SetWindowLong() in a direct function call ( even though MSDN says not to ). I get exactly the same behaviour.
I think if nobody on here knows the answer then I am going to have to ask Microsoft directly ( like that will ever have a response! ).
|
|
|
|
|
I keep looking at those Spy++ traces ... WTF?
|
|
|
|
|
the Dark lord himself 
I don't believe in failure. It is not failure if you enjoyed the process.
|
|
|
|
|
Hi all, I'm looking for ways to make my program can do self-upgrade. I just have no idea how to override the main program with the new version if it is still running.
Lisoft
|
|
|
|
|
If you want to upgrade it while it is running i think the only way is to put all code that might need updates inta a dynamic library. Your programm then simply needs to reload the library and you're done. But this will still require some kind of interruption in the regular flow. This is just a general idea, i hope it applies to your problem. (can i say that - "it applies to your problem" ? or is it bad english ?)
|
|
|
|
|
Updating an EXE while it's running won't work so here's how I do it basically (just one
possible way)...
1) During initialization check if upgrade available
2) If upgrade available start upgrader application and exit.
3) Upgrader app copies/overwrites new files
4) Upgrader app starts the original app and exits
|
|
|
|
|
See this [^]article and see if it meets your needs
|
|
|
|
|
Thanks so much, I think this is exactly what I want.
Lisoft
|
|
|
|
|
I am working with the Explorer kind of MFC Application.
Here I face a problem of when I call a Context Menu from TreeView and when I Handle this menu event from Mouse Click.
- Context Menu is working fine.
- I want to handle the menu control from MOUSE RIGHT CLICK MESSAGE.
- Control ID is also captured correctly when Mouse is clicked (As per expected).
- But When program calls a dialog from this point. The dialog has not a focus on it Even I try so hard Focus on dialog controls are not coming.
- If I swith from this application and coming back to this application again it is working fine. (Change of Focus from one application to another).
How can I resolve this problem?
|
|
|
|
|
Can you post the code calling the dialog ?
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
|
|
|
|
|
I had this function in a class i defined :
void AddJob(IRunnable &NewJob);
Now there is a Windows API that is also called AddJob, but with completely different parameters and return type. The class was defined inside a static library. When i wanted to call that function in an application that linked my library :
TestInstance.AddJob(IRunnableImplInstance);
i got a linker error "Unresolved external". I renamed my functio now, and all works well. But i wonder why the error occured in the first place. The function had completely different parameters, return types and class context (the API is in the global namespace). I use VC++ 6. Does anyone have an explanation for that ?
|
|
|
|
|
I believe that C functions, even when compiled by a C++ compiler only differ by name and not by return type, name and parameter list for C++ member functions. Would this be the culprit?
Chris Meech
I am Canadian. [heard in a local bar]
Nobody likes jerks. [espeir]
Hey, I am part of a special bread, we are called smart people [Captain See Sharp]
The zen of the soapbox is hard to attain...[Jörgen Sigvardsson]
I wish I could remember what it was like to only have a short term memory.[David Kentley]
|
|
|
|
|
I don't know for shure. But i think unsell you declare a function __stdcall explicitly, it will always be translated into that long C++ symbol lingo. However, why would that result in an unresolved external linker error ? If anything it's a redefinition of a symbol, but not no definition of that symbol.
|
|
|
|
|
You're correct. I've got it backwards. My explanation would result from a redefinition error. Not what you are after. Sorry about that. 
Chris Meech
I am Canadian. [heard in a local bar]
Nobody likes jerks. [espeir]
Hey, I am part of a special bread, we are called smart people [Captain See Sharp]
The zen of the soapbox is hard to attain...[Jörgen Sigvardsson]
I wish I could remember what it was like to only have a short term memory.[David Kentley]
|
|
|
|
|
This one is going to make you laugh  and cry  ...
In the Microsoft headers, there are TWO definitions for almost every function - the ANSI version and the UNICODE version. The AddJob in the Microsoft headers is redefined as either AddJobA or AddJobW. The precompiler will see any similar text and change the name.
Now, in your static library, you must NOT have included anything close to the printer header, so the AddJob stayed as 'AddJob', but in your project, when you went to use it, and maybe you directly or indirectly included the files which redefined AddJob, so it did not find AddJobA or AddJobW in your library at link time - your project's main OBJ module was looking for the wrong name.
I had been tripped up by this one time a while back as well. You have to be careful naming anything requiring linkage the same as any one of the bazillion WIN32 functions out there!
This would also explain why once you changed the name your 'problem' went away.
Any sufficiently gross incompetence is nearly indistinguishable from malice.
|
|
|
|
|
Well, it made me laugh more than cry. I knew that most of the functions are mapped to the A and W version via macros, but i didn't make the connection. Well, you just gotta take it with humor ...
|
|
|
|
|
A good candidate for the subtle bug forum...
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
