GaryPJ

I know that I’m getting into the “This Guy’s a pest” territory here, but I just wanted to say that (as you undoubtedly know) that focusin and focusout should be used instead of focus and blur.
I had tried it both ways before I posted the code, but focusin and out seemed to work a little sluggishly…
I (now) think that that was because I had a bunch of apps and about 27 tabs open on the browser that I was testing the site on. I changed it back to focusin, focusout after closing the browser, installing some updates, rebooting and having a reasonable amount of memory being used by open applications, including just a few browser tabs.
I’ve been using it this way for a while now and it seems fine.
I also added some code to (conditionally) restart the slide show after it is paused, but I think that you probably want to leave that functionality for your paid version, so I won’t post it here (unless you ask me to).

Gary

Just one more small detail, especially considering your “on point” comments at line 1111 (LOL!); getting the keydown events is usually done like this:

// If here, OK to change slide if iPf is false
if ( ( e.keyCode || e.which ) == 39 && !iPf ) {
clickNextBind( e );
return false;
} else if ( ( e.keyCode || e.which ) == 37 && !iPf ) {
clickPrevBind( e );
return false;
}

“e.which” being the (now) preferred method, but (unfortunately) we still need to write code for “our dinosaur friend[s]”!

Gary

Jan,

Obviously I’m posting this for the plugin author; this line:

“Please check this and refine as needed, then minify it and include it in you next revision.”

at the end should make that completely clear, if it wasn’t before.

Doesn’t the plugin author have access to the emails of the people posting here? If not, I could tweet it to him if he wants it. In any event, I would never use a decent email account: I have free ones that get about 50,000 spams a day, a few more wouldn’t matter!

Gary

UPDATE:
Okay, I fixed it myself; here’s how:
1) I didn’t realize you were running a minified copy of the JavaScript. Changing keyCodes 37 to 38 and 39 to 40 in that file proved that the lines of code I mentioned were the problem.
2) Since the input boxes and text fields you were using as selectors are dynamically generated, they are not there when you try to bind to them. You must bind your event handlers to a parent of them that exists and use delegated event handling. So your if statement at line 326 was unable to find the input and text boxes you targeted, and (therefore) the left/right arrows stayed with the slider no matter where DOM focus was.
3)I’ll try to put the code here. If it fails to post or you have any questions, send me an email and I’ll provide it. Here goes:

(new) line 320: var iPf = 0;
(line 326 is now 327)
Get rid of the if statement on line 327.
Line 327: $( ‘body’ ).on(‘focus’, ‘input,textarea’, function(event){
Line 328: iPf = 1;
Line 329: });
Line 330: $( ‘body’ ).on(‘blur’, ‘input,textarea’, function(event){
Line 331: iPf = 0;
Line 332: });
Line 333: (blank line)
Line 334: // If here, OK to change slide if iPf is false
Line 335: if ( e.keyCode == 39 && !iPf ) {
Line 336 337 are unchanged.
Line 338: } else if ( e.keyCode == 37 && !iPf ) {
Subsequent lines are unchanged.

I tested these changes and they allow traversing input boxes and text areas in my contact forms and on all of the fields of a JavaScript calculator on the development site test page with the arrow keys.
Please check this and refine as needed, then minify it and include it in you next revision.

Gary