Commands in edit box

[McCain]

Hi,
I'm making a program with an edit box. It's kind of like notepad, but it will not have any menus or buttons, you will control the program by entering commands in the edit box. If I want to save the text that's in the edit box I would go /s C:\file.txt <enter>
To do this I have subclassed the edit box. As soon as the user types a slash (/) I set bSlash = true and when I press enter i set bSlash = false again. While bSlash is equal true I copy every character that I type to a string, but somewhere along the path things messes up...

LRESULT CALLBACK EditProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
	switch(uMsg)
	{
		case WM_KEYUP:
		{
			int iLen;
			iLen = GetWindowTextLength(hwndEdit);
			char *szText;
			szText = new char[iLen + 1];
			GetWindowText(hwndEdit, szText, iLen + 1);

			if(wParam == VK_RETURN)
			{
				bShift = false;
				ParseCommand();
			}

			if(bShift == true && wParam >= 32)
			{
				sCommand += szText[iLen - 1];
			}
			
			if(szText[iLen - 1] == '/')
			{
				bShift = true;
			}

			delete [] szText;
			break;
		}
	
		default:
		{
			break;
		}		
	}

	return CallWindowProc(wndProcOld, hWnd, uMsg, wParam, lParam);
}

void ParseCommand()
{
	MessageBox(NULL, sCommand.c_str(), "sCommand", MB_OK);
	sCommand = "";
} 


Input in the edit box: abc /s "This is a test"
Output in the MessageBox: s "Tiis s    eett"

The number of characters are right but not the caracters them selves... What is wrong?

[CornedBee]

I don't see the error, might be something to do with too fast typing, but I wonder: are you actually allocating and deallocating a buffer on every keypress?

[McCain]

Originally posted by CornedBee
are you actually allocating and deallocating a buffer on every keypress?

Yeah... I just threw it in there and as it worked I didn't change it...
Guess I should move the char *szText and delete lines...

[McCain]

CB, Seems you were right (as always). If I type slow, it works, but if I type fast, it doesn't work.
Now my questions are "Why does this happen?" and "What can I do about it?"

[CornedBee]

Why does it happen?

Edit boxes react to WM_CHAR to add characters. A WM_CHAR is usually created by TranslateMessage from a WM_KEYDOWN and, I believe, delivered to the wndproc via SendMessage. The WM_KEYUP you catch, however, is posted to the message queue. If you type fast, this means that before you process the WM_KEYUP of the last key, the WM_CHAR for the next key is already sent and the character added to the edit box' buffer. This is what you then retrieve as the last char, resulting in this weird character multiplication.
At least that's my explanation.

What can you do about it?

Speeding up the WM_KEYUP handling might help, but I'm not sure.
More importantly, don't rely on the edit box' buffer for getting the newest character. Use wParam directly. Once you do that, you can rid yourself of the temp buffer completly.
Even so, it is terribly inefficient. You allocate a buffer on every keyup, but you only use it if bShift is true AND the character vkey is > 32!

[McCain]

Using wParam in the WM_KEYUP event was my first thought as well, but I couldn't find a way to detect the / key. So I added szText to check for the /. When I got that working I moved on to getting the acutal command, and then it just felt natural to use the szText string as I needed it anyways to check for slashes.

But if you know how to detect the slashkey using wParam I will use that instead...

[CornedBee]

You're right, this is tricky. The slash on my German keyboard is Shift-7, so wParam would have to be 37 and GetKeyState with VK_SHIFT should give you a true.

Tricky - maybe you should intercept WM_CHAR instead? Just make sure you pass it on.

[McCain]

It's Shift-7 on my Swedish keyboard as well, but on American keyboards it's right next to the right shiftkey... So I can not trust the Shift-7 combo...
Will try the WM_CHAR message as soon as I get home

[McCain]

I've got an old ms-dos book from 93. In the back there's pictures of keyboard layouts from 20 different countries, it appears that the shift-7 combo is the most common one, but there are others, like shift-6 in Hungary for example. Maybe I should just look for different key-combos depending on the keyboard layout? What do you think?

[CornedBee]

That's a very bad idea IMO. Not only because you first have to determine the keyboard layout.

[McCain]

So how should I go about it do you think? Are there any other ways than to check the buffer or wParam?

[CornedBee]

Why not catch WM_CHAR? Let Windows worry about the conversion.

[McCain]

How do I check for the slash key in WM_CHAR then? I tried if wParam == '/' but that didn't work I also tried == 'a' But that didn't work either so I don't think that is how you are supposed to do it... I also tried if wParam == 97 but that didn't work either.
So how do I use it?

[CornedBee]

WM_CHAR says something about UTF-16, so you can try comparing wParam to L'/'. Shouldn't make a difference though. Are you sure the message arrives in the first place?

I found the function you can use to convert VKEYs to ASCII, it's called ToAscii.

[McCain]

I saw that about UTF-16 too, but didn't know what it meant...

I looked at the wParam on WM_KEYUP, and it looks like it doesn't care about the shift key, the keycodes are all for uppercase letters if I'm not mistaken. So i don't know if ToAscii will work or not, but I will try.
Thanks for the tip, I'll try it tonight

[CornedBee]

ToAscii takes the complete keyboard state as retrieved from GetKeyboardState as third parameter.

[McCain]

ToAscii works! Thank you.

[McCain]

Actually, "if (wParam == '/')" in WM_CHAR works as well, I was trying the release version but compiling the debug one... That's why I thought it wasn't working... So that is what I'm using now, should be faster than having to call ToAscii and GetKeyboardState every WM_KEYUP.