This is similar to This Post but it did not solve my problem. I have V2024 and wish to allow my users to use the keyboard for grid entry. If I have a lookup field with display 1 = link (UserID), it works perfectly to advance using down arrow to select and tab or enter to accept or typing in the whole field and just pressing tab. Very fast data entry!.
But! If I have display 2 (First Name) and display 3 (Last Name), it fails with the browser indicating “Value does not exist” in small red below the box. It is as if it is trying to compare the lookup list allowable links to the browser field (which includes 2 display entries).
If I click on the desired item instead of arrow down and enter/tab, it works perfectly.
Edit Tag Config:
Custom Attributes : ["onkeyup" => "this.value = this.value.toUpperCase();"]
Use Lookup Table and Force Selection checked
Lookup Table Config:
Link field = Display field 1
Display fields 2 and 3 are other varchar fields in table
Order by is another field in the table
Sort ASC
I have tried many, many combos of the configuration and this is closest (and rational). I’m really hoping it is possible ‘cause the extra two fields are extremely helpful to make sure the operator selects the correct UserID!
If you use native HTML <select> element, keyboard selection works by matching the beginning of option text. That is default browser behavior. If you Select2 without search box, Select2 also search from the beginning.
Enable Auto-Suggest all display fields - If this setting is enabled, Auto-Suggest finds records with Display field#1 to #4 that CONTAINS the input characters
Thank you for a very detailed description of many options. Unfortunately, I wasn’t able to get it to work yet from your suggestions (particularly alternate 2 (AutoSuggest). As my original post wasn’t very organised in describing my setup or problem, let me try to be more concise and complete.
Edit tag (Text):
Custom attributes: ["onkeyup" => "this.value = this.value.toUpperCase();"] This is required because the database has upper case values only and I want the data entry to be case insensitive.
Use lookup table: checked
Force Selection: checked
all else default/blank/unchecked
Lookup table
Display field #1 = Link field
Order by: ASC
Filter: > 0 (note filter field is not the link field or a display field)
Relevant advanced settings
Auto-Suggest all display fields: unchecked
Use Ajax actions (list page): checked
Use native SELECT…: unchecked
This setup works perfectly and meets my needs. It gives me at least 3 ways to enter data:
type in value completely and leave field (tab, enter followed by left or right arrow or click in other field)
type in partial and click on a suggestion
type in partial and arrow down to a suggestion then press enter
My problem is that if I add a Display#2to the lookup (no other change), it ceases to allow data entry by method 1, showing the “Value does not exist” in small red letters below the text entry box. This requires the data entry to require a mouse click or using the arrow keys. This is crippling to the speed of a skilled data entry person.
I have noticed “fragility” of the auto suggest. I have two fields configured identically and one works and the other doesn’t (doesn’t ever match). I’m guessing that this might be cache related so I will now look at wiping out cache. I always log out before generating then log back in when the generation (always full) is complete but perhaps that does not clear caches.
There are soooo many configuration items related to this and only brief explanations with (usually) incomplete warnings of side effects. I’ve been really trying but for me to try every combination would be impractical. I’m amazed I have managed to figure out the scenario when a single change (adding display #2) causes it to fail. Now I just have to get it to work.
So, simply, can you think of any reason why it works perfectly until I add a second display value?
ALERT! Might have some insight but no solution yet. I’m pretty sure now that the way a text field using auto suggest is validated is to compare it against the ENTIRE entry in the suggestion (i.e. Display #1-4 with separators as appropriate). When you click on an auto suggest entry in the suggestion list, the entire entry (Display #1-4 as appropriate) is copied to the text field.
When there is no #2,3 or 4, the text field is compared to the display #1 field which is the link field and it compares perfectly to the link field alone (caching problems aside). When there is a #2, 3 or 4, the operator never types that in so when tabbing out of the text field it is “incomplete” and the link field alone doesn’t match any suggestion.
So, assuming I’m right, I have to intervene to make it compare.
Using custom attributes I could copy the top suggestion to the text buffer when I press enter or leave the field. If so, I would need the names of fields (e.g. top of suggestion list) and I would need the trigger (loss of focus? certain key presses?)
Should I be using customValidate in the client? If so, what are the field and suggestion entry names?
I like custom attribute because it keeps the entire config in one place. Is there a better idea like limiting the compare to characters before the first “,” somehow?
On blur of the data entry field, IF the field value has no separators (‘,’) and the top entry in the autosuggest list is not blank, trigger an autocomplete of the autosuggest list first element.
I believe this would do exactly as I want. When I leave the field it would only fill if it isn’t already filled (separator), and there is a suggestion (i.e. there is a partial user entry and it is a valid match to some autosuggest data).
Now that i have simplified the actions, I need some help with the implementation.
I would like the event handler hook to be in custom attributes of the edit tag (which is “closest” to the configuration for a tag.
The event handler code should have nothing hardcoded (field name etc.) so I don’t have to custom edit the code for every instance of this type of lookup field. This code could be in the custom attributes (preferred) or global code for client.
I also want it to work with add and gridadd. Therefore the tagname cannot be in the code as the tag name would change from #x_ to #x_field
I believe the event handler hook is pretty simple (an on blur calling the event handler code) and can go in the custom attributes.
I’m stuck or the event handler code (particularly given the constraint of grid add above). I’m also unsure if I timing will be an issue (must complete before the field validation, must take action before the autosuggest list is gone etc.).
Please offer me any cautions based on my strategy, any suggestions for improvement or simplification and any code snippets you might suggest. With this, data entry will be FAR faster.
I am looking to autocomplete the data entry from the top autosuggest text of an (add or edit with or without grid) field on blur. This will radically speed up manual data entry for fields that have display #2 fields or more as mentioned above.
I am having incredible difficulty getting access to a select2 autosuggest list in js or jQuery. I have tried using #x_<fieldname>, #as_x_<fieldname>, #sv_x_<fieldname_listbox> and a whole bunch more. They all complain they are an element “not using Select2”.
Please help me to find the select2 object(s) that I need to continue my quest for fast data entry!
Yes. The problem is that it was hard to Inspect when right clicking caused loss of focus and wiped out the list. Ended up using Chrome and More Tools/Rendering/Emulate a focused page and that worked great.
THAT’S THE WINNER!!! It now seems obvious but a lot led me to go down the Select2 path. I now have this phenomenal change ready for testing. Here are the details:
After setting up the field for autosuggest (Use lookup table, Force selection), add this to Custom attibutes for the edit tag: [“onkeydown” => “ttDataEntry(event);”]
add the following code to Client Scripts/Global/Pages with header/footer/Global Code
function ttDataEntry(event) {
if (event.which == 9) //9 is tab
$('.tt-selectable').first().trigger('click');
}
This will select the top entry of the list when tabbing out of the entry field. If no entry exists,
I have tried this with success but I wonder how robust it is. Can anyone see a weakness with this solution? If not, this seems to be awesome in improving data entry speed!!
My endless appreciation to arbei who has been so helpful in this and my other issues on this massive improvement project of mine! The users may not realize, but they thank you as well.
Better avoid inline script, you may try jQuery .on() in Startup Script, e.g. you may try something like (pseudo code only, you need to modify as needed)
$("form").on("keydown", "#sv_myfield", function( event ) {
// Your code
});
// OR
$("#sv_myfield").on("keydown", function( event ) {
// Your code
});
Using the custom attributes method means any additional fields (even on other tables) takes place in one, identical line on the edit tag config. The method you mention would require me to configure in two places (edit tag config and Startup Script). I can see them getting out of sync (e.g. forgot to put the .on() in the startup script or forgot to remove it when I remove the field or autosuggest. I strongly value the containment of the way I tried it but if it affects performance,reliability, protection from edits required in due to future releases, good practice or anything else I haven’t considered, I humbly ask for you to let me know what I didn’t think of.
As usual, any help would be very much appreciated.
Avoiding inline scripts prevents Cross-Site Scripting (XSS) by stopping the browser from executing code embedded directly in your HTML. A strict Content Security Policy (CSP) enforces this by only trusting scripts from verified external files or those validated with a cryptographic nonce.
To improve the maintainablility as mentioned above yet still avoid inline code, I had an idea. I will try to add a custom attribute (e.g. ‘tabcomplete’) to those fields which need this behaviour and in the startup script I can iterate through all elements to find those with ‘tabcomplete’ and register the callback. That leaves all the code protected and means I only have to add one, simple attribute for each autosuggest requiring it.
I thought it valuable to put my finished code here.
In Client Scripts|Global|StartupScript:
// Add callback for autocomplete if any data-autocomplete elements exist
//NOTE: the callback is tied to document keydown instead of each
//tt-input because the tt-input is destroyed and recreated every
//time the page is submitted and this would lose the callback
$(document).ready(function() {
if (document.querySelector(".tt-input[data-autocomplete]") != null)
document.addEventListener('keydown', ttDataEntry);
});
In Client Scripts|Global|Global Code:
// ttDataEntry()
// This routine is used for a twitter typeahead used in autosuggest lookup field
// When a character is received, we check if it is a finalization character
// which includes return and tab. If it is, we choose the first option of the
// autosuggest (tt-selectable class)
function ttDataEntry(event) {
const targetElement = event.target;
if(targetElement.hasAttribute('data-autocomplete') && (event.code == 'Tab' || event.code == 'Enter'))
{
const firstSelection = targetElement.parentElement.querySelector(".tt-selectable");
$(firstSelection).trigger('click');
}
}
Finally, add the custom attribute ["data-autocomplete" => "1"] to your Input tag.
This avoids inline scripts. I used the same structure for toUpperCase() !!!BUT!!! this fails if I use both on the same element on a page with multiple such fields (can’t figure out why). It is also not necessary as twitter typeahead does a case insensitive compare so only the data entry display shows lower case (though when the field is validated it used the database value/case as desired)
So at long last, I have my desired data entry speedup AND I didn’t leave myself vulnerable with inline code.