hi dan, thanks for your answer.
i'm logging the keydown event on the input in the plugin autocomplete. the keydown is there to react to movement, return and delete, and in the default condition it may check for eventual changes in the input field. but, pressing of a hebrew character immediately after the keymap switching with alt-shift (which is itself captured by keydown as alt) is not getting in keydown at all, however it changed the field value. anyway, the keyCode of hebrew chars in keydown is always 0. i will try to move handling of non movement keypresses in keypress, and soon report. best regards, alex On Sun, Oct 19, 2008 at 15:47, Dan Switzer <[EMAIL PROTECTED]> wrote: > Alex, > > What keyboard event are you logging? Some events are only captured by a > keypress event and will be ignored by the keydown event. > > -Dan > > On Sun, Oct 19, 2008 at 5:12 AM, alex bodnaru <[EMAIL PROTECTED]> > wrote: >> >> hello friends, >> >> i ran into a corner case with jquery autocomplete which i'd like to >> seek a solution for: >> >> my system is bilingual (en-he) gnome debian linux, with firefox 3.0.3. >> >> with focus on an autocomplete field, i'm switching the keymap to >> hebrew, using alt-shift. logging the event keyCode to the firebug >> console, i get one 18 value, followed sometimes by a 0 additional >> event. >> >> the next character i'm typing into the field is being shown, but does >> not trigger a keycode event, hence the autocompletion doesn't react. >> this doesn't happen when i switch the language to english, probably >> because ascii characters have non-zero keyCodes. >> >> but the following character i'm typing acts ok. no, this is not >> because minChars. >> >> i assume that the alt-shift is leaving the event manager in an >> ambiguous state, which invalidates an unicode char, but is being later >> cleaned by typing another char, or bksp/del. >> >> could you help? >> >> best regards, >> alex > >
