Link to home
Start Free TrialLog in
Avatar of jdaly
jdaly

asked on

Sending ^Home to an edit box (same process) ?

I have the need to simulate keystrokes to an edit box within the same
process, but am having a tough time sending CTRL+HOME and CTRL+END
combinations.  I'm doing OK with sending HOME and END, etc, but How do I
simulate the CTRL-DOWN.

I've tried :

m_pEdit->SendMessage(WM_KEYDOWN, VK_CONTROL , 0L);
m_pEdit->SendMessage(WM_KEYDOWN, VK_END , 0L);
m_pEdit->SendMessage(WM_KEYUP, VK_END , 0L);
m_pEdit->SendMessage(WM_SYSKEYUP, VK_CONTROL , 0L);

but it's only doing a "VK_END"

Any thoughts?

Jim.
Avatar of nietod
nietod

Thoughts yes, answers.....

Have you tried posting the messages rather than sending them?
You could also also try fooling with the GetKeyboardState and SetKeyboardState() procedures in order to simulate the control key being down when the home or end message is received.
Avatar of Dr. Kamal Mehdi
In Visual Basic, this can be done very easily using the SendKeys statement. I don't know if there is a corresponding statement in C.
Nope.  VB was written for the windows OS, but C and C++ are platform independant.  They have to use windows API calls for this stuff.
I think you really want to do this Jim:

CTRL + HOME:
{
    m_pEdit->SendMessage(EM_SETSEL, 0, 0);
    m_pEdit->SendMessage(EM_SCROLLCARET, 0, 0);
}

CTRL + END
{
    INT nsize = SendMessage(WM_GETTEXTLENGTH , 0, 0);
    SendMessage(EM_SETSEL, nsize, nsize);
    SendMessage(EM_SCROLLCARET, 0, 0);
}

Your users will not be able to tell the difference between this
and a "simulated" keystroke :-)

Good Luck
Avatar of jdaly

ASKER

Although that solution will manipulate the edit box and the cursor positioning within the edit box, my problem is specific to being able to send the CTRL+keystokes, not moving the cursor.  (The actual application needs this functionality).  The edit box cursor positioning is secondary.  Good effor! Perhaps my question needed to be clearer in my prupose.


Have you tried either of my suggestions?
I may give it a try...

If you can tell me the difference between sending CTRL + HOME
and the code above.

Although I am not 100% sure, I would not be suprised if the
actual edit-control code looks a lot like my code.
altena, I think you are missing the point.  Jdaly needs to be able to send control keys to other windows (not necessarily edit windows.)  He is using an edit window for the test because it responds to the control home and end keys.
ASKER CERTIFIED SOLUTION
Avatar of alexo
alexo
Flag of Antarctica image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Alex, do you know for a fact that it has to be posted rather than sent?  The wrong parameters by themselves might be enough to prevent it from working.
Nope, I'm just oferring alternatives.  Sending might work but the app in question may have installed a filter or something.  Documentation says that the WM_KEYDOWN message is posted so why not be on the safe side?  Anyway, you were the first one to suggest posting, weren't you?  I'm just backing you up :-)
I know I suggested it.  I thought it might matter.  I was just wondiring if it meant you KNEW it mattered.  
I'm betting on the wrong arguments.
I remember that windows treats keyboard messages in a special way so posting MIGHT make a difference.  I'll wait for input from jdaly.
Avatar of jdaly

ASKER

I already used Spy++ to determine the wParam and lParam to send, my source snippet had used the "correct values", and I've tried both Posting and Sending the messages.

I intend to try alexo's answer to see if in my numerous coding attempts may have "just missed".

Has any one of you gotten this to work?
PostMessage(hwnd, WM_KEYDOWN, VK_CONTROL, MAKELPARAM(1, 0x1D));
PostMessage(hwnd, WM_KEYDOWN, VK_HOME, MAKELPARAM(1, 0x47 | KF_EXTENDED));
PostMessage(hwnd, WM_KEYUP, VK_HOME, MAKELPARAM(1, 0x47 | KF_EXTENDED | KF_REPEAT | KF_UP));
PostMessage(hwnd, WM_KEYUP, VK_CONTROL, MAKELPARAM(1, 0x1D | KF_REPEAT | KF_UP));

Unfortunately, it didn't work :-)  The CONTROL had no effect...

What worked for me is:

    SetForegroundWindow(hwnd);
    keybd_event(VK_CONTROL, 0x1D, 0, 0);
    keybd_event(VK_HOME, 0x47, 0, 0);
    keybd_event(VK_HOME, 0x47, KEYEVENTF_KEYUP, 0);
    keybd_event(VK_CONTROL, 0x1D, KEYEVENTF_KEYUP, 0);

More bad news: SetKeyboardState() also doesn't help.

I'm affraid you'd have to use a journalling hook.  See documentation of SetWindowsHookEx() for details.  More info on http://www.dejanews.com/getdoc.xp?AN=275984203

keybd_event was what I had been looking for.  It puts the information in the single-system event queue rather than the applications's queue.  
SetSel(0,0,FALSE) should do what you want (move the cursor to the start of the edit box).

Roger, see comment from "Saturday, May 09 1998 - 04:55AM PDT"
Must've missed reading that one in the thread .. carry on !!
keybd_event() has the downside that the keystroke is redirected to the foreground window, therefore one must bring the desired window to the foreround.
However, it seems to be the only solution.  I remember reading somewhere (lost the reference) that the editbox checks the CONTROL key state when receiving the WM_KEYDOWN message instead of remembering the previously recieved VK_CONTROL.  Tough luck :-(
But how does it check the control key state?  I would guess it uses GetKeyState(), which I would guess just uses GetKeyboardState().  That is why I was wondering if the SetKeyboardState() function could be used to "convince" it that the control key is down.

I guess that is two guesses in there and this is the third, but it is worth a try.
As I said, I tried SetKeyboardState() with no luck.
I didn't remember that.  I wonder how the edit box tests if the control key is down?
No clue.  If you manage to divine that info, please share it with us.
Avatar of jdaly

ASKER

I've developed a new wrinkle to this problem.  If a simple SetSel is used to go to the top or bottom of the text, the statements execute (i step through them), but the cursor (in my "big" app) does not get repositioned.  However, in a "simple" test app, the cursor does move.  Any ideas?
Works for me:

    #define STRICT
    #define WIN32_LEAN_AND_MEAN
    #pragma warning(disable: 4201 4214 4514)
    #include <windows.h>

    void main()
    {
        HWND hwnd;
        hwnd = GetWindow(FindWindow("Notepad", "test.txt - Notepad"), GW_CHILD);
        SendMessage(hwnd, EM_SETSEL, 0, 0);
    }

Check the messages the edit box is getting with SPY.
I you use SetSel, then altena should get the points for his/her earlier answer tht was rejected.

Avatar of jdaly

ASKER

For lack of the "perfect solution"...!  Thank you, alexo, for your input!!!!

RE:
What worked for me is:

    SetForegroundWindow(hwnd);
    keybd_event(VK_CONTROL, 0x1D, 0, 0);
    keybd_event(VK_HOME, 0x47, 0, 0);
    keybd_event(VK_HOME, 0x47, KEYEVENTF_KEYUP, 0);
    keybd_event(VK_CONTROL, 0x1D, KEYEVENTF_KEYUP, 0);

Have Fun!