Setting the text in an edit box of another application
-
I am trying to interact programmatically with another application, and have succeeded in finding the handle of the correct edit box in the application's dialog. However, I can't seem to find a way to send text to the dialog control. The MSDN documetation for ::SetWindowText() states that it cannot be used to modify the text in another application. What other means is there to achieve the text transfer ? Doug
I have now managed to copy the text to the clipboard, and then send a WM_PASTE message to the other application. This works, but is it the only way to achieve this transfer ? Doug
-
I have now managed to copy the text to the clipboard, and then send a WM_PASTE message to the other application. This works, but is it the only way to achieve this transfer ? Doug
-
Personally, I'd use WM_SETTEXT[^]. It's what SetWindowText uses internally.
WM_SETTEXT is used to set the text of a window.
Working is a happy thing! Enjoy the free partition manager!
-
WM_SETTEXT is used to set the text of a window.
Working is a happy thing! Enjoy the free partition manager!
Which is precisely why I'd use it. Recall that an edit control may be created thusly:
hwndEdit = CreateWindowEx(0, WC_EDIT, 0, WS_VISIBLE | WS_CHILD | WS_TABSTOP | WS_BORDER | ES_AUTOHSCROLL, 11, 11, 147, 23, hwnd, (HMENU)IDC_EDIT1, hInst, 0);
Where
- hwndEdit is derclared of type HWND
- hwnd holds the parents HWND
- hInst holds HINSTANCE of the program
- IDC_EDIT has been defined as an integer used to identify messages from this control
-
Personally, I'd use WM_SETTEXT[^]. It's what SetWindowText uses internally.
Yes, I originally made an error in using SendMessage in the way that I set up lParam !!! I've got it working now ! (Much neater than using the clipboard !) So, if ::SetWindowText() ultimately uses WM_SETTEXT, then it begs the question as to why MS doe not allow it to act on "other applications" windows ?? Doug
-
Yes, I originally made an error in using SendMessage in the way that I set up lParam !!! I've got it working now ! (Much neater than using the clipboard !) So, if ::SetWindowText() ultimately uses WM_SETTEXT, then it begs the question as to why MS doe not allow it to act on "other applications" windows ?? Doug
Probably because SETTEXT needs a pointer to the text, and that pointer must be valid in the destination app's address space. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
Probably because SETTEXT needs a pointer to the text, and that pointer must be valid in the destination app's address space. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
<< Probably because SETTEXT needs a pointer to the text, and that pointer must be valid in the destination app's address space. >> But if SetWindowText() ends up using SendMessage, the text is in lParam. I'm confused ......... !! Doug
-
<< Probably because SETTEXT needs a pointer to the text, and that pointer must be valid in the destination app's address space. >> But if SetWindowText() ends up using SendMessage, the text is in lParam. I'm confused ......... !! Doug
you're welcome. FYI: there are Win32 system calls that help you pass arbitrary amounts of data from one process to another; my LP#TrayIconBuster[^] article has an LP_Process class that shows how it's done in C#; similar techniques could be used in C/C++. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
<< Probably because SETTEXT needs a pointer to the text, and that pointer must be valid in the destination app's address space. >> But if SetWindowText() ends up using SendMessage, the text is in lParam. I'm confused ......... !! Doug
lParam holds the pointer to the text, and is assumed to be a valid pointer within the process' address space. It can not be an address in some other process. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
lParam holds the pointer to the text, and is assumed to be a valid pointer within the process' address space. It can not be an address in some other process. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
>>Param holds the pointer to the text, and is assumed to be a valid pointer within the process' address space. It can not be an address in some other process.<< Thanks for your patience, Luc !! So that I can just FULLY understand this, let me describe it back to you with a few extra words (!!):- The issuer of SendMessage() holds the variable containing the text (my app, in this case), and lParam is set up containing an address to this variable (within the senders address space ?). The receiver of SendMessage()(the 3rd party app, with which i'm endeavouring to interact) has access to lParam which contains the address of the original text, but as I'm alluding to above, is this address within the sender's address space ? I suspect that somewhere within the process, the text is COPIED to some global address space and it is THIS address that is contained within lParam. I can't see how else the process can work whilst protecting each app's memory space. I await your words of wisdom, and to be "sorted out" !! Again, thanks for your patience ! Doug
