Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: Alt+Letter key problm in win32 console

  1. #1

    Default Alt+Letter key problm in win32 console

    If there is a better forum for this message I understand if it gets moved.

    I'm writing a small program that I plan to compile for DOS and also for WIN32 console. I used getch() to fetch the keys and some are extended keys where you will get a 0 first and then a second key value. Left arrow is a 0 followed by a 75. What I always have done is check for a 0 and if so, fetch another character from getch() and then add 256 to it. In this case 256+75=331, so if I see a 331, I know it is the left arrow.

    My first question is, is there a list of these extended keys somewhere?

    The second problem I am having is some sort of Windows 10 console problem. It will not pass ALT+A as the proper key (0 followed by 30, or 286 by my add 256 method), but rather it passes it as if the ALT key was not being pressed. Interestingly, the win10 console will process ALT+F1 properly, but not ALT+A properly. I've tried using the legacy console/not legacy console and turning on/off all the options such as quick edit, insert mode, etc., but I can't get it to produce a real ALT+A no matter what I try.

  2. #2
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,511
    Blog Entries
    20

  3. #3
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    462

    Default

    Windows has a special set of messages for alt keypresses (WM_SYSKEYDOWN and WM_SYSKEYUP). How you detect alt keys in a Windows console application depends on the language being used. If it's a .NET program the easiest way is probably to use Console.ReadKey() to get a ConsoleKeyInfo struct that will indicate whether Shift, Ctrl and/or Alt were held or not. For a native program this link might point you in the right direction:

    https://stackoverflow.com/questions/...indows-console

  4. #4
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,511
    Blog Entries
    20

    Default

    As I understand it, the OP wants to use the C library function getch(). I don't know if there's a do-it-all standard C library function for this.

  5. #5
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    462

    Default

    It appears to be a bug in the 32-bit Windows C runtime library: https://jeffpar.github.io/kbarchive/kb/107/Q107427/

  6. #6
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,511
    Blog Entries
    20

    Default

    Since that was in 2002, I don't suspect that an MS fix will be forthcoming.

    You'll have to write your own library function, it seems.

  7. #7

    Default

    I'm using an older Borland compiler (C++ Builder 6) and its conio.h library. I'm going to test it in older win32 OS's to see if it works there; I'll bet it does.

    I'm writing an editor; I've always wanted to, but never got around to it. I know there are plenty of editors, but I've always wanted to go through the challenge of making one myself. Also, I want to give it some macro capabilities. Even today I still use superkey with DOS editors sometimes which mostly works, but sometimes there is a disconnect between it and the editor where keys are lost. I hope to eliminate that by integrating the macro feature in the editor itself, and making both a WIN32 and DOS16 will let me do macro modification of files in the win32 environment.

    One question - my approach is to allocate a memory structure for each line so that I can insert/delete/modify lines without having to shift up or down large chunks of memory. Is there a better way? Memory isn't such a concern for WIN32, but DOS is a different world for sure. I've tried a simple pointer approach where I support 16383 lines (4 byte pointers * 16383 = around 64K) and then each one points to a line. I was also going to try a ptr to ptr to line approach so I could do more lines in DOS than the 16K, but it seemed like a lot of trouble to go through code wise.

  8. #8

    Default

    Testing shows that the OS makes no difference, I even went back to NT4 and it still doesn't work! So much for me blaming it on win10. It then occurred to me that I had other programs in win32 console that did respond to Alt+letters so going back to review some stuff from 2 decades ago shows that I wrote some code that uses ReadConsoleInput and converts the results to be what getch() would return! I'm not sure I want to bring all that code into my simple editor just to have Alt+ key support when I also have WordStar type support too. Maybe.

  9. #9
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    31,511
    Blog Entries
    20

    Default

    Have you looked at the code in joe's own editor? It's a Wordstar clone and versions exist for DOS, Win16, Win32 and various flavors of Linux (even ARM-based).

  10. #10
    Join Date
    Mar 2017
    Location
    New Jersey, USA
    Posts
    462

    Default

    Regarding memory management, whether there's a better way or not depends on the style of editor you're writing. For a line editor, structuring your memory allocations per line makes sense. For a screen editor, you might find a line-based structure overly constraining. I feel like you would be well served to focus first on how you will manage character insertion/deletion within a line, how you will handle potentially very long lines, and how you might avoid wasting too much memory for very short lines (or blank lines). I suspect that once those issues are sorted out, whatever scheme you come up with will extend naturally to handling lines as well.

    If I were going to write my own editor, one of the first questions I'd ask myself is whether I want to be able to edit files too large to fit in memory. If the answer is yes, that dramatically changes how memory management will need to be done.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •