Printable View
hello,
the story;
I have two dialogs (they belong to diff. processes)
Dialog -A- has the focus (Dialog -B- is also on the screen),
when I press a (control)-button in dialog -A- a text string has to be send
to the edit control of Dialog -B-, using the keyboard event.
but has Dialog -B- does not has the focus, nothing happens.
Well, not what I want.
quest;
what can I do to make it work?
regards,
ger
::SendMessage (WM_USER_MSG, ...) from A to B.Quote:
Originally Posted by TBBW
Bring Dialog B to the foreground and use SendInput.
@ Alin, tell a little bit more on the SendMessage
@Arjay, I only control Dialog -A-
I can do a FindWindow and set the focus to it.
ger
...where WM_USER_MSG is a registered window message, isn't it? :)Quote:
Originally Posted by Alin
@To TBBW: Why do you want to send text from an edit control in a procss to an edit control in another process by using "using the keyboard event" ?.
There are many other better methods.
The easier one is sending WM_SETTEXT message.
Oups! :sick:
Here is the story: http://msdn.microsoft.com/en-us/libr...50(VS.85).aspx :)Quote:
Originally Posted by TBBW
I'm not transferring text from an edit control to an edit control.
pushing a control button will send a static text string to the edit control of the other dialog.
that is why i'm using the keyboard event, to simulate user input.
as i'm still learning I do not know all options, I will have a go using the mention options.
ger
Using SendInput is the way to go.
Please, excuse my ignorance!Quote:
Originally Posted by TBBW
Why doing that via sending WM_SETTEXT is not possible?
Call SetForegroundWindow before SendInput.
See DiLascia's C++ Q&A from January 2005: "Sending Keystrokes to Any App" at http://msdn.microsoft.com/msdnmag/is...A/default.aspx
Mike
Thank you guys for all the much appriciated input !!
the SetForegroundWindow() did the trick.
tested both SendInput() and Keyboard_event()
I could not observe any major diff. between them
apart from the lines of codes needed.
the only thing I observed, using the SendInput. Also the next, back buttons of the receiving
dialog (Dialog -B-) are 'touched'. (this is the case if the control button sending the text is hit more
than once.
using the keyboard event did not created this problem.
ger
This unwanted behavior is an artifact of how you are using SendInput.
Without seeing your code we can only speculate on what you are doing wrong.
Why not just get the pointer of first dialog in second dialog?
A constructor of second dialog can take pointer of first dialog, and directly set the control's text.
Yes, the appropriate control variable should be accessible to second dialog-class.
Oops. My bad! They are in different processes!
You can use WM_SENDDATA to silently send the data to second dialog (application). The application would understand it, and would display the content.
Please note that with Windows Vista and higher, UIPI and integrity may prevent sending messages from lower integrity process to higher integrity process!
I would use named-pipes in this case. ;)
@Ajay - pretty sure the OP can't modify the source to Dialog B.