Solved

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

Posted on 1998-05-08
31
330 Views
Last Modified: 2013-12-03
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.
0
Comment
Question by:jdaly
  • 11
  • 10
  • 4
  • +3
31 Comments
 
LVL 22

Expert Comment

by:nietod
ID: 1400106
Thoughts yes, answers.....

Have you tried posting the messages rather than sending them?
0
 
LVL 22

Expert Comment

by:nietod
ID: 1400107
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.
0
 
LVL 7

Expert Comment

by:kamall
ID: 1400108
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.
0
 
LVL 22

Expert Comment

by:nietod
ID: 1400109
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.
0
 
LVL 3

Expert Comment

by:altena
ID: 1400110
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
0
 

Author Comment

by:jdaly
ID: 1400111
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.


0
 
LVL 22

Expert Comment

by:nietod
ID: 1400112
Have you tried either of my suggestions?
0
 
LVL 3

Expert Comment

by:altena
ID: 1400113
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.
0
 
LVL 22

Expert Comment

by:nietod
ID: 1400114
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.
0
 
LVL 11

Accepted Solution

by:
alexo earned 100 total points
ID: 1400115
First, post the messages instead of sending.  Second, Wrong parameters.

Spy++ says:

WM_KEYDOWN nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:0 fUp:0
WM_KEYDOWN nVirtKey:VK_HOME cRepeat:1 ScanCode:47 fExtended:1 fAltDown:0 fRepeat:0 fUp:0
WM_KEYUP nVirtKey:VK_HOME cRepeat:1 ScanCode:47 fExtended:1 fAltDown:0 fRepeat:1 fUp:1
WM_KEYUP nVirtKey:VK_CONTROL cRepeat:1 ScanCode:1D fExtended:0 fAltDown:0 fRepeat:1 fUp:1

You set lparam to 0.  I.e., the repeat count is zero (should be 1), the scan code is zero, etc.

The correct value if lparam is computed as follows:

Value of lParam. Specifies the repeat count, scan code, extended-key flag, context code, previous key-state flag, and transition-state flag, as shown in the following table:

Value      Description

0-15      Specifies the repeat count. The value is the number of times the keystroke is repeated as a result of the user holding down the key.

16-23      Specifies the scan code. The value depends on the original equipment manufacturer (OEM).

24      Specifies whether the key is an extended key, such as the right-hand ALT and CTRL keys that appear on an enhanced 101- or 102-key keyboard. The value is 1 if it is an extended key; otherwise, it is 0.

25-28      Reserved; do not use.

29      Specifies the context code. The value is always 0 for a WM_KEYDOWN message.

30      Specifies the previous key state. The value is 1 if the key is down before the message is sent, or it is 0 if the key is up.

31      Specifies the transition state. The value is always 0 for a WM_KEYDOWN message.


0
 
LVL 22

Expert Comment

by:nietod
ID: 1400116
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.
0
 
LVL 11

Expert Comment

by:alexo
ID: 1400117
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 :-)
0
 
LVL 22

Expert Comment

by:nietod
ID: 1400118
I know I suggested it.  I thought it might matter.  I was just wondiring if it meant you KNEW it mattered.  
0
 
LVL 11

Expert Comment

by:alexo
ID: 1400119
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.
0
 

Author Comment

by:jdaly
ID: 1400120
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?
0
Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

 
LVL 11

Expert Comment

by:alexo
ID: 1400121
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);

0
 
LVL 11

Expert Comment

by:alexo
ID: 1400122
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

0
 
LVL 22

Expert Comment

by:nietod
ID: 1400123
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.  
0
 
LVL 10

Expert Comment

by:RONSLOW
ID: 1400124
SetSel(0,0,FALSE) should do what you want (move the cursor to the start of the edit box).

0
 
LVL 11

Expert Comment

by:alexo
ID: 1400125
Roger, see comment from "Saturday, May 09 1998 - 04:55AM PDT"
0
 
LVL 10

Expert Comment

by:RONSLOW
ID: 1400126
Must've missed reading that one in the thread .. carry on !!
0
 
LVL 11

Expert Comment

by:alexo
ID: 1400127
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 :-(
0
 
LVL 22

Expert Comment

by:nietod
ID: 1400128
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.
0
 
LVL 11

Expert Comment

by:alexo
ID: 1400129
As I said, I tried SetKeyboardState() with no luck.
0
 
LVL 22

Expert Comment

by:nietod
ID: 1400130
I didn't remember that.  I wonder how the edit box tests if the control key is down?
0
 
LVL 11

Expert Comment

by:alexo
ID: 1400131
No clue.  If you manage to divine that info, please share it with us.
0
 

Author Comment

by:jdaly
ID: 1400132
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?
0
 
LVL 11

Expert Comment

by:alexo
ID: 1400133
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.
0
 
LVL 10

Expert Comment

by:RONSLOW
ID: 1400134
I you use SetSel, then altena should get the points for his/her earlier answer tht was rejected.

0
 

Author Comment

by:jdaly
ID: 1400135
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);

0
 
LVL 11

Expert Comment

by:alexo
ID: 1400136
Have Fun!
0

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
MSDN Subscription - Azure and NFP's 3 64
Dialogbox API leak? 18 81
What is MicroStrategy.NET? 2 58
Question to Pivot table 1 34
This article describes how to add a user-defined command button to the Windows 7 Explorer toolbar.  In the previous article (http://www.experts-exchange.com/A_2172.html), we saw how to put the Delete button back there where it belongs.  "Delete" is …
With most software applications trying to cater to multiple user needs nowadays, the focus is to make them as configurable as possible. For e.g., when creating Silverlight applications which will connect to WCF services, the service end point usuall…
This is Part 3 in a 3-part series on Experts Exchange to discuss error handling in VBA code written for Excel. Part 1 of this series discussed basic error handling code using VBA. http://www.experts-exchange.com/videos/1478/Excel-Error-Handlin…
Internet Business Fax to Email Made Easy - With  eFax Corporate (http://www.enterprise.efax.com), you'll receive a dedicated online fax number, which is used the same way as a typical analog fax number. You'll receive secure faxes in your email, f…

911 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

25 Experts available now in Live!

Get 1:1 Help Now