Thank you John for your reply, very interesting.
but I have only one objection to your explanation: why pressing the same key, the edit mask control in a window, have different behavior than an edit mask column in datawindow.

Depending on the individual, it may be difficult to nearly impossible to explain this behavior to a customer/user. Maybe, just maybe, the following will help:

Each physical key in a keyboard produces a unique scan code (an ID number) that identifies which key is pressed/released. The label on the surface of the key does not matter. To illustrate this point, imagine if you removed, swapped and re-installed the "3" and "7" keys and then pressed the key to the immediate right of the "2" key (now labeled as "7"), the scan code for the physical "3" key will be transmitted, not the scan code for the physical "7" key.

Because they are different keys, the period/dot key position in the regular portion of the keyboard transmits a different scan code from the period/dot key in the keypad portion of the keyboard. They are not the same, even if the key shows the same symbol on its surface.

The hardware device driver for the keyboard translates these scan codes into virtual key codes (a different ID number, one that Windows expects to receive) before it notifies the Windows operating system. Because the scan codes are not the same, the virtual key code for the period/dot key in the regular portion of the keyboard differs from the period/dot key in the keypad portion of the keyboard.

When regional localization is being used, Windows substitutes virtual key codes as needed. For example, with European localization, the numeric keypad period/dot virtual key code gets swapped for the comma's virtual key code, even though the label on the surface of the key shows a period/dot. Remember, how the key is labeled makes no difference, what matters is the scan code of the physical key. Windows then places a "key down" event message on the active thread's message queue, passing it the (changed, localization-swapped) virtual key code.

The application software then decides how to interpret the virtual key code in the "key down" event message. PowerBuilder, and applications created with PowerBuilder, "see" a comma, so a comma is produced. This is how PB works "under the covers", and developers cannot change this behavior. MS Word apparently does something different. Neither app is incorrect, per se... they each work the way there have been designed to work.

Conclusion: If the customer wants to input a period in any PB application when European localization is being used, they must press the period key that resides in the regular portion of the keyboard (the one highlighted in the keyboard diagram in my previous reply).

Here is a link that describes most of this in a little more detail:

    https://learn.microsoft.com/en-us/windows/win32/inputdev/about-keyboard-input

Good luck with helping your customer understand this.

Best regards, John

I did as he said and indeed the results are different.

Using the EDIT MASK CONTROL it works correctly. Instead, the comma appears in the edit control using datawindow, as shown in the image below.

Think that customer demand is similar to yours. Why does a COMMAappear if I type the DOT in the numeric keypad, instead of typing what you have highlighted a DOT appears? a dot is drawn on both keys, but as you type, different things come out.
I would say that this is still a clear proof that Italians are artists, right?

Dearest John, you are not wrong: the problem is not me but the customers.

I could be wrong, but I believe that as long as you use the numeric-keypad "dot" key to input a (text) period under your conditions, this is the behavior that will result when using a PowerBuilder application.

According to Wikipedia, the layout for an Italian keyboard is shown below. Why can you not use the (text) period (highlighted) to input a period?

Thank you John,

the problem is that also in an edit column the comma appears.

Hi, Enrico -

Please keep in mind that Miscrosoft Word and Appeon PowerBuilder are completely different products, designed and used for two different purposes. I do not believe it is reasonable to expect these apps to perform in the same manner.

That being said, the Help topic for the KeyDown PowerScript function shows that the virtual key designation for the "dot" key on the numeric keypad portion of a keyboard is recognized/named "KeyDecimal!", where as the "dot" key located in the main area of the keyboard is "KeyPeriod!". The localization performed by the Windows O/S may also be a factor here. This may help to explain the behavior you're experiencing.

Best regards, John

Attached the image of the italian keypad.

You can see that we have a DOT; may be yuo have a COMMA?

So the problem is that when i press the DOT in PB a comma appears :(

Hi Enrico.

We in Germany use a comma as decimal separator and AFAIK it is the same in Italy.

If I type the decimal separator (comma) on my num pad it writes a comma in PB and also in Word.