performance with large items select in element ui ? - element-ui

I have 3000 items I used Element UI select but it very slow with large Select Lists, any help

You should take a look at remote search feature.Where user can enter keywords and search data from server accordingly
see the docs

Related

Is there any easy way of making able to select from DBGrid?

Is there any easy way of making able to select from DBGrid just like selecting range in excell file?
http://docwiki.embarcadero.com/Libraries/XE5/en/Vcl.DBGrids.TDBGridOption
http://docwiki.embarcadero.com/Libraries/XE5/en/Vcl.DBGrids.TDBGrid.SelectedRows
http://docwiki.embarcadero.com/Libraries/XE5/en/Vcl.DBGrids.TCustomDBGrid.SelectedField
http://docwiki.embarcadero.com/Libraries/XE5/en/Vcl.DBGrids.TCustomDBGrid.SelectedIndex
It seems you can have any number of ROWS selected using dgMultiSelect option.
However for the columns your choice is between select nothing, select single, or select the whole row (using dgRowSelect) and there is no option to select few of those.
I think you'd try your chances using VirtualTreeView in Report (ListView) mode, though it would need wrting some code

Looping through rows

I have an app that displays a number of rows of products. Right now it's hardcoded to use three html rows. I really want to build a template for one row, and loop through and populate as many as I need to show up. I was thinking this is a job for Web UI loops (think fruitsearch example). Or do I want to build the template and make it a web component and pass my data to that? I'm really not sure what the best structure is here. This is a bit of an open-ended question, but what's the ideal structure for populating multiple rows of data?
Use Web Components when you need re-usability, or if your rows have complex logic or layout associated with them.
Given your description of "rows of products" I would use a Web Component for each product row and possibly another Web Component to keep track of all the product rows. For instance, if this is a product search result page, the SearchResultComponent could have a title, a list of ProductRowComponents and the number of results found, and each ProductRowComponent could have a name, a price and an image.
This would make it easier to handle the complexity involved as well as allow re-usability (i.e. using multiple ProductRowComponents).

Automatically updating Data Validation lists based on user input

I have a very large data set (about 16k rows). I have 10 higher level blocks and within each block I have 4 categories (10 rows for each) which use Data Validation lists to show items available in each category. The lists should automatically update based on user input. What I need your help with is that I want to use the same data set for each block and preferably a least calculation/size intensive approach. I have put together a sample file that outlines the issue with examples.
Sample File
Thank you for your help in advance.
Okay, I've found something, but it can be quite time consuming to do.
Select each range of cells. For instance, for the first one, select B3:B18 and right click on the selection. Find 'Name a Range..." and give it the name "_FIN_CNY". Repeat for all the other ranges, changing the name where necessary.
Select the first range of cells to get the data validation, and click on "Data validation", pick the option "Allow: List" (you already have it) and then in the source, put the formula:
=INDIRECT($G$4&"_CNY")
$G$4 is where the user will input. This changes as you change blocks.
_CNY is the category. Change it to _CNY2 for the second category.
Click "OK" and this should be it. Repeat for the other categories.
I have put an updated file on dropbox where you can see I already did it for the data of _FIN for categories CNY, CNY2 and INT and did the one for _GER as well. You'll notice the category of INT for _GER doesn't work, that's because the Named Range _GER_INT doesn't exist yet.

Combo box that can open quickly with lots of items

