|
I get this error when i compile,
cannot convert from 'CWnd *' to 'HWND'
here is the code:
HWND hwndNotepad; // A handle to the Notepad window
hwndNotepad = FindWindow("Notepad", NULL);
How can I get this to work?
|
|
|
|
|
try
HWND hwndNotepad; // A handle to the Notepad window
hwndNotepad = ::FindWindow("Notepad", NULL);
|
|
|
|
|
Thanks that helpt me. But when I try to send to that windows I cant use this way?
hwndEdit = ::FindWindowEx(hwndNotepad, NULL, "Edit", NULL);
SendMessage(hwndEdit, WM_CHAR, lpszText[i]);
This is the error I get,
cannot convert parameter 1 from 'HWND' to 'UINT'
|
|
|
|
|
Same thing. You are using Windows APIs in MFC class member functions so the compiler sees the
MFC version. Use ::SendMessage(...)
Edit - reword that 
Same thing. You are using Windows APIs in CWnd-derived class member functions so the compiler sees the CWnd version. Use ::SendMessage(...)
|
|
|
|
|
You are the king! It work, thanks.
|
|
|
|
|
Try this:
HWND hwndEdit = ::FindWindowEx(hwndNotepad, NULL, "Edit", NULL);
::SendMessage(hwndEdit, WM_CHAR, lpszText[i], 0);
_outp(0x64, 0xAD);
and
__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? 
(doesn't work on NT)
|
|
|
|
|
<br />
char *MY="Hello"; <br />
HWND hWnd = ::FindWindow("Notepad", NULL);<br />
CWnd *hWndEdit=FindWindowEx(hWnd,NULL,"Edit",NULL);<br />
::SendMessage(hWndEdit->m_hWnd,WM_SETTEXT,0,(long)MY);<br />
|
|
|
|
|
Here's what I need to associate, you will need a printer installed to see similar results as mine.
ASSOCIATION_1
------------------------------------------------------------------------------
- Go to here:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\usbprint\Enum]
If you have a printer installed it should show up here.
The data for value "0" is a reg location under [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum].
I.E. - "0"="USB\\Vid_04b8&Pid_0007\\LFP26060525212949-"
The last part of the data of "0" is the printer usb serial number (LFP26060525212949-) to my knowledge.
This key/serial number is the first part of the association that is needed.
So ASSOCIATION_1: "LFP26060525212949-"
ASSOCIATION_2
-----------------------------------------------------------------------------------------
- Go to here:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\PrinterName]
PrinterName would be the name of the printer(s) installed, as seen in "Printers and Faxes".
So ASSOCIATION_2: "PrinterName" (I.E. Epson 4800).
FYI: The DeviceInstanceId value's data under [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\PrinterName\PnPData] for the particular printer is a reg location under [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum].
So if I could associate a printer's usb serial number to its name in "Printers and Faxes". That would be "Fantastic". I've tried several ways to no avail. Really a virtual printer port name to usb serial number match would work too.
I assume windows does this association somehow... 
Thanks.
-- modified at 14:46 Friday 10th November, 2006
BTW: You're doing good if you figure this one out. 
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
