List view editing loosing focus

[TriffidGirl]

Hi,

I don't know if anyone can help, but I have an issue with the cusor not going where I expect it to in a list. I have a list control and have created 2 javascript fields in it that enable the user to edit the contents of the list directly. Now when the user tabs from one field to the next the onChange event triggers and that calls the lists updateTableRow method. This is removeing the focus from the list/form rather than moving the cursor to the next box. In some instances (this isn't consistent) it results in the user having to hit the tab key 11 times to end up where they need to be (in the next input box). I know it is the updateTableRow method that is doing this as when I comment that it it tabs beautifully.

Things I have tried:-

• passing the optional setting of setFocustToTargetRow()
• using the {dialogue,object}.setFocus(fieldname_rownumber); as this is the generated id in the javascript field object I have created
• setting the setFocus in a number of places including the updateTable event in the list;
• the onChange event on the input box;
• the afterUpdateList event on the List
• removed references to the list data in the javascript
• jumping up and down

Removing the second input box does resolve the issue, but this isn't an option in reality. So my question is does anyone have any ideas how to force the cursor to be in the next input box?

Yours hopefully
Georgina

P.S. I have (once again) posted this in the wrong place. I am really sorry I will try to post in the right place next time. Please move this to Alpha Anywhere (Version 12) mobile and browser applications.

[Davidk]

Re: List view editing loosing focus

The over issue with "features" like the Javascript Control Type is that they are never fully tested... and generally abandoned. Alpha's philosophy is to rely heavily on developers to debug Alpha features. This is a perfect example.

The use of the Alpha setFocus can't work because it's operating on a unique UX control... and not a Javascript created List field.

I'm going to guess that after your updateTableRow has run... that you are also running a .saveListEdits. Is this correct?
I'm also going to guess that the html for your Javascript field is where you have your "onchange" event running... and this runs a Javascript function.

What you need to do is set focus to the input div of your 2nd Javascript field... but after the updates and saves have completed for your 1st Javascript field.

In your onchange Javascript function of your 1st Javascript field, add this after your updateTableRow and saveListEdits...

	setTimeout(function(){
		$('QuantityInput_'+rowNumber).focus();
	},500);

QuantityInput_ is the first part of my 2nd Javascript field div id. Replace this with your own div id.
The setTimeout gives updateTableRow and saveListEdits time to settle down before you set focus to your 2nd Javascript field.

I've only tested this under current Chrome.

[jgrannis]

Re: List view editing loosing focus

I could take a few guesses but as I sit here thinking about what might be going on, I have doubts about whether such or such events occur in such or such situations. For example, does the updateTableRow always - in all cases and configurations - eventually trigger a complete list redraw?

I personally would take a few minutes and add a 'console.log("[listname]\'s x event has fired")'. And copy that into every single list/list detail view event. Of course, replace the x by each event name.

Then, when looking at the console in Chrome DevTools for example, you get a good idea of what is happening and in what order. It really helps me to understand what is happening instead of guessing. I have even added the same type of logging to all the dialog's client-side events. For instance, in those events, if you log it, do you see anything getting fired off in terms of events such as: onControlFocus, onControlBlur, onControlChange, ....? Also, console.log out some of the parameters associated with each event. For example, onControlBlur has e.controlName and e.sourceElement available. If you log that but don't see any logged e.controlName, maybe it isn't really a control for Alpha. Yes, the browser will tab to the next HTML input element but, after an updateTableRow, does the Alpha code have some state variable to remember which is the next "control" that it should give focus to?

[RichCPT]

Re: List view editing loosing focus

I hope the idea of constantly saving changes is something that Alpha will tackle this year. It seems to be the way everything is going, as demonstrated by Google Docs, Google Sheets and a ton of other web (and desktop) apps.

I put that concept of constantly saving LIST data into my Detail View for a LIST, but my trigger points are when user navigates to a different row or when X number of seconds have passed. This is for a connected app, so I'm saving the changes to the server. If I had a disconnected app I'd experiment with saving to local storage.

Anyway, I spent a fair amount of time going through every line of AA Javascript involved in this process.
And, all I can say is that the LIST does NOT like doing this - constantly saving to the server based on triggers we put into the code!
It is constantly messing up!

[TriffidGirl]

Re: List view editing loosing focus

Thank you Jeff for you advice on logging - without these tools us developers are helpless.

Thank you Rich for your response I know I am not the only one going crazy with Lists.

A big thank you David your solution worked a treat. I wasn't doing the .saveListEdits as I was aware that this would make the issue worse. I am makeing the user save after all the edits have been done. This is great as it means that we can develop the screens the user wants, rather than one that is a compromise.

Many thanks
Georgina

[Davidk]

Re: List view editing loosing focus

Glad it worked out for you. There is a lot going on with the List Control and, in general, it's all ok. When you get into some custom behaviours I believe many potential issues are usually timing related. This is particularly true when dealing with List updates and server syncs.