Codepage again... - OS2

This is a discussion on Codepage again... - OS2 ; On Sat, 8 Jan 2005 09:31:38 UTC, Ilya Zakharevich wrote: > > > If my guesses above are correct, then one should be able to write a > > > replacement of keyb which uses other sources than KEYBOARD.DCP. > ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 48

Thread: Codepage again...

  1. Re: Codepage again...

    On Sat, 8 Jan 2005 09:31:38 UTC, Ilya Zakharevich wrote:

    > > > 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.


    Sorry. This name I manually added to disassembler table for PMWin.296 function
    many years ago and then just copied from old to new versions. Now I looked at
    this file more closely and discovered that it contains another name for this
    ordinal - WinSetKbdLayout.
    WinSetKbdLayout is not described in the toolkit documentation, but it is
    defined in the pmbidi.h file (together with layout numbers). Also this name
    is used in sources of KLayer (yet one keyboard switcher).

    > > 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...


    KbdSetLayout is not mentioned in the OS/2 1.3/2.0 programming documentation
    (at least I am not able to find it). Moreover, first parameter of
    KbdSetLayoutUni is Unicode string. So do they legacy?

    > --------------------------------------------
    >
    > 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).


    I use russian version of OS/2, where only "866,850" sequence is possible
    (otherwise desktop will not be loaded). But now I checked "850,866" in
    english version of Warp 4 (COUNTRY=007; CODEPAGE=850,866; DEVINFO=KBD,RU443).
    The result was quit unexpected.
    "keyb ru" from command line displayed me two string of success. Nevertheless,
    I still was not able to switch keyboard to russian mode! But in e.exe, that
    was launched from this session, keyboard switching worked!

    > 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).


    Do not know why CPRef allows only 2. AFAIK, max. value for this index - 3
    (or even 4)!
    Your sequence is correct. First call loads latin layer of RU443 layout for
    CP850. Second call loads latin layer of RU443 layout for CP866. Third call
    loads national layer of RU443 layout for CP866.

    > Why does it want to setup a THIRD codepage?


    It's not a third codepage. KEYBOARD.DCP, unlike its PM counterparts, is quit
    sophisticated and flexible stuff. (Have you looked at it in any layout editor?)
    Every layout is defined separately for different code pages, and for each code
    page it consists of one or two separate tables (layers).
    Loading of every layer requires separate call of IoCtl. RU is equivalent to
    RU443. For your CODEPAGE= statement there are 2 matching entries for RU443 in
    the KEYBOARD.DCP: one (single-layered) for CP850, and one (double-layered) for
    CP866. That's why 3 calls are required.

    > How to fix it?


    I do not know yet. As a first step: what keyb will tell you after "keyb ru441"
    (instead of 443)? And what fixpack is installed on your system (IOW, does
    "Keyboard" notebook in the System setup folder contain "Layout" tab)?

    --
    Yuri Proniakin


  2. Re: Codepage again...

    On 07.01.05 23:08, Yuri Proniakin wrote:

    > 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?

    >
    > 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.


    Ok, I understand. But I see following problems:

    - Text, copied to the clipboard, can be used only in apps with the
    same cp correctly. Maybe it would better to convert it to the
    standard cp before copying?

    - I load a text, maybe a manual, switch the cp to make the editor
    show a few chars correctly, add my own stuff and save it. Then I
    would create a text in a different cp, what is not what I would
    expect, if a reversible conversation is possible, of course.

    Therefore for the texts, I deal with, I would prefer to use another
    tool to convert them. Note, that I usually don't have to create text
    for foreign systems and cps. Most of the files are readmes.

    Looks like an optional conversation on Save and for the clipboard
    (beside the cp selection for the editor control and the keyboard)
    is what combines the advantages of both ways.

    --
    Andreas Schnellbacher

  3. Re: Codepage again...

    [A complimentary Cc of this posting was sent to
    Yuri Proniakin
    ], who wrote in article :
    > On Sat, 8 Jan 2005 09:31:38 UTC, Ilya Zakharevich wrote:


    > WinSetKbdLayout is not described in the toolkit documentation, but it is
    > defined in the pmbidi.h file (together with layout numbers).


    I'm only up to toolkit 4.0, it is not there. Does it take only one
    argument, layout number?

    > > > 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...


    > KbdSetLayout is not mentioned in the OS/2 1.3/2.0 programming documentation
    > (at least I am not able to find it). Moreover, first parameter of
    > KbdSetLayoutUni is Unicode string. So do they legacy?


    Apparently not; I was under (wrong) impression that all Kbd* stuff is
    legacy. Can you find .EXE or .DLL which uses them?

    > > 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).

    >
    > I use russian version of OS/2, where only "866,850" sequence is possible
    > (otherwise desktop will not be loaded). But now I checked "850,866" in
    > english version of Warp 4 (COUNTRY=007; CODEPAGE=850,866; DEVINFO=KBD,RU443).
    > The result was quit unexpected.


    To the contrary (see below)... BTW, what codepage was it?

    > "keyb ru" from command line displayed me two string of success. Nevertheless,
    > I still was not able to switch keyboard to russian mode! But in e.exe, that
    > was launched from this session, keyboard switching worked!


    You mean you were not able to switch it in a VIO shell window? This
    window is created by PMSHELL, whose process codepage is 850, so the
    window's codepage is still 850, even if you did chcp in a kid process.
    So no wonder it is confusing...

    I did not try changing the shell window codepage by a window codepage
    switcher; the compiled one would not do it, and I had no time to
    recompile it yet.

    > > 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).

    >
    > Do not know why CPRef allows only 2. AFAIK, max. value for this index - 3
    > (or even 4)!
    > Your sequence is correct. First call loads latin layer of RU443 layout for
    > CP850. Second call loads latin layer of RU443 layout for CP866. Third call
    > loads national layer of RU443 layout for CP866.


    How does KBD$ know that the second call sets the first layer of second
    codepage, and not second layer of first codepage? If the calls are
    done in sequence, then it is not that difficult to distinguish, since
    the call has the codepage field. But what if you change the second
    layout separately of the first one and the second one?

    > > Why does it want to setup a THIRD codepage?

    >
    > It's not a third codepage. KEYBOARD.DCP, unlike its PM counterparts, is quit
    > sophisticated and flexible stuff. (Have you looked at it in any layout editor?)


    Yes.

    > > How to fix it?

    >
    > I do not know yet. As a first step: what keyb will tell you after "keyb ru441"
    > (instead of 443)?


    No difference.

    > And what fixpack is installed on your system


    The latest.

    > (IOW, does "Keyboard" notebook in the System setup folder contain
    > "Layout" tab)?


    Wow, I did not know about this! This successfully switches the
    keyboard. And another bug is avoided too: even after a switch to "US
    international" one can switch to "Russian"...

    Then probably KLayer will be able to replace KEYB too...

    Thanks a lot,
    Ilya

  4. Re: Codepage again...

    On Sat, 8 Jan 2005 20:28:27 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?

    > >
    > > 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.

    >
    > Ok, I understand. But I see following problems:


    I cancelled that my post less then in five minutes after sending it - because
    I had understood what you will say me and had no intention to discuss it
    (prematurely).

    > - Text, copied to the clipboard, can be used only in apps with the
    > same cp correctly. Maybe it would better to convert it to the
    > standard cp before copying?


    Text may be copied to clipboard in different formats (standard and private)
    simultaneously. In your case standard CF_TEXT may hold text converted to
    default system CP (for other applications), and some private format may hold
    the same text in its native code page or, better, in Unicode (for this editor).

    > - I load a text, maybe a manual, switch the cp to make the editor
    > show a few chars correctly, add my own stuff and save it. Then I
    > would create a text in a different cp, what is not what I would
    > expect, if a reversible conversation is possible, of course.
    >
    > Therefore for the texts, I deal with, I would prefer to use another
    > tool to convert them. Note, that I usually don't have to create text
    > for foreign systems and cps. Most of the files are readmes.


    It you can convert your texts to the system CP without loss of significant
    characters, you are lucky. But there are many peoples, who can not.

    > Looks like an optional conversation on Save and for the clipboard
    > (beside the cp selection for the editor control and the keyboard)
    > is what combines the advantages of both ways.


    If editor allows to work with text in the selected code page (as it
    implemented now), then there is very simple and logical way to convert
    this text to any other code page: select all text, cut it to the clipboard,
    select another code page, insert text from the clipboard.

    --
    Yuri Proniakin


  5. Re: Codepage again...

    On Sat, 8 Jan 2005 22:40:29 UTC, Ilya Zakharevich wrote:

    > > WinSetKbdLayout is not described in the toolkit documentation, but it is
    > > defined in the pmbidi.h file (together with layout numbers).

    >
    > I'm only up to toolkit 4.0, it is not there. Does it take only one
    > argument, layout number?


    BOOL APIENTRY WinSetKbdLayout(HWND hwndDesktop, ULONG idKbdLayout);

    > > KbdSetLayout is not mentioned in the OS/2 1.3/2.0 programming documentation
    > > (at least I am not able to find it). Moreover, first parameter of
    > > KbdSetLayoutUni is Unicode string. So do they legacy?

    >
    > Apparently not; I was under (wrong) impression that all Kbd* stuff is
    > legacy. Can you find .EXE or .DLL which uses them?


    No, I can't. No one executable contains these names. It is not unusual -
    functions are called by ordinals often, but I do not know ordinals of this
    pair. Also I can't find these names neither in the .lib files, nor anywhere
    else in the toolkit, except CPRef (cp1.inf).

    > > I use russian version of OS/2, where only "866,850" sequence is possible
    > > (otherwise desktop will not be loaded). But now I checked "850,866" in
    > > english version of Warp 4 (COUNTRY=007; CODEPAGE=850,866; DEVINFO=KBD,RU443).
    > > The result was quit unexpected.

    >
    > To the contrary (see below)... BTW, what codepage was it?


    I tried in both - no difference.

    > > "keyb ru" from command line displayed me two string of success. Nevertheless,
    > > I still was not able to switch keyboard to russian mode! But in e.exe, that
    > > was launched from this session, keyboard switching worked!

    >
    > You mean you were not able to switch it in a VIO shell window? This
    > window is created by PMSHELL, whose process codepage is 850, so the
    > window's codepage is still 850, even if you did chcp in a kid process.
    > So no wonder it is confusing...


    But the very same happens in a fullscreen session. So I am still confused.

    > > > 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).

    > >
    > > Do not know why CPRef allows only 2. AFAIK, max. value for this index - 3
    > > (or even 4)!
    > > Your sequence is correct. First call loads latin layer of RU443 layout for
    > > CP850. Second call loads latin layer of RU443 layout for CP866. Third call
    > > loads national layer of RU443 layout for CP866.

    >
    > How does KBD$ know that the second call sets the first layer of second
    > codepage, and not second layer of first codepage? If the calls are
    > done in sequence, then it is not that difficult to distinguish, since
    > the call has the codepage field. But what if you change the second
    > layout separately of the first one and the second one?


    I do not know does sequence of calls have any value or not. KEYB always loads
    secondary layer immediately after primary one. But it calculates the index for
    this secondary layer as "index of primary layer + 2". So, I think, index - what
    is important. It looks like 1 - index for primary layer of first CP, 2 - index
    for primary layer of second CP, 3 - index for secondary layer of first CP,
    and 4 - index for secondary layer of second CP. If layout for first CP does
    not have the secondary layer, then only 1,2, and 4 will be used - exactly
    as you saw.

    > > And what fixpack is installed on your system

    >
    > The latest.


    Try to compare you current KEYBOARD.DCP and KEYB.COM with original ones
    (KEYBOARD.DCP is in the fixpak, KEYB - in the \OS2IMAGE\DISK_3\BUNDLE file,
    if it is an old Warp 4, not a Convenience Package) - perhaps, something wrong
    with them.
    And didn't you forget to install the fixpak for device drivers? It contains
    KBDBASE.SYS.

    > > (IOW, does "Keyboard" notebook in the System setup folder contain
    > > "Layout" tab)?

    >
    > Wow, I did not know about this! This successfully switches the
    > keyboard. And another bug is avoided too: even after a switch to "US
    > international" one can switch to "Russian"...
    >
    > Then probably KLayer will be able to replace KEYB too...


    I think - very likely.

    --
    Yuri Proniakin

  6. Re: Codepage again...

    [A complimentary Cc of this posting was sent to
    Yuri Proniakin
    ], who wrote in article :
    > On Sat, 8 Jan 2005 22:40:29 UTC, Ilya Zakharevich wrote:
    > > > KbdSetLayout is not mentioned in the OS/2 1.3/2.0 programming documentation
    > > > (at least I am not able to find it). Moreover, first parameter of
    > > > KbdSetLayoutUni is Unicode string. So do they legacy?

    > >
    > > Apparently not; I was under (wrong) impression that all Kbd* stuff is
    > > legacy. Can you find .EXE or .DLL which uses them?

    >
    > No, I can't. No one executable contains these names. It is not unusual -
    > functions are called by ordinals often, but I do not know ordinals of this
    > pair. Also I can't find these names neither in the .lib files, nor anywhere
    > else in the toolkit, except CPRef (cp1.inf).


    Without a .lib or a known ordinal, even the existence of these API is
    very questionable... I would consider it as a misprint in
    documentation... ;-) :-(

    > > You mean you were not able to switch it in a VIO shell window? This
    > > window is created by PMSHELL, whose process codepage is 850, so the
    > > window's codepage is still 850, even if you did chcp in a kid process.
    > > So no wonder it is confusing...

    >
    > But the very same happens in a fullscreen session. So I am still confused.


    I have no plausible explanation for this...

    > I do not know does sequence of calls have any value or not. KEYB always loads
    > secondary layer immediately after primary one. But it calculates the index for
    > this secondary layer as "index of primary layer + 2".


    I see. I would probably write it as "index of primary layer" | 0x2. ;-)

    How did you deduce this? Experiments?

    > And didn't you forget to install the fixpak for device drivers? It contains
    > KBDBASE.SYS.


    You probably nailed it! My kbdbase is of '96. Do not remember how it
    happened, I see different renamed versions in the same directory,
    including the ddpak2 one, of '99. Will experiment later...

    > > Then probably KLayer will be able to replace KEYB too...

    >
    > I think - very likely.


    It does (even with the old KBDBASE.SYS).

    Thanks,
    Ilya

  7. Re: Codepage again...

    [A complimentary Cc of this posting was sent to
    Yuri Proniakin
    ], who wrote in article :
    > On Sat, 8 Jan 2005 20:28:27 UTC, Andreas Schnellbacher wrote:


    > Text may be copied to clipboard in different formats (standard and private)
    > simultaneously. In your case standard CF_TEXT may hold text converted to
    > default system CP (for other applications), and some private format may hold
    > the same text in its native code page or, better, in Unicode (for this editor).


    I think what we badly need is to agree on the name of the atom to
    denote clipboard format with Unicode-encoded clipboard text (e.g., via
    little-endian C shorts - probably the same as cp1208). Which one is
    Mozilla using?

    Yours,
    Ilya

  8. Re: Codepage again...

    On Sun, 9 Jan 2005 23:48:26 UTC, Ilya Zakharevich wrote:
    > Yuri Proniakin wrote in article :
    > > On Sat, 8 Jan 2005 20:28:27 UTC, Andreas Schnellbacher wrote:

    >
    > > Text may be copied to clipboard in different formats (standard and private)
    > > simultaneously. In your case standard CF_TEXT may hold text converted to
    > > default system CP (for other applications), and some private format may hold
    > > the same text in its native code page or, better, in Unicode (for this editor).

    >
    > I think what we badly need is to agree on the name of the atom to
    > denote clipboard format with Unicode-encoded clipboard text (e.g., via
    > little-endian C shorts - probably the same as cp1208). Which one is
    > Mozilla using?


    "text/unicode"

    BTW... if the PM codepage for a message queue doesn't match the system CP,
    PM will automatically do a codepage conversion before placing the text on
    the clipboard (at least for Plain Text).


    --
    == == almost usable email address: rich AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | New - Remote Workplace Server v0.60
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws060.zip
    __________________________________________________ _________________

  9. Re: Codepage again...

    Hello everyone,

    I see a big discussion ensued!

    Sorry for the delay. I have been having some RSI/OOS type issues so am
    cutting back on "homework"

    Suddenly, @tin.it (Alessandro Cantatore) sprang forth and uttered these
    pithy words:
    > BTW but how did you manage to change the codepage in the MLE ?


    MLM_QUERYFONT

    change FontInfo.usCodePage

    MLM_SETFONT



    Only works with the MLE, which has specially implemented this message,
    of course. Otherwise I would be SOL.

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

  10. Re: Codepage again...

    Suddenly, Andreas Schnellbacher sprang forth and uttered these pithy
    words:
    > 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?


    That is a somewhat useful function, for some cases (ones close to
    English/Roman). But it doesn't work in many, many cases. Cyrillic, Thai,
    Chinese, etc.

    As I said to you before, the whole POINT (and problem) with codepages is
    that the same code, appears as different characters, and therefore _in
    general_ CANNOT be converted.



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

  11. Re: Codepage again...

    Suddenly, Yuri Proniakin sprang forth and uttered these pithy words:
    > "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?


    KbdSetCP always seems to return 504, ERROR_KBD_EXTENDED_SG, which is not
    explained anywhere I can see. But perhaps it doesn't work under PM.

    It seems to me that the docs might be wrong about WinSetCP. It doesn't
    give an error if you set other codepages than what's in config.sys.

    It clearly changes some handling of the keyboard, as the alt key works a
    bit differently. I don't have an Alt Gr key though, so perhaps I won't
    be able to see much.


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

  12. Re: Codepage again...

    On Sun, 9 Jan 2005 23:39:16 UTC, Ilya Zakharevich wrote:

    > > > > KbdSetLayout is not mentioned in the OS/2 1.3/2.0 programming documentation
    > > > > (at least I am not able to find it). Moreover, first parameter of
    > > > > KbdSetLayoutUni is Unicode string. So do they legacy?
    > > >
    > > > Apparently not; I was under (wrong) impression that all Kbd* stuff is
    > > > legacy. Can you find .EXE or .DLL which uses them?

    > >
    > > No, I can't. No one executable contains these names. It is not unusual -
    > > functions are called by ordinals often, but I do not know ordinals of this
    > > pair. Also I can't find these names neither in the .lib files, nor anywhere
    > > else in the toolkit, except CPRef (cp1.inf).

    >
    > Without a .lib or a known ordinal, even the existence of these API is
    > very questionable... I would consider it as a misprint in
    > documentation... ;-) :-(


    But layout files for this (sp) functions are there.
    Anyway, I am interesting in API for this files, not in these particular
    functions. If there are some other functions, this will be enough. I already
    have some idea (questionable, though) and shall check it tomorrow.

    > > I do not know does sequence of calls have any value or not. KEYB always loads
    > > secondary layer immediately after primary one. But it calculates the index for
    > > this secondary layer as "index of primary layer + 2".

    >
    > I see. I would probably write it as "index of primary layer" | 0x2. ;-)


    Unlike you, I, undoubtedly, shall use INC(index, 2) ;-)

    > How did you deduce this? Experiments?


    Disassembler :-)) So all, what I see in that point, is:

    mov ax, index
    inc ax
    inc ax

    --
    Yuri Proniakin

  13. Re: Codepage again...

    On Mon, 10 Jan 2005 12:28:00 UTC, Aaron Lawrence wrote:

    > > "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?

    >
    > KbdSetCP always seems to return 504, ERROR_KBD_EXTENDED_SG, which is not
    > explained anywhere I can see. But perhaps it doesn't work under PM.
    >
    > It seems to me that the docs might be wrong about WinSetCP. It doesn't
    > give an error if you set other codepages than what's in config.sys.
    >
    > It clearly changes some handling of the keyboard, as the alt key works a
    > bit differently. I don't have an Alt Gr key though, so perhaps I won't
    > be able to see much.


    As I wrote to Ilya, KEYB changes keyboard layout for text mode sessions via IoCtl, and then changes layout for PM programs by calling of WinSetKbdLayout.
    Will WinSetKbdLayout work in your program without IoCtl prior it?

    --
    Yuri Proniakin


  14. Re: Codepage again...

    [A complimentary Cc of this posting was sent to
    Yuri Proniakin
    ], who wrote in article :
    > > Without a .lib or a known ordinal, even the existence of these API is
    > > very questionable... I would consider it as a misprint in
    > > documentation... ;-) :-(

    >
    > But layout files for this (sp) functions are there.


    How do you know that these functions are supposed to work with these files?

    > Anyway, I am interesting in API for this files


    How do you know the APIs in question are supposed to work with these
    files?

    > > How did you deduce this? Experiments?

    >
    > Disassembler :-))


    Using less brute force, the only file mentioning 'Language\keyboard'
    is unikbd.dll. Now it should be easy to find files using APIs from
    this DLL. None in my d:\os2 or d:\language... So my guess is that
    this directory is NOT used by OS/2 itself - only for use from
    applications...

    Hope this helps,
    Ilya

  15. Re: Codepage again...

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Rich Walsh
    ], who wrote in article :
    > > I think what we badly need is to agree on the name of the atom to
    > > denote clipboard format with Unicode-encoded clipboard text (e.g., via
    > > little-endian C shorts - probably the same as cp1208). Which one is
    > > Mozilla using?

    >
    > "text/unicode"


    Wow, this is was a clever decision... An obvious useful extrapolation
    would be

    "text/plain; charset=cp1004"

    > BTW... if the PM codepage for a message queue doesn't match the system CP,
    > PM will automatically do a codepage conversion before placing the text on
    > the clipboard (at least for Plain Text).


    This is lousy... And I wondered why when I cut-and-paste all I get is
    a series of question marks...

    BTW, what you described can't be true, since there is no such thing as
    "the system CP". A (very) few experiments I did suggest "the program
    CP". Is it what you meant?

    Thanks,
    Ilya

  16. Re: Codepage again...

    In article ,
    Aaron Lawrence wrote:

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

    >
    >MLM_QUERYFONT
    >
    >change FontInfo.usCodePage
    >
    >MLM_SETFONT


    OK.. thanks

    --
    bye
    Alessandro Cantatore
    email reply to: acantatore_at_tin_dot_it

  17. Getting to clipboard data

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Rich Walsh
    ], who wrote in article :
    > > I think what we badly need is to agree on the name of the atom to
    > > denote clipboard format with Unicode-encoded clipboard text (e.g., via
    > > little-endian C shorts - probably the same as cp1208). Which one is
    > > Mozilla using?

    >
    > "text/unicode"


    Drat, this one is not (obviously) 0-byte-terminated; probably (with
    the tools I have, it is a little bit tricky to examine such data)
    0-short terminated. Much harder to work with...

    But suppose I would not know it were 0-short terminated. Given a
    clipboard data of unknown format (with flag CFI_POINTER), is it
    possible to find the size of the (shared memory) segment which
    contains this data (e.g., to save the data, then vgrep the file and
    try to determine its actual format)?

    Thanks,
    Ilya

  18. Re: Codepage again...

    On Tue, 11 Jan 2005 00:19:21 UTC, Ilya Zakharevich wrote:

    > > > Without a .lib or a known ordinal, even the existence of these API is
    > > > very questionable... I would consider it as a misprint in
    > > > documentation... ;-) :-(

    > >
    > > But layout files for this (sp) functions are there.

    >
    > How do you know that these functions are supposed to work with these files?


    I do not know, I only suppose it (judging on the max. size of a layout name).

    > > Anyway, I am interesting in API for this files

    >
    > How do you know the APIs in question are supposed to work with these
    > files?


    It is "by definition". Because "API in question" = "API for these files" -
    it was in the continuation of my sentence, that is omitted in your quote.
    IOW, I am searching for any usable API for these files.

    > > > How did you deduce this? Experiments?

    > >
    > > Disassembler :-))

    >
    > Using less brute force, the only file mentioning 'Language\keyboard'
    > is unikbd.dll.


    This morning I was playing exactly with UniKbd functions.

    > Now it should be easy to find files using APIs from
    > this DLL. None in my d:\os2 or d:\language... So my guess is that
    > this directory is NOT used by OS/2 itself - only for use from
    > applications...


    Your guess is correct - I checked it many years ago (by renaming "\LANGUAGE").

    --
    Yuri Proniakin

  19. Re: Codepage again...

    On Tue, 11 Jan 2005 03:30:31 UTC, Ilya Zakharevich wrote:
    > Rich Walsh wrote in article :


    > > BTW... if the PM codepage for a message queue doesn't match the system CP,
    > > PM will automatically do a codepage conversion before placing the text on
    > > the clipboard (at least for Plain Text).

    >
    > This is lousy... And I wondered why when I cut-and-paste all I get is
    > a series of question marks...
    >
    > BTW, what you described can't be true, since there is no such thing as
    > "the system CP". A (very) few experiments I did suggest "the program
    > CP". Is it what you meant?


    By "system CP", I meant the first codepage listed in config.sys, i.e. the
    one that every program uses unless explicitly started under the alternate
    CP. WRT the clipboard, it would be more precise to say that text gets
    converted to pmshell's PM codepage, which under normal circumstances, is
    always the primary CP.


    --
    == == almost usable email address: rich AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | New - Remote Workplace Server v0.60
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws060.zip
    __________________________________________________ _________________

  20. Re: Codepage again...

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Rich Walsh
    ], who wrote in article :
    > > > BTW... if the PM codepage for a message queue doesn't match the system CP,
    > > > PM will automatically do a codepage conversion before placing the text on
    > > > the clipboard (at least for Plain Text).


    > By "system CP", I meant the first codepage listed in config.sys


    Well, what you say in the last paragraph does not look true on my
    system. But if "system CP" == "process CP", my experiments agree with
    your recipe:

    I start Mozilla, load a cyrillic page, select+COPY, and read the
    content of the CF_TEXT of the clipboard. On 850,866 system the
    content is "????? ???" (or somesuch) (real question marks) if
    process_CP of Mozilla is 850; the content is `expected Cyrillic in
    cp866' if process_CP is 866.

    What experiments did you do?

    Thanks,
    Ilya

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