Thanks - especially for the link that explains the mystery. Glyfyx

I recently started using a Logitech keyboard with several specific special keys - volume control, WWW, E-Mail, Mute, and so on, and they all work. So I'm wondering what it sends when I press them. The keyboard did not require any special software - just plug it in and go. So I reason that the only thing it can send are keyboard keystrokes, since its a keyboard without host software. I reason further that if I knew what it sends then I should be able to send the same thing by striking keys on the keyboard. In other words, regardless of what application is running, I should be able to send a sequence of keystrokes that will open up my e-mail client. Am I right? Does anyone have an idea what's going on here? Thanks folks.. glyfyx

Thanks everyone for a great solution - InnoSetup is excellent, and sooo easy to use. I got it to work first pass !! Thanks again glyfyx

I've written a simple standalone win32 exe in plain C that I'd like to ship to friends on an install/setup CD. I'm using VS 2003 Academic and can't find a clear explanation how to go about creating a simple setup. I recall how easy it was with VB5 Enterprise, and was expecting the VS 2003 procedure to be at least as easy - but not to be. There must be an understandable way to create a simple setup for a simple win32 exe - understandable to me, that is. All help appreciated! glyfyx

Maxim Zarus wrote: the value would be 510. Thank you Maxim - you just saved me a whole lot of experimenting!! /nick

I'm developing a game that relies on hitting a Shift key several times. During testing the Sticky Keys featured popped up and I read somewhere it could be disabled by setting the 'flags' value of the registry key HKEY_CURRENT_USER\Control Panel\Accessibility\StickyKeys to zero. So I set it to zero, but like a dummy, I did not SAVE the original value (possibly it was 26). I now want to reset it to its original value - I did a very recent Win2000 reinstall, and assumed all default accessibility values. Would some kind Win2000 user kindly let me know what his/her setting is for this flag - especially if its an install default value - please? Thanks for the help! /nick

Thanks rotter - I believe that's it! I used Spy++ (for the first time!) and found what looks very much like a child window and its handle under Notepad. Now what I have to do is figure out how to obtain the child's handle in my code then send WH_CHAR to it. Big help - thanks! glyfyx

