Problems with Greek accented characters

Report · Jun 11, 2010

After the update to AIR 2.0.2 I cannot input into any application greek with accented characters.

Tried TweetDeck and Twhirl and neither work (used to before the update)

Is this a bug or it needs some configuration

I am working on Fedora13 but heard the same problem reported on Ubuntu.

Have not tried on MS Windows or MacOSX

Report · Jun 11, 2010

Hi akoukoulis

We are aware of the issue, and are working to get it fixed.

-Thanks

Sundeep

AIR Team

Report · Jul 08, 2010

Any news on this bug?

This affects too the Spanish-writing apps, and writing without accents and ñ is unacceptable.

Report · Jul 14, 2010

The bug will be fixed in AIR 2.0.3.

Report · Jul 15, 2010

Thank you for the reply.

Is there any plan of when the Adobe Air update will be released ?

Report · Aug 10, 2010

Hi akoukoulis

AIR 2.0.3 is live now, it fixes the issues with accented characters on Linux. Please grab it from:

http://get.adobe.com/air/

-Thanks

Sundeep

Report · Aug 11, 2010

Moved discussion to the Problems & Bugs forum

Report · Aug 20, 2010

Hi,

Seems the same problem is with polish letter ż (small z with dot above) or Ż (capital Z with dot above). The problem occurs in AIR 2.0.2 and the latest 2.0.3 version.

Could you take a look at this ? Unable to input those characters makes application difficult to use.

Kind regards.

Report · Aug 23, 2010

Hi,

We can input both characters (ż and Ż) here. Could you please check if you can input them in native Linux apps like gedit? If yes, can you please share with us your sample source code?

Besides, to input the charaters above, you need to set Compose Key Position in Linux. Instruction page for your reference http://stefaanlippens.net/accented-characters-on-qwerty-keyboard.

Thanks,

Grace

Report · Aug 23, 2010

Hi,

I'm using Adobe AIR 2.0.3 on Windows machine. I wrote an app in Aptana Studio (build: 2.0.5.1278522500) with ExtJS library and I found the problem with polish national characters like ż and Ż (all the other national characters like ą, ę, ń are possible to input).

In order to reproduce, here you have the sample code in ExtJS:

http://dev.sencha.com/deploy/dev/examples/form/anchoring.html

As you will see - it is possible to input ż and Ż in text fields.

Now, use the same code to build AIR applicaton and then run the application. It is not possible to input those characters in Air window. Right Alt+z acts like undo operation - it removes last entered text. All the other characters work fine.

Here is the code I used:

<html>
    <head>
        <title>New Adobe AIR Project</title>
        <link rel="stylesheet" type="text/css" href="lib/ext/resources/css/ext-all.css" />
        <link rel="stylesheet" type="text/css" href="lib/ext/air/resources/ext-air.css" />
        <script type="text/javascript" src="lib/air/AIRAliases.js"></script>

        items: [{
            fieldLabel: 'Send To',
            name: 'to',
            anchor:'100%' // anchor width by percentage
        },{
            fieldLabel: 'Subject',
            name: 'subject',
            anchor: '100%' // anchor width by percentage
        }, {
            xtype: 'textarea',
            hideLabel: true,
            name: 'msg',
            anchor: '100% -53' // anchor width by percentage and height by raw adjustment
        }]
    });

    var window = new Ext.Window({
        title: 'Resize Me',
        width: 500,
        height:300,
        minWidth: 300,
        minHeight: 200,
        layout: 'fit',
        plain:true,
        bodyStyle:'padding:5px;',
        buttonAlign:'center',
        items: form,

        buttons: [{
            text: 'Send'
        },{
            text: 'Cancel'
        }]
    });

    window.show();
            });
        </script>
    </head>
    <body>
    </body>
</html>

Is it possible to input those characters or is there a workaround for this (disable undo operation or so) ?

I really appreciate any help.

Kind regards,

Marcin.

Report · Aug 24, 2010

I've already let Marcin know the status of this issue, but others following along, we've verified this bug and added an internal report (#2699774) in our bug database.

Thanks,

Chris