WM_CHAR help

Started by
4 comments, last by eal 18 years, 3 months ago
This just can't be as difficult as I seem to be making it. I am trying to use WM_CHAR to get user input from the keyboard. I just can't seem to figure out how to assign the user's input to a string variable that I can then use. My code: case 5: { //Settings Draw_Text_GDI("New Load File - ", 250, 290, RGB(255, 0, 0), lpddsprimary); while(loadstring==0) { PeekMessage(&msg,NULL,0,0,PM_REMOVE); { TranslateMessage(&msg); DispatchMessage(&msg); } } nextmove = 0; break; } As you can see this is part of a switch. Loadstring is a global to tell when the return is pressed. The code in the WinProc for WM_Char: case WM_CHAR: { char ascii_code = wparam; if(ascii_code==13) { loadstring = 1; return(0); break; } sprintf(buffer, "%s", ascii_code); Draw_Text_GDI(buffer, 20, 40, RGB(255, 255, 255), lpddsprimary); return(0); } break; The Draw_Text here is just a temp test to see that key presses were registering. I've tried assigning different char variables the WM_Char results so that I can use the input to change file names, etc. but I have not found something that would work or didn't blow the program up. I need something in C that will allow me to capture the input. Any suggestions would be appreciated. I can see the key presses taking place. I just haven't been able to save them. Thanks, Slider
Advertisement
Couldn't you just use an array to store the 'ascii_code' values?

int index=0;
char string[100];
...
string[index++]=ascii_code;
Hi eal. Thanks for the reply. I've tried that before, but gave it another shot. Set up char loader[80] as a global and int index within the WM_CHAR. My program just blows up. It now looks like this:
case WM_CHAR:
{
int index = 0;
char ascii_code = wparam;

if(ascii_code==13)
{
loadstring = 1;
return(0);
break;
}
loader[index++] = ascii_code;
sprintf(buffer, "%s", ascii_code);
Draw_Text_GDI(buffer, 20, 40, RGB(255, 255, 255), lpddsprimary);
return(0);
} break;

The screen goes black and each time I press a key I get this ugly little error sound. The code compiles ok, and the build works, but it just doesn't run. I've been fooling with this same problem for a couple of weeks or more and I'm about to throw in the towel. Someone has to have actually gotten this to work out there. Thanks for trying, Slider
It should work if you change the '%s' in sprintf to a '%c'. '%s' would be used if 'ascii_code' were a string, but since it's only a single character you have to specify '%c'.

Also, you probably want to make 'index' a global variable as well. Otherwise it will keep being reset back to 0 instead of incrementing each time. Hope that helps.
Hi eal. Sorry to say that that change didn't help. Program still blows up. I don't know why my screen goes black. I try typing a letter or two and I'm blown back to the compiler. I guess I don't know enough about how WM_CHAR really works. It seems to me that I have no choice but to try and trap these keystrokes from within the message handler itself. It seems you can't send any additional parameters to the message handler like a pointer to a string buffer or something, and as far as I know, a call to the message handler doesn't return anything to the calling program. But everytime I try and trap the ascci code nothing seems to go right. I tried making the index a global, but that didn't help. I had that %s in my code to see if I could print out everything that had been typed so far. My goal was to print the input as it was given. I thought that while the input is given one letter at a time, I could print out the total so far by printing the string created. Obviously that didn't work either. This is maddening. My WM_Char now looks like this:
case WM_CHAR:
{
char ascii_code = wparam;

if(ascii_code==13)
{
loadstring = 1;
return(0);
break;
}
loader[index++] = ascii_code;
sprintf(buffer, "%c", ascii_code);
Draw_Text_GDI(buffer, 20, 40, RGB(255, 255, 255), lpddsprimary);
return(0);
} break;
The 2 variables are up in the global space like this:
char loader[80];
int index = 0;
Again I appreciate your suggestions. They make common sense but then common sense doesn't seem to have much in common with windows. Thanks, Slider
Hmm, I'm not sure what to say. I added the same lines to a program of mine and it worked fine. Any chance it's some other part messing up?

This topic is closed to new replies.

Advertisement