Thank you Viktor. Im mainly using it on the login page.

Hi cperez,

I forgot to mention that most browsers do not raise keypress for actions keys like enter, esc, arrows, tab, etc.

If application is interested in processing action key events, then it should listen to keydown. Also if your application does not rely on default submit of browser on enter key, but it does all processing by itself, then there is not need to disable hideEnterKey option. The igEditor raises all browser events regardless if they are canceled by igEditor or not.

$(document).delegate("#UserName", "igtexteditorkeydown", function (evt, ui) {
 if (ui.key == 13)
  alert('enter');
});

Hi cperez,

The igEditor has option hideEnterKey, which by default is enabled. That option was designed for opposite scenario: suppress possible default postback of a browser when editor had focus and enter key was pressed. That allows to select item from drop-down list by keyboard without mouse, select date in calendar of datepicker, etc.

Processing key events by application will not be able to "undo" the  default stop/cancel action used by igEditor. That includes enter key. In fact, custom action might have opposite effect. If application returns false within key event-handler, then igEditor stops/cancels original event of browser and does not do its default process-key-action.

You may disable that option by
$('#editor1').igEditor({ hideEnterKey: false, ...});
In case of Mvc
<%= Html.Infragistics().TextEditorFor(m => Model.Editor1).HideEnterKey(false).Render() %>