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

[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

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

[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

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

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

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

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

[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

[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

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

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

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

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

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

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

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

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

[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