How many times have we seen this type of selector:
List Box Selector http://geekswithblogs.net/images/geekswithblogs_net/dotNETvinz/MoveItemsListBox.jpg
I was just about to start creating this in a WinForms app, when I thought that others may have some ideas for doing this better. We need it to sort - so the right hand list will need up/down buttons. But this seems so old school. I love devexpress components, and was thinking of asking them if they would consider adding a component that handles this functionality with a slick UI.
I am thinking that a graphical representation of the objects, and a graphical representation of the listboxes - that would be a more intuitive way to move items around.
Has anyone seen an open source project like this?
If a CheckListBox won't suffice (and it usually will), then the "modern" approach would be to use a ListView or similar component with a "Transfer" column. Render the button inline in that column, one for each row, so that it only takes one click to move an item from one to the other.
You see this everywhere in Vista, usually with hyperlinks as opposed to buttons. Instead of clicking on an item and then choosing an action, you click the action at the item level.
I wouldn't go overboard with slickness as it can impair functionality, but the dual-listbox screen is definitely old-school.
Also, if there's a very large amount of data to manage, it helps to provide a progressive search at the bottom of one or both lists.
I have done this type of selection using (essentially) a single CheckListBox that displays each item as an image. Part of the image looks like a LED, which is on (bright) if the item is selected or off (dark) if it is not selected.
This works well if you have a reasonable amount of data to select from, and also works well in a multi-column format if you can predict that the options will have reasonably similar lengths.
Allow users to drag items in/out of list 2, and also drag to reorder in list2.
(All items dragged out of list2, and dropped anywhere outside the list, get put back into list 1, in their correct place in the list by alphabetical or natural order.)
You can merge the two list boxes into one with the help of groups (LVGF_GROUPID flag): one group for selected and one for not selected.
You can also implement group membership changes with drag-drop between them. This way single drag-drop can move an item into the other group at the appropriate position, saving most/all of the other buttons.
Additionaly the bottom of each group can have one pseudo item with help text (i.e. "Drag items here to...") that is visible only when relevant.
Related
I've noticed that certain dropdowns, despite having e.g. five different options in the set, only display two at a time, which makes scrolling an inconvenience. On the very same form, another dropdown displays three and a half rows and, as far I could see, there's no relation between the number of rows displayed and the placement on the form nor does such a relation exist related to the number of the elements in the option set.
(How) can I control (or at the very least affect) the number of elements displayed in a dropdown? I didn't find any options for that in the settings (format has only the num er of columns to span across).
Judging from what I've seen, CRM lets dropdowns lower bound expand until the lower end of the container tab. Because of this, one is forced to add spacers (creating "holes" in the form) when the optionset sits at the bottom...
There doesn't seem to be a way to manipulate this behavior, unless one strays outside supported customizations and goes on manipulating the DOM.
I'm trying to create a filter so the user can choose any of 40+ fields to display in a query result that has been dynamically created via VBA.
This is something I see standard in a lot of programs so I figure someone must have code that does it without me reinventing the wheel. Unfortunately I haven't been able to find it online.
Basically when it starts all the field names are listed in the left box and the right box is empty. The user can click a right arrow button to move the fields into the right box or a left arrow to remove them and put them back in the left box. Also the user can use up and down arrow buttons to change the order of a selected field in the right listbox.
Once I have the right listbox populated and ordered correctly I know how to execute the query properly.
If you are unable to find a full example for this then you'll need to work through it step-by-step yourself. Here is an MSDN link for the ListBox control. There are links to the various methods and properties of this control at the bottom of the page.
Essentially, clicking a button (your arrow(s)) triggers the Click event;
In this event you might need to loop through to find the Selected item;
If the listbox is multi-select then you can examine the ItemsSelected collection;
Then you would use the AddItem and RemoveItem methods to move them for right-to-left or left-to-right.
I cannot recall currently whether the Field List option is bound to the table, or whether it just populates the list once when the form is loaded. If it is bound then you would instead need to use the Value List option and use VBA to retrieve all the field-names, and use these to set the RowSource (you may be doing this already).
In either event (Field or Value List) I don't believe the lists can remain sorted automatically (unlike in VB.NET). You will probably need to split the RowSource up into a (dynamic) array, find a simple sort routine to sort the array, and reassign the sorted items as the RowSource.
An alternative would be to create two temporary tables and use ADO (or DAO) to insert and delete rows between them, then use SELECT statements each time to re-populate the lists. This has the advantage that the SELECT can include an ORDER BY clause to sort the lists each time. However, It perhaps involves a little bit more effort (to maintain, and delete, the temporary tables).
You might, however, want to continue your search as I suspect an example is out there somewhere. Good luck.
I'm using VB Net, but this is entirely a question about user interface, not coding.
I want to "manage" a table of "orders." Orders is a typical table with a foreign key pointing to a customer, and a one-to-many relationship with a "details" table. To manage orders means to enter new orders, add details to orders, record payments, print a list of orders, cancel orders, mark orders shipped, print one order, etc., etc. These tasks can be divided into tasks that affect single orders (cancel an order) and tasks that affect multiple orders (print a list of orders).
That task division led me to this user interface: present a form/window that displays by default a list of orders, and provide a button that switches the view from list mode to single-order mode. Each mode then provides the buttons for its tasks.
I first implemented this with panels, putting the controls for each view into its own panel, and then superimposing the panels. I then use hide and show methods to switch between panels, effectively switching between views. It works, but meh...
Would it be better to use a tabbed control, and put each view on its own tab? I'm not trying to re-invent any wheels. I know nobody gets fired for making it look like a Microsoft app. LOL :) But I haven't seen any retail applications to copy from.
I'd argue that your "multiple panels" approach IS tabs, just without the tab part. In reality, tab controls do basically what you've already done with code, they just hide that behind a convenient design time facade.
Still, it's the same thing.
E James answer is pretty good. Would it make sense to put both on screen at a time? is this a touch screen app or a traditional windows app? How sophisticated is the target user?
Those are a few questions that should drive how complex you let the screen get.
Do you have room to show the list and all of the possible controls? If so, I would start with all controls disabled. When you select a single order, only the single order controls would be enabled, and when you select multiple orders, only the multiple orders controls would be enabled.
I would also put the most common tasks right into the list, if possible, so that only one click is required for frequent tasks.
In order to support automated testing tools I need to x:Name all controls (so that the tool can "pick it up" and observe its details).
The question is concerning DataGrid where the ItemSoure is bound to a property (in the ViewModel).
What is the best way to ensure all rows and all grid cells are uniquely named?
A better question is: If a DataGrid is x:Named, will automated test tools be able to observe its rows and individual cells, even if the rows/cells are NOT x:Named themselves?
Option 1 (which id like to avoid) is the x:Name each row (on the row loading event, as well as all of its column cells).
Is there perhaps another option where all of these are x:named (uniquely) automatically?
Even better, perhaps all this is not even needed.
In case anybody is interested, i found the answer. Listen for the Row-loaded event. From there recursively traverse down the rows layout/control tree while naming valid controls (while ignoring any layout controls... Grid, StackPanel, Border).
I am creating a web control in vb.net that contains a list box. I know that I am able to choose a selection mode of Single or Multiple, but I am interested in limiting a Multiple selection to a predetermined size. For example preventing a user from selecting more than 3 items.
I have tried adding a Validator to the list box, which might be a way forward, but was wondering if there was a way of changing the selection mode to something a bit different than just the two specified ones.
Any ideas or suggestions would be greatly appreciated
Edit: Unfortunately due to project limitations I am unable to use Javascript on this problem. very annoying I know!
You could try handling one of the SelectedIndexChange events. With multiple selection, each time this event fires you can check how many items have already been selected. If it is more than you want, have the handler deselect the one that was just selected. You could also put up a little red label under the listbox saying "Sorry, no more than [n] selections allowed."
EDIT:
Just noticed you said WEB. Same theory applies, but it would have to be done using Javascript.
On the SelectedIndexChanged event, write a short piece of code that will check the number of selected items and if it is greater than your desired amount, unselect the new selection (or unselect the oldest one, or however you wish this to operate).