That is one problem with the autocomplete control but unless you are running the november CU and FP3 the control wont bring data back to the form or validate that the data is correct when entering. I had tickets open on this and the fixes are in those releases.

With that said if you have a large group set you cannot do much about the load time but unless this is the very first or only field you could move the populate rule to the Initialized rule. This runs after the form initalizes so the user can use the form. You could also populate it later on a change rule. It does not fix the problem but it makes it less aparent. The other ideas would be is it absolutely necessary to pick from all 20K or could it be filtered somehow?

This might not help but may give you some ideas.

Hey Micki,

Thanks for your reply.

I got K2 support in on this, but we weren't able to improve the time.

I'm on the Feb CU.

The AD Group only has 2000 users, which is small really, but no matter how much of a delay or trigger setting we used, there was still a 4 second delay in it displaying any results.

We disabled the initialize rule to speed up the form load time (was 10 seconds), but then doing a Live Search, it's taking 4 seconds to return a result, which just isn''t acceptable. The user would think nothing is happening and type another letter, in which case the search would start again.

I'm always about giving the user the best UI experince, and the Autocomplete control would have been just that, but in reality it's too slow to be practically useful.

No way round it I was told, so back to the horrible Picker control.

When you're up against smart .Net forms with instant and seemless autocomplete, K2 is left in the dust.

Either way, the speed up has been added as a Feature request, so lets wait and see.

P.S. I don't suppose there is a way of embedding .net User Lookups within a K2 Form is there? If so, i could use .Net for the Autocomplete User lookup part????