Currently I have an EnumList column that sometimes have more than 1000 suggested values. If the user hits “Select All”, the app would be unresponsive.
Is it possible to enhance the performance of this situation so that the app won’t be unresponsive.
You may want to further detail out your requirement.
Do you wish user to be able to select all those 1000 values or do you wish the user to be not able to select all when there are such a high number of enumlist values. If you do not wish the user to select such a high number of values, how many maximum values at a time you would like the user to select.
Also if possible you may want to share more about your use case where such a high number of options are required so that the community could suggest better ways if possible to achieve the said functionality.
The sample I have is only 950 not yet 1000, but the current enumlist is still running smoothly and without any problems.
Good point @Syamsudin
@ralph.christian , I could also select as many as 2007 values when selected from a suggested values expression drawn from another table using a Table_name[Player_Name] expression.
The player names are from soccer world cups database from the past and as such a public database uploaded on Kaggle site. This database I use to test when the use case needs to test on a fairly large number of records, The database has 37 K + records.
So it may be still more useful or necessary to share your implementation because under typical selection pattern the selections are going through for 1000 + selections.
Hello, upon checking, it seems I underestimated the number of items. It was actually around 9400 records.
I also took another look at it, and the worst case scenario is actually 170,000 items (although we definitely do not want this to happen.)
I am thinking it’d be best if the user can only select 100 items at a time (I still need to discuss with the team for the actual number but 100 seems good enough to start with). If the user chose more than 100, an error should say that they should not be able to select more than 100 items.
Additionally, in the scenario where the choices is too abundant, if the user hits Select All, the app shouldn’t crash/be unresponsive. The best case would be to remove the Select All button if there’s more than 100 items available; only show it if they narrow down the list.
Additional details: I will actually pair this up with Adding rows to another table, one for each item in this enumlist. So I have to limit the number of items because it might cause more performance issues.
Thank you for all the additional details. To start with, it sounds that your requirement is a bit unusual. To allow user to select from such a massive list is a bit unusual. Please evaluate if you can shorten the choices by further dividing the choices in steps. For example if inventory of engineering components is to be selected , you may first give the user to select mechanical, electrical, civil , then within mechanical , there could be further choices such as milling machine, grinding machine and so on.
Please explore if you can use the dependent dropdown approach described in the help article Dependent Dropdowns
Anyway for your current configuration, you could try the following workaround.
To hide “Select All” option, please have the expression something like below in the localization section.
IF(CONTEXT(“View”)=“Your Form view Name”, “”,“Select All”)
Please replace form view name with the actual form view name you will have.
Please note that this merely hides the display of the “Select all” option and replaces it with a space or blank. So, a very small area equivalent to a single space area still remain active in the enumlist selection panel. if the user hovers over that active area and clicks, the select all will still become active. However such probability is very less.
In the valid_if of the enumlist column please have an expression something like
COUNT([_THIS])<=100
This will disallow more than 100 selections by the user.
Your valid_If error message could be “Select maximum 100 or less values.”
However user interface for this will not be very intuitive as user also may need a real time feedback on how many options she/he has selected, which I believe is not very easily possible to be displayed with the current user interface.
You could initially alert the user with a display name for the column such as
IF(CONTEXT(“ViewType”)= “Form”, CONCATENATE(“Select options (Max 100)”, “Currently selected(”, COUNT([_THIS]),“)”), “Options selected”)
Thank you for the suggestions. I agree that my request is a bit unusual and would explore if I could shorten the choices in some way which would solve all my problems to be honest.
I also had another idea (I might do another post if necessary), is it possible for the user to paste a list of items (e.g., item_1, item_2, item_3, …, item_4) or upload a csv file, or something of the sorts and then the app stores the values in an EnumList?
I am afraid this is not easily possible. If the list of multiple items is pasted in an enumlist column, it will be considered as a separate single option by the enumlist. So if you paste item_1, item_2, item_3, item_4, it will start showing up together as an additional enumlist option. This means the list will NOT be bifurcated to individually select each of the items in the enumlist.
In general, this could be possible. However, you will need to build a proper workflow for user interaction to ensure this can happen. CSV upload is possible through an action, so you may need to do it through a summary view. You will also need to ensure other columns are not incorrectly impacted due to CSV upload.
Yet another option is to upload the list into a user table. There can be a column in the user table to upload the list in a text column. You could then use reference action to upload the list in the intended row of the table where the enumlist column is there. However here also you will need to be careful that the spelling of each item is correct. So if instead of Item_1 if the user enters Items_1, it should be disallowed through a proper valid_if etc.
I suggest you confirm this. My expectation is that if the user-entered list uses the separator the EnumList column uses, the input items will be treated as individual items once the input is saved.
Oh yes, you are correct Steve. Sorry, it was my bad to not have carried the testing totally to the end of saving and rechecking.
Thank you for correcting this oversight. 