I've got a custom combo box descended from DevExpress's TdxfCustomComboBox. It works really well in most cases... and then I got a report from a client that when they try to open it it takes 3 seconds for the popup to appear. After a bit of investigation, I found out that that's because their database has about 12000 items that it's trying to populate, and it recreates the popup window and populates it each time.
This means that StdCtrls.TListBoxStrings.Add, which contains this line, gets called 12000+ times, once for each string.
SendMessage(ListBox.Handle, LB_ADDSTRING, 0, Longint(PChar(S)));
Processing this line requires several trips through multiple layers of message handlers and really bogs things down. I find this kind of silly since only about a dozen or so items are actually displayed in the popup window at once anyway. Does anyone know of a combo box control that doesn't require this sort of pre-loading and can scale?
EDIT: Unfortunately, making it not load 12,000 items is not an option here. The number of items in the combo box is based on the number of items in the database, and they all have to be available. Neither is making it into something other than a combo box. Not enough screen real estate for that.
the best solution that I can think of is using a TButtonEdit and when you click on the button a TVirtualStringTree(which is lightning fast) will popup containing the items, whenever the user clicks on a item the popup will close and the selected item will be displayed in the TButtonEdit's text property -- this can be achieved in a matter of minutes(5-10)
Another possibility: can you create the combo box at start-up and keep it around, reparenting it when you need it on this form?
Failing that, could you load the strings into another string list and .Assign to the combo box as necessary? (I'm not familiar with TListBoxStrings.)
Some options.
1./ Do you really have to populate with 12,000 items? can you use some filtering scheme and only return a subset of that data?
2./ Do you have to use a Combo box? do you have the screen real estate to use a virtual list view instead? (handle the storage and paging yourself)
3./ Create your own Virtual combo box...model the virtualization techniques on the virtual list view.
4./ Cheat...rather than a combo box, use a edit box with a "browse" button that opens a list that you can fill dynamically.
As far as I know there is no mode that lets you do this already with the dev express (or native) combo boxes.
ComboBoxes and ListViews experience performance degradation on an exponential curve, becoming really bad with thousands of items. Use Virtual lists whenever possible, if you have more than a few thousand.
Maybe you can use a LookupComboBox (also from DevExpress). Here you can load the data into a single DataSet where the Comboboxs are refering to it.
Honestly, three seconds sounds pretty good for loading 12000 records into a control like that.
Does the drop-down have to descend from TdxfCustomComboBox? I think you'd be better off rolling your own combo-box-like control here that would page through an associated dataset as required rather than pre-loading all the strings. Ideally you could build filtering into it too.
This is just a foolish design! A better option is to add a button which the user can click on. When he clicks on it, a new form opens with a connection to the options table and it will display all the options in the way you prefer. The user then has to select one, could use pageUp/PageDown and all kinds of filters because -of course- you'd be using a DBGrid to display the options and then the user clicks the "Select" button which will return the selected option back.A new form would provide all the space you would need!
From a design viewpoint, anyone considering a dropdown list with 12.000 options will be considered a fool by the users of this software! It would definitely make it very unpopular, no matter how fast you make it! Why, you say? Because users can't find what they need in a list that big without additional search options!

Why would a SharePoint lookup menu require a double-click to select an item?

I have a SharePoint feature which programatically creates 3 lookups in a custom list, one from each of 3 different lists via extremely similar CAML markup.
The only differences in the CAML are the List, ID, Name, DisplayName and StaticName properties yet one of these lookups looks slightly different (has a slightly more "modern" drop-down arrow) than the other two and this same menu requires I double-click in order to select an item instead of single-clicking as I do with the other lookups.
Might anyone have seen this before and have an idea of what I might look into to make this lookup operate as a single-click menu?
The style of dropdown displayed is usually related to the number of items, although it also renders as a standard select element when viewed in firefox.
For any other field type it would make sense to create a custom field control, but due to code that expects things to be named "Lookup", lookup fields are next to impossible to extend.
The best way to customize a specific field is probably with javascript/jquery. When you click on the dropdown arrow, ShowDropdown (in core.js) is called. This creates a select element with options set from the pipe delimited list in the choices attribute of the textbox.
Add some code to the page so that on load EnsureSelect and FilterChoice or similar are called to create the select element. Set properties on the textbox and select elements so that the textbox as hidden and the select element is a visible dropdown. Have SetCtrlFromOpt called on change rather than on blur/double click so that the control that the server will read and save is properly updated.
The same approach could be used to keep the combo box but add a click event to set the value rather than requiring a double click.
How many items has the source list of every lookup field?
Lookup fields shows a "Combo" when the source list has 10 items (I'm not sure if 10 item is the exact limit). When the source list has more than 10 items the lookup field shows a "ListArea" control that works as you said.
I have exactly the same problem. One difference I have noticed is that the one listbox that requires a double-click is a lookup field, whereas the one that doesn't is a choice field with pre-populated choices. Don't know if that helps.

Resources