C / C++ / MFC

10-Nov-06 5:25

I have subclassed a scrollbar in order to apply a skin, but I have now lost the ability to display the context menu. The only thing my callback does is to return CallWindowProc(). I have commented out all my message handlers trying to narrow the problem down. Using Spy++ I compared my subclassed control to a standard control, the messages are identical except for the WM_CONTEXTMENU. A standard control sends the message after processing the WM_RBUTTONUP message, my control does the same except that it recieves the WM_CONTEXTMENU message directly after sending it.

Could anybody point out what I might be doing wrong?

Mark Salsbery10-Nov-06 5:45

10-Nov-06 5:45

WalderMort wrote:
my control does the same except that it recieves the WM_CONTEXTMENU message directly after sending it

After sending what? Smile | :)

Waldermort10-Nov-06 5:59

10-Nov-06 5:59

The scrollbar sends a WM_CONTEXTMENU message after processing the WM_LBUTTONUP message. I guess this message is sent to the parent window. A default scrollbar will only send this message, but mine both sends and recieves it. So I guess it is sending the message to itself rather than the parent. But I can't understand why.

I should also mention that I have tried forwarding the message to the parent, but the menu is still not being displayed.

Mark Salsbery10-Nov-06 6:22

10-Nov-06 6:22

heh

I'm confused as usual. WM_CONTEXTMENU should go to the control under the cursor and
if the control calls DefWindowProc() then it goes to the parent right?

Waldermort10-Nov-06 6:42

10-Nov-06 6:42

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++?

Mark Salsbery10-Nov-06 7:18

10-Nov-06 7:18

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.

Waldermort10-Nov-06 7:35

10-Nov-06 7:35

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++ Wink | ;)

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.

Mark Salsbery10-Nov-06 8:20

10-Nov-06 8:20

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. (???)

Waldermort10-Nov-06 8:26

10-Nov-06 8:26

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.

Mark Salsbery10-Nov-06 9:01

10-Nov-06 9:01

WalderMort wrote:
The parent recieves a WM_CONTEXTMENU then sends a WM_CONTEXTMENU (I guess back to the child).

That doesn't make sense Smile | :)

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?

Waldermort10-Nov-06 9:15

10-Nov-06 9:15

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

Waldermort10-Nov-06 9:22

10-Nov-06 9:22

I doesn't look like I am going to be able to solve this in a hurry, it's already 4:30am Sleepy | :zzz:

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.

Waldermort11-Nov-06 6:50

11-Nov-06 6:50

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! ).

Mark Salsbery11-Nov-06 7:03

11-Nov-06 7:03

I keep looking at those Spy++ traces ... WTF?

OMG

Monty²10-Nov-06 18:42

Monty²

10-Nov-06 18:42

the Dark lord himself OMG | :OMG:

I don't believe in failure. It is not failure if you enjoyed the process.

Program self upgrade

lisoft10-Nov-06 4:04

lisoft

10-Nov-06 4:04

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. Confused | :confused:

Lisoft

Mr.Brainley10-Nov-06 4:29

Mr.Brainley

10-Nov-06 4:29

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 ?)

Mark Salsbery10-Nov-06 5:31

10-Nov-06 5:31

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

Wes Aday10-Nov-06 10:39

Wes Aday

10-Nov-06 10:39

See this [^]article and see if it meets your needs