|
Yeah, I've had a similar problem. I need to come up with a way to associate a USB port to a specific printer when multiple printers of the exact same type are plugged into the same machine. I've tried going through the registry, but after searching and diving through it many times I couldn't find any correlation. Is this even possible? It appears that WinBlows can do it, but are they using some sort of super secret magic or a printer fairy to get this done?
I win because I have the most fun in life...
|
|
|
|
|
I didn't think I would get any help on this one... 
|
|
|
|
|
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?
|
|
|
|
|
WalderMort wrote: my control does the same except that it recieves the WM_CONTEXTMENU message directly after sending it
After sending what? 
|
|
|
|
|
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.
|
|
|
|
|
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?
|
|
|
|
|
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 ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