In my simple win32 pgm I launch Notepad, CreateProcess("c:\\winnt\\notepad.exe"... then get a handle to it, hwndTarget = FindWindow(NULL, TEXT("Untitled - Notepad")); then close it with no problem, SendMessage(hwndTarget, WM_CLOSE, 0, 0); But if instead of closing it I try to Post/Send it a character to display PostMessage (hwndTarget, WM_CHAR, 'x', 1) ; SendMessage (hwndTarget, WM_CHAR, 'z', 1) ; it doesn't work. So I'm missing something here, but don't know what it is. Thanks for any assistance! glyfyx

Thanks for the response David. But doesn't WM_GETTEXT only return the text of the windows title - that is, for non-EditControl class windows? glyfyx

Thanks a lot Mark! I understand what you're saying - that once text is onscreen, it's just pixels. I still wonder how, for example, context sensitive help works. Suppose I have 50 pages of source code available onscreen in my IDE and I place the caret on a string *anywhere* in the code and press F1. I will get help related to the string near/on the caret. The F1 support code must somehow obtain the ansi/unicode/whatever equivalent of the onscreen string in order to lookup and return information related to the string. The only way I imagine F1 support code can accomplish this is either: 1 - to maintain an internal text copy of the entire source code and use the caret's x,y point to map into its text-copy to the exact text equivalent of the screen's image of the string; 2 - or as you suggest, the F1 code must ocr the pixels in the immediate vicinity of the caret to decifer its string equivalent. Somehow, neither sounds very appealing. Especially alternative 1 - wow - can you imagine having to keep the internal copy in synch with the myriad screen operations possible? Your ocr suggestion seems more reasonable (in comparison.) Could it be that the text-entry part of an IDE is the client area of an EditControl class window, permitting F1 code to use EM_* msgs? What about all the other text-oriented applications, text editors, WPs, publishing apps, IDEs, spreadsheets, email, etc, are they all EditContol client areas? Hmm.. maybe I should write some code to find out what are the various window classes currently running in my machine. I assume there are API calls that'll supply this information? There must be one that does that. At any rate, I'm very happy to receive your answers even if they're not ones I'd been hoping for - much appreciated! glyfyx

Just a word of thanks - appreciated! glyfyx

Thanks for taking time to provide such a complete answer - much appreciated! glyfyx

MSDN tells me only EditControl class windows provide the means to manipulate text strings displayed in their client area. EG, EM_SETSEL, EM_REPLACESEL, messages. Which is fine, but I need a more general solution. I need to access a text string displayed in a non-EditControl type window's client area. It's obvious such code exists, because if I double-click text string T in a text-enabled but non-EditControl class window A of arbitrary app A, T will be highlighted in most if not all cases. When I press Ctrl-C, T will be copied to the clipboard. Some code, no doubt Windows code, located the string of highlighted characters, grabbed a copy of it, and stuck it onto the clipboard. My question is: What do I need to know in order to write code that does the same thing under my control of my pgm? Or is such code available somewhere that I could adapt, and if so, how can I acquire it? Sometimes there are undocumented Windows routines that are available - maybe something I can use? What do you think? Is there a simple answer I'm too inexperienced to realize - possibly as I'm a win32 intermediate newbie at best. I've looked and looked but can't find anything helpful. Any information, suggestions, clues, references, etc, will be very much appreciated. Big thanks! /glyfyx

I'd like to search the active window's client area for a given string and highlight it. I've done this in VB using SelStart and SelLength. I'm sure I've seen the same functionality available from a conventional Windows program, but can't remember what the win32 API calls are. Does anyone know, or have tips on how to find out? Thanks for the assist. glyfyx

Of course, %c for char! I was sure it had a simple answer but couldn't see it for looking - most embarrassing. Too many years of VB? So big thanks Maxwell and Mark! Also Mark, I was starting to think of assembling a 2 byte char array as you suggested - that'd work with %s. Also special thanks to Rajkumar R for the ToAscii suggestion, which is intriguing to say the least, since it requires a GetKeyboardState call to set its 256 byte array arg, lpKeyState, to the current status of *all* the virtual keys. I would have thought GetKeyState for just the virtual key in question (1st arg, uVirtKey),would be sufficient. I suppose ToAscii will be a case-sensitive conversion - will give it a shot and see what happens. int ToAscii( UINT uVirtKey, UINT uScanCode, PBYTE lpKeyState, LPWORD lpChar, UINT uFlags ); Here's the MSDN article... http://msdn2.microsoft.com/en-us/library/ms646299(VS.85).aspx Thanks again everyone! glyfyx

I'm very rusty - haven't coded C/C++ since 1994 - and I'm sure there's a simple answer, but I can't find it. I'm not using 'string' support. Just the old char* methods, and the code is behaving well except when I tried to convert a keyboard virtual key code to a it's ascii character I got a runtime access violation. The 'break' option showed me the site of the infraction - inside some MS code located in the midst of some UNICODE related logic, judging by the Defines. I included , but it didn't help. The related trimmed code follows: char c; c = (char)__toascii(keyCode); keyCode = p->vkCode; The offending later statement is: nLen = fprintf(fOut,"kcK=%d ud=%s kc=%d sh=%d ti=%d %s\n",cb.kcK,updn,keyCode,Shift,tick, c); The following statement works perfectly (as above, but no c at the end) nLen = fprintf(fOut,"kcK=%d ud=%s kc=%d sh=%d ti=%d %s\n",cb.kcK,updn,keyCode,Shift,tick); Searched the articles and FAQ but didn't find anything. Hope you can give me a hand here. BTW, I want to stay in the char* arena rather than strings, for now. I'm using Visual C++ 2003 and running Win2K SP4 One more thing - I'm logged in under my old email glyfyx@storm.ca but I have a new address, glyfix@storm.ca. I guess I should change it at Code Project? Thanks glyfyx

For the sake of closure on this thread, if you exactly follow Microsoft's rules to set a LOCAL low-level keyboard hook don't expect it to run because Microsoft forbids its execution. According to Microsoft the following will result in a setting a LOCAL hook: HHOOK hhkLowLevelKybd = SetWindowsHookEx( WH_KEYBOARD_LL, HookProc, NULL, GetCurrentThreadId()); However, it fails execution, returning NULL. I took the trouble to rerun it in order to get extended error information and got this surprising formatted error message in a MessageBox: "SetWindowsHookEx failed with error 1429: This hook procedure can only be set globally." Do I laugh or cry?

Thanks Mark - very much!! That's what I get for spending the last several years doing VB! I won't do that again - even once is too often! Thanks again.. glyfyx

In a Win32 app I am able to set global keyboard hooks, but not a local hook. I've coded the call as required for a local hook but it complains that GetCurrentThreadID can't be found. But I see that winbase.h (invoked by windows.h) contains the following declaration of GetCurrentThreadId: WINBASEAPI DWORD WINAPI GetCurrentThreadId( VOID ); The following call setting a global hook works fine: HHOOK hhkLowLevelKybd = SetWindowsHookEx(WH_KEYBOARD_LL, HookProc, hinstExe, 0); The identical pgm with the following call setting a LOCAL hook fails: HHOOK hhkLowLevelKybd = SetWindowsHookEx(WH_KEYBOARD_LL, HookProc, NULL, GetCurrentThreadID()); The error it gives is: error C3861: 'GetCurrentThreadID': identifier not found, even with argument-dependent lookup I've seen docs saying that GetCurrentThreadID is deprecated, but there's no alternative given. Surely there must be some way a thread can find out its own thread id, but I haven't been able to find out how. I'm using VS 2003 tools. Any ideas anyone? Many thanks in advance! glyfyx