one button with wrapped list view
my searched result are:
1.worst approach: put add button on the wrapped list view.
2.bad approach: set two data template for list view.
3.?
thanks
I've had something similar a while back. In the end I decided to add a fake data item where I needed the button.
Say I had a list of MyDataItem, I created a derived class MyFakeDataItem and added that at the end of the list, after I finished populating it. In the WPF I created two data templates, one for each class, and a selected to decide.
I think it turned out quite elegant, since it allowed me to easily override any real functionality I had on MyDataItem, and add a command on the fake one to suit my needs.
Hope that helps.
For my setup I have two sub-views (on the same View) that render the same type of Models, however each view uses a totally different set of Model (one displays the latest ones, the other is split in 4 subviews per category). Using filter() on a Collection doesn't work because I need 4 posts per Category and about 20 new ones.
Since they are both on the same page, when I update the model on one view, I want the same model to be updated on the second view.
I tried a couple of things:
Use one Collection on the mainView, fetch inside the mainView and give this common Collection to the subViews. This is working as long as both subViews are using the same set of Models, which I am not.
Use custom events and a Collection in each subView. When Model is updated, send a global Backbone.trigger with the modified Model, catch it on the other side and do stuff as needed. This is also working but the implementation is really not pretty or efficient. Having all the Models listen for change and only act if their id is the correct one seems counter productive.
Use one Collection on the mainView and one per subView, the idea being that the Collection on the mainView holds all the items and distribute them to each subView's Collection as needed. This works but fetching the data, duplicating in the main Collection and the other subView Collection is kind of a pain and requires me to hold an instance on mainView inside each subView, which I don't really want to do because each subView is a "component" and can be use in multiple places.
People online seem to do the Events way most of the time, but I wonder if someone has a better idea.
Thanks a lot.
We have a list of items in a TreeView where users can select the item they want. Every item can be associated with another item. I have a button on my ItemEditor view that opens a new window with the associated item in read-only mode. The read-only copy of the item has no save functionality nor does it give any of the edits made by previous users. It does however share 90% of the fields, out of ~50.
Do I take the hit in almost duplicating the entire view and create a pure ReadOnlyItemViewModel? Or is it typically more acceptable to set flags in my view model to display which editable items are hidden?
You can map multiple views onto the same View Model. It's actually encouraged. You don't have to make a ReadOnlyItemViewModel...just make a View on top of the ItemViewModel. If you are trying to auto-generate the view, make whether it generates read-only or fully editable view a strategy of the generator. If you need more fine grain control consider adding attributes that express how a field should be displayed in Read-Only vs. Editable mode. Only after you've explored all those avenues should you consider splitting the VM into two.
I understand the syntax but not how really to use it. It's clear in many basic scenarios but as soon as it get's a little bit advanced I start getting a headache.
For example there are many different views but often not clear wich one to use. Also should you use always just one or mix and match. Do you use the view as your itemssource for ItemsControls?
I'm gonna give a scenario. I have items from a database that I need to show info about in a app and also allow to edit and add new. The items form a hierarchy and the models are of different types. So the top level have children and they then have children.
I could show it in a TreeView or some itemscontrol. Problem here is I tend to bind to the children property of the root elements wich returns a List of chilren. Now the children aren't really inside a view, like I can't call editview.addnew() or filter the children straight away. Question is how do I ensure the children are also in a view and their children and so on. Should the model return a view, should I create a seperate view for each children type or even for each parent?
Another thing is if I'm allowing editing should I put the Collections straight into a IEditableCollectionView or wrap it in ICollectionView first (why is that better)?
Is there a good guide to using views that isn't just pure basics?
I'm developing a Winforms application which has been running for years with an explorer view (TreeView left, screen right). I means that:
All the screens have an hierarchy organization
All the nodes on TreeView have one and only one screen related.
A screen gets activated when a node on treeview gets selected.
One of the advantages is that the user has an ordered stucture and one of the inconveniencies is that with hundreds of screens the user gets confused.
I see other options: use classical menus, use tabs or a mix of everything.
Any advice for a good way to show a lot of screens to user in a user-friendly way?
Update: I'm changed "hundreds screens" by "a lot of screens". The most important thing is not show all at time but that the user can find what they need easily.
Update2: In this proposal, the user only see one screen at time.
Update3: I'm talking about handling multiple screens not showing multiple screens. No MDI, only one ontime.
I have used other applications similar to this is the past, and the major problem is trying to find the exact screen you want. There are two common solutions to this problem, shortcut codes and favorites menu.
With the shortcut codes, allocate a short code (5 or 6 characters) to each screen. The user then inputs this shortcut code into a text box which will then jump to the correct screen. Users will create their own list of often used codes.
For the favorites menu, allow users the ability to be able to create their own menu list in the structure they want. They will find things easier, if they organize it themselves.
Why do you need to show so many seprate screens at once? Why not just show the screen for the currnetly selected node, why are all needed at once?
If it is all tabular data is is probably too much to be consumed all at once, if it is graphical data, could it not be combined?
There may be a valid reason to show all the data at once or there may not, hard to tell from what is provided in your question. With that said, better to keep it simple than overload the user. MDI apps are never easy to use.
Tabs may work for a small set of items but still is not a good UI for hundreds of items.
If you are only showing one element at a time, out of hundreds possible on the tree nodes, then that is fine. The one screen showing at a time would be contextual to the item selected as the user moves through the nodes. Think of the Outlook approach where what is selected in the left pane is displayed in the right pane in whatever form fits the data being displayed.
Have you considered the Office Ribbon?
The Ribbon gives you a lot of flexibility on how to show and
organize functions and it's highly visual.
Here is a good link about the Ribbon and also here
To use the Ribbon you have to license it from Microsoft. You can do that online.
Providing the user with ketboard shotcuts is usually a good thing too.
I also like to provide the user with an "autocomplete" field on the menu
so that they can can find the function by name (or part of it) and be
able to navigate directly to where they want to go.
I general I find trees to be a bad idea, especially if your "hierarchy" is of a small fixed depth.
If you have a small fixed depth, consider replacing the tree with a list. At the top of the list can be drop-downs for filtering based on the node-level properties. It will use up less screen real-estate because it is vertical-only, with no horizontal component.
Clicking on an item can display it in the view (like currently), but it may be a good idea to allow a user to double-click on more than one item which could launch more windows, or tile with the existing displayed items. (I am assuming that currently, the user only sees a single detailed view at once in any given window.)
Actually, it’s hard to beat a hierarchy for organizing large numbers of items. I wouldn’t favor a classical pulldown menu for vast numbers of windows because it would be even harder to keep track of where you are than in a tree (e.g., a tree lets you look in multiple branches at once). But here’s a few alternatives:
I’m not clear how you ended up with so many windows, but maybe it comes from combinations of classes, views, content, and detail, or maybe it comes from using a task-centered UI structure for something far too complex (I’ve more on that at http://www.zuschlogin.com/?p=3). For complex apps, you want a different primary window for each significant class of data object (e.g., invoices, employees). These are listed on one menu, and typically there’s few enough (15 or less) that it can be single non-cascading pulldown menu. The content of each window is set by a separate menu, perhaps by a menu item that opens a dialog that may include a list box (like an Open dialog) or other controls for querying/searching. The “view” of each window (how the data objects are shown, e.g., table versus form) is set by menu items in the View menu. Details for any given object in a window can be shown in a separate pane within the window in a master-detail relation, essentially turning you data objects into a menu for details. A single window can have multiple detail panes for the user to open and close to select the specific detail to show. Tabs may also be used within a single pane to fit subdivisions of content.
You say it’s not important to show all window options at once, but often showing all options at once makes it easiest for users to find what they need. Maybe you need a “home” window that lists all the other windows in organized, labeled, and separated categories. This is will be easier to use than the tree if your users select a window then stick with it for most of the session. Your tree is better if there's frequently selection of windows throughout the session, owing to the overhead of getting to the home window. If all windows/options don’t fit on a single home window, then show only selected common windows for each category on the home window and provide a button or link to show an exhaustive list.
If you’re talking 100’s of windows, maybe you should have Search, perhaps in addition to a menu-based browse approach to getting to a window.
In any case, providing easy access to the few most commonly used windows is a good idea. Such windows can be explicitly selected by the designer, based on user research, or selected by the the user (favorites), but it also typically works well to make it automatic with an algorithm that uses some combination of frequency and recency of use.