Codepage again... - OS2

This is a discussion on Codepage again... - OS2 ; Well, in AE I now change the codepage and that affects the display OK. However characters typed into the MLE, still come out in the codepage of the system. I assume that this means I should be doing WinSetCP as ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 48

Thread: Codepage again...

  1. Codepage again...

    Well, in AE I now change the codepage and that affects the display OK.
    However characters typed into the MLE, still come out in the codepage of
    the system.

    I assume that this means I should be doing WinSetCP as well.

    Unfortunately, according to W4.5 toolkit docs, that can only set to
    codepages specified in CODEPAGE= in config.sys.

    This seems to suggest that as long as I am using MLE my feature to set
    any codepage is somewhat useless, as it can only change the way existing
    text is displayed.

    --
    aaronl at consultant dot com
    For every expert, there is an equal and
    opposite expert. - Arthur C. Clarke

  2. Re: Codepage again...

    On Wed, 5 Jan 2005 13:18:36 UTC, Aaron Lawrence wrote:

    > Well, in AE I now change the codepage and that affects the display OK.
    > However characters typed into the MLE, still come out in the codepage of
    > the system.
    >
    > I assume that this means I should be doing WinSetCP as well.
    >
    > Unfortunately, according to W4.5 toolkit docs, that can only set to
    > codepages specified in CODEPAGE= in config.sys.
    >
    > This seems to suggest that as long as I am using MLE my feature to set
    > any codepage is somewhat useless, as it can only change the way existing
    > text is displayed.


    This is not an answer to your question. I am not familiar with this aspect
    of PM too much. I only know that:
    a) keyboard layouts from KEYBOARD.DCP are used for text mode sessions only;
    b) keyboard layouts for PM programs are totally independent from KEYBOARD.DCP;
    they are stored in the PMMRGRES.DLL, and this subsystem is much less
    flexible then KEYBOARD.DCP

    But there is \LANGUAGE\KEYBOARD directory, and it contains a lot of keyboard
    layout files (with Unicode indices inside). And I am very interesting: how to
    use them, or what purpose they are there for?

    --
    Yuri Proniakin

  3. Re: Codepage again...

    [A complimentary Cc of this posting was sent to
    Yuri Proniakin
    ], who wrote in article :
    > On Wed, 5 Jan 2005 13:18:36 UTC, Aaron Lawrence wrote:
    > This is not an answer to your question. I am not familiar with this aspect
    > of PM too much.


    Likewise.

    > I only know that:
    > a) keyboard layouts from KEYBOARD.DCP are used for text mode sessions only;


    I suspect that the situation is in fact 2-step:

    a1) Keyboard layout for text mode sessions are done via an IoCtl call();

    a2) Parameters for this call are extracted from KEYBOARD.DCP.

    So one should be able to setup *any* keyboard layout no matter what
    KEYBOARD.DCP says if one is able to grok the documentation of the
    corresponding IoCtl() ;-(;

    > b) keyboard layouts for PM programs are totally independent from KEYBOARD.DCP;
    > they are stored in the PMMRGRES.DLL, and this subsystem is much less
    > flexible then KEYBOARD.DCP


    I have no idea what low-level call is done here...

    > But there is \LANGUAGE\KEYBOARD directory, and it contains a lot of keyboard
    > layout files (with Unicode indices inside). And I am very interesting: how to
    > use them, or what purpose they are there for?


    http://www.google.com/search?q=cache.../2+glyph&hl=en

    mentioned that there is a tool to set all 3 types of keyboards by one
    call. Maybe it reads \LANGUAGE\KEYBOARD\* and translates it to an
    IoCtl() calls?

    Hope this helps,
    Ilya

  4. Re: Codepage again...

    On Wed, 5 Jan 2005 22:25:09 +0000 (UTC) Ilya Zakharevich wrote:
    >
    > > I only know that:
    > > a) keyboard layouts from KEYBOARD.DCP are used for text mode sessions only;

    >
    > I suspect that the situation is in fact 2-step:
    >
    > a1) Keyboard layout for text mode sessions are done via an IoCtl call();
    >
    > a2) Parameters for this call are extracted from KEYBOARD.DCP.
    >
    > So one should be able to setup *any* keyboard layout no matter what
    > KEYBOARD.DCP says if one is able to grok the documentation of the
    > corresponding IoCtl() ;-(;
    >
    > > b) keyboard layouts for PM programs are totally independent from KEYBOARD.DCP;
    > > they are stored in the PMMRGRES.DLL, and this subsystem is much less
    > > flexible then KEYBOARD.DCP

    >
    > I have no idea what low-level call is done here...
    >
    > > But there is \LANGUAGE\KEYBOARD directory, and it contains a lot of keyboard
    > > layout files (with Unicode indices inside). And I am very interesting: how to
    > > use them, or what purpose they are there for?

    >
    > http://www.google.com/search?q=cache.../2+glyph&hl=en
    >
    > mentioned that there is a tool to set all 3 types of keyboards by one
    > call. Maybe it reads \LANGUAGE\KEYBOARD\* and translates it to an
    > IoCtl() calls?


    A while ago I experimented with "on the fly" switching of key
    definitions to support inputting of several (non-bidi) languages.

    The application I found that gave the greatest flexibility was
    called KBDREDEF. I did not attempt to examine its internals,
    I just used it. It gave me what I wanted - freedom from having
    to use the key assignments as pre-defined by someone else.

    mikus


  5. Re: Codepage again...

    [A complimentary Cc of this posting was sent to
    Mikus Grinbergs
    ], who wrote in article :
    > On Wed, 5 Jan 2005 22:25:09 +0000 (UTC) Ilya Zakharevich wrote:
    > > I suspect that the situation is in fact 2-step:
    > >
    > > a1) Keyboard layout for text mode sessions are done via an IoCtl call();
    > >
    > > a2) Parameters for this call are extracted from KEYBOARD.DCP.
    > >
    > > So one should be able to setup *any* keyboard layout no matter what
    > > KEYBOARD.DCP says if one is able to grok the documentation of the
    > > corresponding IoCtl() ;-(;


    > The application I found that gave the greatest flexibility was
    > called KBDREDEF. I did not attempt to examine its internals,
    > I just used it. It gave me what I wanted - freedom from having
    > to use the key assignments as pre-defined by someone else.


    Thanks; got it from Hobbes. It comes without source code. I will not
    have time today to run it under os2call (sp?) to find out how it does
    it... It claims to work in PM, FS, OS/2, MDOS, but not Win-OS2.

    Yours,
    Ilya

  6. Re: Codepage again...

    In article ,
    Aaron Lawrence wrote:

    >Well, in AE I now change the codepage and that affects the display OK.
    >However characters typed into the MLE, still come out in the codepage of
    >the system.
    >
    >I assume that this means I should be doing WinSetCP as well.
    >
    >Unfortunately, according to W4.5 toolkit docs, that can only set to
    >codepages specified in CODEPAGE= in config.sys.


    but how did you manage to change the code page in MLE ?
    did you set a hook and issue GpiSetCP() when the MLE get painted ?
    you probably have to do the same if possible on WM_CHAR and other
    kind of text input (like paste)...

    Or is there some other MLM_ message I'm not aware of ?
    (I mean to change the codepage)

    --
    bye
    Alessandro Cantatore
    email reply to: acantatore_at_tin_dot_it

  7. Re: Codepage again...

    On Thu, 6 Jan 2005 10:37:11 UTC, Ilya Zakharevich wrote:

    > > The application I found that gave the greatest flexibility was
    > > called KBDREDEF. I did not attempt to examine its internals,
    > > I just used it. It gave me what I wanted - freedom from having
    > > to use the key assignments as pre-defined by someone else.

    >
    > Thanks; got it from Hobbes. It comes without source code. I will not
    > have time today to run it under os2call (sp?) to find out how it does
    > it... It claims to work in PM, FS, OS/2, MDOS, but not Win-OS2.


    Here there is a lot of similar tools. All they install themselves as keyboard
    monitor, and then are intercepting and modifying packets from keyboard driver.
    As a side effect they do not use system keyboard layouts, but always offer
    their own tables in home-grown formats.

    --
    Yuri Proniakin

  8. Re: Codepage again...

    On Wed, 5 Jan 2005 22:25:09 UTC, Ilya Zakharevich wrote:

    > > This is not an answer to your question. I am not familiar with this aspect
    > > of PM too much.

    >
    > Likewise.
    >
    > > I only know that:
    > > a) keyboard layouts from KEYBOARD.DCP are used for text mode sessions only;

    >
    > I suspect that the situation is in fact 2-step:
    >
    > a1) Keyboard layout for text mode sessions are done via an IoCtl call();
    >
    > a2) Parameters for this call are extracted from KEYBOARD.DCP.
    >
    > So one should be able to setup *any* keyboard layout no matter what
    > KEYBOARD.DCP says if one is able to grok the documentation of the
    > corresponding IoCtl() ;-(;


    Are you talking here about system internals or about application level? I do
    not think that IoCtl is a right way for text editor or similar program.
    (Naturally, if it is not the only way to do this.)
    So as there are .kbl files in the \LANGUAGE\KEYBOARD - where is API for them?

    > > b) keyboard layouts for PM programs are totally independent from KEYBOARD.DCP;
    > > they are stored in the PMMRGRES.DLL, and this subsystem is much less
    > > flexible then KEYBOARD.DCP

    >
    > I have no idea what low-level call is done here...


    > > But there is \LANGUAGE\KEYBOARD directory, and it contains a lot of keyboard
    > > layout files (with Unicode indices inside). And I am very interesting: how to
    > > use them, or what purpose they are there for?

    >
    > http://www.google.com/search?q=cache.../2+glyph&hl=en
    >
    > mentioned that there is a tool to set all 3 types of keyboards by one
    > call. Maybe it reads \LANGUAGE\KEYBOARD\* and translates it to an
    > IoCtl() calls?


    ??? The only keyboard-related program on this site is PRINTKB. But it does
    not switch layouts, it "prints a graphic representation of a keyboard layout
    using PostScript". And it directly parses layout files from \LANGUAGE\KEYBOARD
    - and no more :-(

    --
    Yuri Proniakin

  9. Re: Codepage again...

    On Wed, 5 Jan 2005 13:18:36 UTC, Aaron Lawrence wrote:

    > Well, in AE I now change the codepage and that affects the display OK.
    > However characters typed into the MLE, still come out in the codepage of
    > the system.
    >
    > I assume that this means I should be doing WinSetCP as well.
    >
    > Unfortunately, according to W4.5 toolkit docs, that can only set to
    > codepages specified in CODEPAGE= in config.sys.
    >
    > This seems to suggest that as long as I am using MLE my feature to set
    > any codepage is somewhat useless, as it can only change the way existing
    > text is displayed.


    "Keyboard Functions" section of CPRef contains description of KbdSetCP,
    KbdSetLayout and KbdSetLayoutUni. And this KbdSetCP does not limited by
    CODEPAGE= statement. Have you tried them?

    --
    Yuri Proniakin

  10. Re: Codepage again...

    [A complimentary Cc of this posting was sent to
    Yuri Proniakin
    ], who wrote in article :
    > On Thu, 6 Jan 2005 10:37:11 UTC, Ilya Zakharevich wrote:
    > Here there is a lot of similar tools. All they install themselves as keyboard
    > monitor, and then are intercepting and modifying packets from keyboard driver.
    > As a side effect they do not use system keyboard layouts, but always offer
    > their own tables in home-grown formats.


    This one also works in MDOS sessions, so I think it is not that
    simple. Also, it manages to intercept calls to KEYB; I think its
    source code would be educational anyway...

    BTW, is there a decent monitor with source code available? It is
    painful that Win95Keys works only from PM sessions; I think installing
    a monitor should be a good solution...

    Thanks,
    Ilya

  11. Re: Codepage again...

    [A complimentary Cc of this posting was sent to
    Yuri Proniakin
    ], who wrote in article :
    > On Wed, 5 Jan 2005 22:25:09 UTC, Ilya Zakharevich wrote:
    > > a1) Keyboard layout for text mode sessions are done via an IoCtl call();
    > >
    > > a2) Parameters for this call are extracted from KEYBOARD.DCP.
    > >
    > > So one should be able to setup *any* keyboard layout no matter what
    > > KEYBOARD.DCP says if one is able to grok the documentation of the
    > > corresponding IoCtl() ;-(;

    >
    > Are you talking here about system internals or about application level?


    Depends... Do you consider keyb.exe (sp?) "system internals"?

    If my guesses above are correct, then one should be able to write a
    replacement of keyb which uses other sources than KEYBOARD.DCP.

    > So as there are .kbl files in the \LANGUAGE\KEYBOARD - where is API for them?


    My guess is that it is some misplaced AIX stuff. ;-) :-(

    > > http://www.google.com/search?q=cache.../2+glyph&hl=en
    > >
    > > mentioned that there is a tool to set all 3 types of keyboards by one
    > > call. Maybe it reads \LANGUAGE\KEYBOARD\* and translates it to an
    > > IoCtl() calls?

    >
    > ??? The only keyboard-related program on this site is PRINTKB. But it does
    > not switch layouts, it "prints a graphic representation of a keyboard layout
    > using PostScript". And it directly parses layout files from \LANGUAGE\KEYBOARD
    > - and no more :-(


    There was no program there. But IIRC there was a slideshow about some
    "Internationalization tool" available from Software Choice which
    replaces all the legacy internationalization APIs in OS/2 by a simple
    universal fully user-configurable API.

    Can't find it now on borgendale.com. Maybe it was somewhere else? :-(

    Yours,
    Ilya

  12. Re: Codepage again...

    On Thu, 6 Jan 2005 21:42:57 UTC, Ilya Zakharevich wrote:

    > > Here there is a lot of similar tools. All they install themselves as keyboard
    > > monitor, and then are intercepting and modifying packets from keyboard driver.
    > > As a side effect they do not use system keyboard layouts, but always offer
    > > their own tables in home-grown formats.

    >
    > This one also works in MDOS sessions, so I think it is not that
    > simple.


    But almost any similar utility supports MDOS sessions too, so it not that hard.

    > Also, it manages to intercept calls to KEYB;


    Unlikely. There is no need to do it.

    > I think its
    > source code would be educational anyway...


    Try to decompile KeybMon (ftp://ftp.kiae.su/pub/.1/os2/cyrillic/keyb410h.zip)
    - it is the most powerful and flexible keyboard switcher. Its executable is
    9 KB only (code segment - less then 4 KB). And its documentation contains a
    chapter, that describes how it (and other similar programs) works.
    (Size of code segment of KBDREDEF.DLL - less then 4 KB too.)

    > BTW, is there a decent monitor with source code available? It is
    > painful that Win95Keys works only from PM sessions; I think installing
    > a monitor should be a good solution...
    >
    > Thanks,
    > Ilya



    --
    Yuri Proniakin

  13. Re: Codepage again...

    On Thu, 6 Jan 2005 21:50:00 UTC, Ilya Zakharevich wrote:

    > > > a1) Keyboard layout for text mode sessions are done via an IoCtl call();
    > > >
    > > > a2) Parameters for this call are extracted from KEYBOARD.DCP.
    > > >
    > > > So one should be able to setup *any* keyboard layout no matter what
    > > > KEYBOARD.DCP says if one is able to grok the documentation of the
    > > > corresponding IoCtl() ;-(;

    > >
    > > Are you talking here about system internals or about application level?

    >
    > Depends... Do you consider keyb.exe (sp?) "system internals"?


    No, I don't - because it is not an API. It is a small utility, that uses
    "system internals" (parses KEYBOARD.DCP and then calls DosDevIOCtl + WinSetKbd).

    > If my guesses above are correct, then one should be able to write a
    > replacement of keyb which uses other sources than KEYBOARD.DCP.


    Yes, this is possible. But it has no sense, because KEYB loads translation
    table to keyboard driver - but for text mode sessions only. After that it
    invokes WinSetKbd - and PM loads its own translation table (from PMMRGRES.DLL).

    > > So as there are .kbl files in the \LANGUAGE\KEYBOARD - where is API for them?

    >
    > My guess is that it is some misplaced AIX stuff. ;-) :-(


    But there are KbdSetLayout and KbdSetLayoutUni functions. First parameter
    of both is:
    --------
    >The name of the keyboard layout. The length of the name cannot exceed
    >8 characters.

    --------
    Standard form of traditional keyboard layout name is: 2 letters + 3 digits.
    So why 8? Isn't it influenced by "8.3" limitation for file names?
    And PRINTKB (below) was written not just for curiosity (I hope).

    KEYB was written many years ago. We want to set the keyboard layout for one
    single PM session, not for a whole system. So we should not mimic the KEYB
    if there is another method.

    > > > http://www.google.com/search?q=cache.../2+glyph&hl=en
    > > >
    > > > mentioned that there is a tool to set all 3 types of keyboards by one
    > > > call. Maybe it reads \LANGUAGE\KEYBOARD\* and translates it to an
    > > > IoCtl() calls?

    > >
    > > ??? The only keyboard-related program on this site is PRINTKB. But it does
    > > not switch layouts, it "prints a graphic representation of a keyboard layout
    > > using PostScript". And it directly parses layout files from \LANGUAGE\KEYBOARD
    > > - and no more :-(

    >
    > There was no program there. But IIRC there was a slideshow about some
    > "Internationalization tool" available from Software Choice which
    > replaces all the legacy internationalization APIs in OS/2 by a simple
    > universal fully user-configurable API.
    >
    > Can't find it now on borgendale.com. Maybe it was somewhere else? :-(


    --
    Yuri Proniakin

  14. Re: Codepage again...

    In article ,
    @tin.it (Alessandro Cantatore) wrote:

    >but how did you manage to change the code page in MLE ?
    >did you set a hook and issue GpiSetCP() when the MLE get painted ?
    >you probably have to do the same if possible on WM_CHAR and other
    >kind of text input (like paste)...
    >
    >Or is there some other MLM_ message I'm not aware of ?
    >(I mean to change the codepage)


    OK... I've checked more carefully... if I set Thai codepage, I can
    type Thai characters if I use Alt + the numpad keys...

    so the problem lies with switching keyboard layouts

    since I do not think it is advisable to do that systemwide
    as probably the user would just need to type some text in ae.exe
    you probably have to subclass the MLE and replace WM_CHAR
    parameters

    I do not know if the \language\keyboard content may help...
    at a first glance my keyboard layout (IT.KBL) contains
    3 array of scancodes you get when pressing the keys without
    any modifier, the keys + shift, the keys + AltGr...

    BTW but how did you manage to change the codepage in the MLE ?

    --
    bye
    Alessandro Cantatore
    email reply to: acantatore_at_tin_dot_it

  15. Re: Codepage again...

    On 07.01.05 18:23, Alessandro Cantatore wrote:

    > In article ,
    > @tin.it (Alessandro Cantatore) wrote:
    >
    >> but how did you manage to change the code page in MLE ? did you set
    >> a hook and issue GpiSetCP() when the MLE get painted ? you probably
    >> have to do the same if possible on WM_CHAR and other kind of text
    >> input (like paste)...
    >>
    >> Or is there some other MLM_ message I'm not aware of ? (I mean to
    >> change the codepage)

    >
    > OK... I've checked more carefully... if I set Thai codepage, I can
    > type Thai characters if I use Alt + the numpad keys...
    >
    > so the problem lies with switching keyboard layouts
    >
    > since I do not think it is advisable to do that systemwide as
    > probably the user would just need to type some text in ae.exe you
    > probably have to subclass the MLE and replace WM_CHAR parameters
    >
    > I do not know if the \language\keyboard content may help... at a
    > first glance my keyboard layout (IT.KBL) contains 3 array of
    > scancodes you get when pressing the keys without any modifier, the
    > keys + shift, the keys + AltGr...
    >
    > BTW but how did you manage to change the codepage in the MLE ?


    At first: sorry for the full quoting: I didn't find a place to step
    in.

    That all sounds to me much too complicated (like I've already posted
    to Aaron before):

    1) Why should someone type in a different as the default cp?

    2) Wouldn't it be a better (and for me, it looks like: easier) way to
    convert the text (to the current cp) before showing it?

    --
    Andreas Schnellbacher

  16. Re: Codepage again...

    On Fri, 7 Jan 2005 18:53:35 UTC, Andreas Schnellbacher wrote:

    > That all sounds to me much too complicated (like I've already posted
    > to Aaron before):
    >
    > 1) Why should someone type in a different as the default cp?


    Imagine, for example, that you need to print text with some characters, that
    are not present in the default CP - em-dashes, en-dashes, typographic quotes,
    etc.

    > 2) Wouldn't it be a better (and for me, it looks like: easier) way to
    > convert the text (to the current cp) before showing it?


    And what will you do if you need to read Cyrillic that is written in ANSI-1251?
    Does your current CP contain this characters?

    --
    Yuri Proniakin

  17. Re: Codepage again...

    On 07.01.05 21:39, Yuri Proniakin wrote:

    > On Fri, 7 Jan 2005 18:53:35 UTC, Andreas Schnellbacher
    > wrote:
    >
    >> That all sounds to me much too complicated (like I've already
    >> posted to Aaron before):
    >>
    >> 1) Why should someone type in a different as the default cp?

    >
    > Imagine, for example, that you need to print text with some
    > characters, that are not present in the default CP - em-dashes,
    > en-dashes, typographic quotes, etc.


    Sounds interesting, but I don't have an example for that.

    >> 2) Wouldn't it be a better (and for me, it looks like: easier) way to
    >> convert the text (to the current cp) before showing it?

    >
    > And what will you do if you need to read Cyrillic that is written in
    > ANSI-1251? Does your current CP contain this characters?


    Of course: not, I guess (while speaking german). That's really an
    argument.

    But here, the main issue with foreign texts can be resolved with
    changing the chars before showing it in the app. That works well for
    german texts with umlauts, written in latin1 (Linux) or W$ and showing
    them in cp850. Of course, the current cp (that one, that shows these
    chars) contains them. (You're right, that this shouldn't work with
    cyrillic text.)

    --
    Andreas Schnellbacher

  18. Re: Codepage again...

    On Fri, 7 Jan 2005 21:01:05 UTC, Andreas Schnellbacher wrote:

    > >> 2) Wouldn't it be a better (and for me, it looks like: easier) way to
    > >> convert the text (to the current cp) before showing it?

    > >
    > > And what will you do if you need to read Cyrillic that is written in
    > > ANSI-1251? Does your current CP contain this characters?

    >
    > Of course: not, I guess (while speaking german). That's really an
    > argument.
    >
    > But here, the main issue with foreign texts can be resolved with
    > changing the chars before showing it in the app. That works well for
    > german texts with umlauts, written in latin1 (Linux) or W$ and showing
    > them in cp850. Of course, the current cp (that one, that shows these
    > chars) contains them. (You're right, that this shouldn't work with
    > cyrillic text.)


    And even for german text you steel need some tool for converting it to CP850
    (and back, if you need to edit this text and return to the original system).
    So why do not do it directly in the editor? Especially if you do not know
    beforehand in what code page this text is written, and need to ascertain it
    by trials.

    --
    Yuri Proniakin

  19. Re: Codepage again...

    On Fri, 7 Jan 2005 21:01:05 UTC, Andreas Schnellbacher wrote:

    > >> 1) Why should someone type in a different as the default cp?

    > >
    > > Imagine, for example, that you need to print text with some
    > > characters, that are not present in the default CP - em-dashes,
    > > en-dashes, typographic quotes, etc.

    >
    > Sounds interesting, but I don't have an example for that.
    >
    > >> 2) Wouldn't it be a better (and for me, it looks like: easier) way to
    > >> convert the text (to the current cp) before showing it?

    > >
    > > And what will you do if you need to read Cyrillic that is written in
    > > ANSI-1251? Does your current CP contain this characters?

    >
    > Of course: not, I guess (while speaking german). That's really an
    > argument.
    >
    > But here, the main issue with foreign texts can be resolved with
    > changing the chars before showing it in the app. That works well for
    > german texts with umlauts, written in latin1 (Linux) or W$ and showing
    > them in cp850. Of course, the current cp (that one, that shows these
    > chars) contains them. (You're right, that this shouldn't work with
    > cyrillic text.)


    "Windows"? That's you, who said it.
    I often receive e-mails, that are written in Windows (in ANSI family of
    code pages) and contain some characters, that are not present in IBM family
    of code pages (CP850 is one of them).
    In other words - "see answer for first question" :-)

    --
    Yuri Proniakin

  20. Re: Codepage again...

    [A complimentary Cc of this posting was sent to
    Yuri Proniakin
    ], who wrote in article :
    > On Thu, 6 Jan 2005 21:50:00 UTC, Ilya Zakharevich wrote:
    > > Depends... Do you consider keyb.exe (sp?) "system internals"?

    >
    > No, I don't - because it is not an API. It is a small utility, that uses
    > "system internals" (parses KEYBOARD.DCP and then calls DosDevIOCtl + WinSetKbd).
    >
    > > If my guesses above are correct, then one should be able to write a
    > > replacement of keyb which uses other sources than KEYBOARD.DCP.

    >
    > Yes, this is possible. But it has no sense, because KEYB loads translation
    > table to keyboard driver - but for text mode sessions only. After that it
    > invokes WinSetKbd - and PM loads its own translation table (from PMMRGRES.DLL).


    What is WinSetKbd() - can't find in the docs or on google.

    > But there are KbdSetLayout and KbdSetLayoutUni functions. First parameter
    > of both is:
    > --------
    > >The name of the keyboard layout. The length of the name cannot exceed
    > >8 characters.

    > --------
    > Standard form of traditional keyboard layout name is: 2 letters + 3 digits.
    > So why 8? Isn't it influenced by "8.3" limitation for file names?


    Do not think it is relevant; this is legacy stuff, right? So it was
    written ages before Unicode-based stuff appeared...

    --------------------------------------------

    BTW, looks like you know details of KEYB operation; and I can't make
    it work after upgrade Warp3->Warp4. The problem: with
    codepages=850,866 the command `keyb ru' gives error 1744 (which has a
    useless explanation)... It works fine with codepages=866,850 (which I
    do not want to use).

    Running it under OS2TRACE shows that IoCtl category 4=IOCTL_KEYBOARD
    function 0x5C=KBD_SETNLS fails; the parameter packet is

    Code Page Translation Table = SOME_POINTER;
    Code Page Number = 0x0362 = 866
    Index To Load = 4

    Note that "Index To Load" is outside the allowed range 1--2 (and,
    maybe, 0). No wonder it fails.. This is a THIRD (!) call to this
    IoCtl; the parameters to the previous two calls were quite reasonable
    (850 and1 and 866 and 2).

    Why does it want to setup a THIRD codepage? How to fix it?

    Puzzled,
    Ilya

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast