I am looking into developing a GUI that will switch the controls based on the value of the selected combo box item.
I have tried adding a different canvas or grid to the gui designer in visual studio but it comes hard to manage as everything overlaps each other in the designer and is hard to know what's what.
Is there an easy way that I can do this, is there a particular control that makes this easy to achieve. I don't really want code the gui in c# and not use xaml.
What I was hoping to do is that all the controls are in there own panel and when the combo box value is changed one panel is removed or hidden and the other is shown.
How can something like this be achieved.
Thanks for any help you can provide
You could implement each different "mode" as a separate UserControl.
Then have a shell with the combobox, where the combobox OnChange will swap out what UserControl is plugged into the shell.
Any other totally common components such as OK/cancel buttons could be part of the shell.
A completely alternative implementation to consider is a tabbed approach, but that probably only flies if it makes sense for the user to act on several of them.
What will you do if the user selects A in the combo, makes changes in UserControlForA, and then selects B in the combo? Could be an annoying corner case, and if this is production code the sort of thing that you'll get future user requests to change how it works.
If you're sure of the design go for it. If not, I'd play around with a few apps and try to find a nice example of the same sort of thing, and consider how they approached it.
But techwise I think a UserControl is what you're describing.
(Edit: crud just saw the xaml/wpf in the question, not sure this is correct in that context, clueless there)
You can use DataTemplate for each different mode.See Different item template for each item in a WPF List for more information.
Related
I am in the process of recreating a Win32 (Delphi 5) screen using WPF in C# with the MVVM pattern. The purpose is to create a demo that I can use to push my company to make the move from Delphi 5 to C#. In this demo I want to do things the "right" way so we have a good example to start with. With that in mind, I am trying to adhere to MVVM as strictly as possible which is where I am currently running in to a problem.
In the original program/screen we have lookup dialogs that we can attach to edit boxes and grid cells. The way it works is that the lookup dialog is an implementation of a specific search (i.e. Customer lookup). When you attach the lookup dialog to a control, it listens to the key press events for the control. It has a progressive search feature so that when you start typing, if it can find results that start with what you are typing it will insert the first result in control you attached it to. While doing this it keeps the cursor where you were typing and highlights the part of the data that you typed in so that if you keep typing it can narrow down the results to find the more specific answer you were looking for. Where the dialog part comes in to play is when you hit the ellipse button next to the control or if you type in something that it couldn't find while doing the progressive search. In either of those cases it will bring up the lookup gui which will show you all the possible results, provide filters to help you narrow your search down etc. This gui is visually attached to the control you assigned it to. It always pops up right under the cell or edit box etc that you assigned it to.
So this lookup dialog is throwing me off when it comes to trying to figure out how to implement it using MVVM. So far my code mostly pure as far as MVVM goes. The only code in the Views code behind is the one line creating the ViewModel and assigning it to its DataContext. The ViewModel makes no references to the view. But with this lookup dialog the lines seem a little blurred to me. I envision the lookup having it's own ViewModel. When you lookup something, say an Item to be put in a Sales Order, we may want to get information like the Item's price from the lookup so that it can be copied in to the Sales Order record. So to do that the main ViewModel for the screen needs to know about the lookup's ViewModel. The View for the main screen needs to know about the View for the lookup too though because it has to be able to "attach" the lookup to a gui control so it can listen to key press events and know where to visually popup when it needs to be shown. I'm not sure if the code determining the visual position of the lookup should reside in the lookups ViewModel which would break the MVVM concept totally or maybe in the lookup's view's code behind which would muddy the purity of the view a bit since now the View isn't just the XAML.
The original lookup, after being created, would be given a reference to the control that it should attach to. It would then attach functions within its object to the key press and button click events (our edit boxes can have buttons built-in). When it was told to popup, it would figure out the current position of the control it is attached to so that it could figure out where to put itself. In the case of attaching it to a grid, it was actually attached to the column of the grid because there is only one instance of the lookup, and it would figure out the current position of the cell in the grid it is supposed to be popping up under.
What is the best way to do this while still staying in the realm of MVVM. I really would like to stay as "pure" as possible so I can come back later and add integration and possibly unit tests for the ViewModels in the program and these should be ViewModels that are "headless" (no View).
To make it easier to understand what I am trying to achieve I have included a picture of the screen I am recreating for my demo with the lookup shown.
I am working on a Win8 app destined for the Windows Store. Hurdles I am trying to overcome is how to deal with the different ways an app can be displayed.
Currently, my main pages is a LayoutAwarePage so it has logic to handle different visual states. However, my question is more how to make my page render differently depending on its state.
I thought, initially, that you basically created a layout for each state that the application supports. But it seems like the VisualStateManager portion of the XAML is just an area where you make piecemeal modifications to the design (hide an element, change an alignment).
I am working with a grid that has many columns and rows to organize my controls and it looks great in fullscreen. However, this doesn't work at all in the snapped state, as most of my controls become hidden off screen. I could certainly add a ScrollViewer control, but this is basically a hack and a usability nightmare for a user.
Thanks for any insight!
It might be that your app doesn't lend itself to snapped view. You are allowed to simply display a message / image that states this. Alternatively, consider just showing the columns that are most important.
The standard MS way seems to be to replace horizontal oriented controls with vertical ones - maybe a listview or something would look better. You'll probably find your code easier to read if you have one control for snapped and another for full screen.
Not exactly related to your question, but Blend works very well with XAML to allow you to manipulate the grid or show the relevant control.
Here is a very good guide from Jerry Nixon.
http://blog.jerrynixon.com/2012/12/walkthrough-implementing-snapview-in.html
I'm building a C# client app that allows a user to communicate with one or more existing users in a system via an email-like metaphor. I'd like to present the user with a text entry box that auto-completes on known email addresses, and allows multiple delimiter-separated addresses to be entered. Ideally, I'd also like the email addresses to turn into structured controls once they've been entered and recognized. Basically, I'm modeling the UI interaction for adding users after Facebook's model.
Are there any Windows Forms controls out there with the ability to do something like this? Is there any well-established terminology for a hybrid textbox / control list box (no, not a ComboBox) or something that I should be searching for?
Thanks,
-Patrick
I have had good luck in the past creating composite user-controls to provide specific functionality using native .NET Winforms controls. It works pretty good as long as there aren't too many of them, in which case things start to slow down.
In you case, and this is just off the top of my head, but, perhaps you could take a FlowLayoutPanel, a Button, and a Textbox which supports auto-complete and put these together to create a control that would provide the functionality you are looking for.
If there are no addresses selected in the control (e.g. in a List<string>), then the container (FlowLayoutPanel) would only display the TextBox. Once the user selected an entry, the control would automatically create a Button with the appropriate caption and insert it to the left in the FlowLayoutPanel. If the user removes an address he/she has already selected, simply remove its representation (the button) from the FlowLayoutPanel, and the TextBox can resize accordingly. There may be issues with getting the TextBox to fill up the remaining space (I can't remember how to do that), but you get the idea. The container does not have to be FlowLayoutPanel - you could use a Panel with Docked controls, or even a TableLayoutPanel for this.
A design as I described would allow the user to delete the address by clicking on the button. However, without some other visual cues, that isn't very intuitive or user-friendly, so I would consider making the "Button" be another composite control which contains a "prettied-up" label along with an tiny delete Button (X) to the right. For this you could use a Panel control and dock the X button to the right, and fill the Label on the left. You would provide public properties here as needed to control the text and provide an event handler or callback for the delete functionality.
Once the visual stuff is working, all that is left is to provide the appropriate Properties and Methods on the main control to allow it to interact as needed with outside code.
As a simple, "poor man's", implementation you could take a look at the AutoComplete* properties of the TextBox control. You could dynamically populate the AutoCompleteSource with your known addresses and when an entry matches, add to a separate, list-style control of your choice.
See this SO article for some interesting code snippets related to your question, and my suggested workaround.
Beyond the built-in AUtoComplete properties you're probably looking at having to purchase a 3rd party control from a tools vendor.
I've not seen anything like that before in WinForms. In WPF it would be another matter - if you can use that, maybe consider hosting a WPF control within your WinForms application instead?
I think you're trying to do something similar to this codeproject article: AutoComplete TextBox
And since you mention WPF in a comment, you also have this article: WPF AutoComplete Folder TextBox (should be easy enough to cut out the folder bit of the article I'd thought).
Well, there isn't such a control. If I were you, I'd create 2 textboxes to do the job. See, a normal textbox can easily be configured for autocomplete from a list, even dynamically; however, it accepts only one entry at a time.
So, I suggest you dedicate one textbox for autocomplete, and one for the addresses. So, whenever there is a qualified email address in the first textbox, and you click enter, the address gets added to the address textbox, and automatically add delimitation.
Then you need to handle the addresses in the address textbox as objects instead of characters. Code it in a way that when a user tries to delete a character in an address, the whole address is deleted.
This is the workaround I can think of. I'll help with the code if you give it a try.
EDIT:
So, I ended up making my own basic solution to this problem, and it can be found in my own answer to the question below. Or, here's a link.
Original Post
I'm doing some UI programming for a small .NET application. The application has some collections of items that need to be displayed in a grid sort of format (X columns by Y rows) and the grid elements need to be able to get dragged around to different grid locations, and possibly out of the grid all together.
The most comparable sort of UI design elements I can think of are the jQueryUI Draggables.
Do I have to roll my own or are there components people have already written to act like this? Even better, are there any free components? Or is there an easy way to do this that I just don't know about (don't do a lot of .NET UI programming..)
Also these "grid items" need to be able to include windows form components. The DataRepeater control is close to what I need, except it only supports horizontal or vertical alignments, not grids of items.
Here's a visual example of what I'm looking for:
I tried to stick with a halloween theme here.
Well I rolled my own solution and hosted it on GoogleCode:
draggableitemorderedpanel- A .NET Winforms Component... Kinda like jQuery UI Draggables (not really, maybe someday)
here's a screenshot:
(source: googlecode.com)
and another just resized:
(source: googlecode.com)
Hope this helps someone else out. Also it's super basic and pretty sucks right now but gets the job done.
Anyone that wants project access can have it.
The System.Windows.Forms.TableLayoutPanel control supports dragging and dropping, you just have to handle the right events. You could make your own "GridItem" user control, with the icon, caption, background color, etc displayed on a Panel, and then plop a bunch of them in the tablelayoutpanel, and wire up some event handlers. Here's something similar:
http://social.msdn.microsoft.com/Forums/en-US/Vsexpressvcs/thread/1cade626-b76d-40c5-9e5a-101cf2a5e412
I have a ContextMenuStip that contains a dynamically generated list of ToolStripMenuItem objects. The problem is that when there are too many of them to fit onto the screen, tiny scroll buttons appear at the top and at the bottom of the list, and scrolling through the list is a bit tedious.
How can I make the menu to automatically break into 2 or more columns so the user does not have to scroll?
This behaviour was dropped from Windows some while ago -note that Windows Vista/7 use a tree to show programs in the start menu. I suspect that this was because it presents too much data and decision making for the user.
Are you sure that this is the best way to present the choices to the user?
If so, then you will probably need a custom menu control which will be quite a lot of work.
If not, then you should consider how
you can achieve the same choices with
other controls. How about a list with
a filter?
Is there some natural grouping to the
items? If so you could split into
listboxes, comboboxes or trees.
Does the application need splitting
into different modes?
Are the items numbers? - if so a
numeric up/down control might work
The general approach is to simplify the amount of decision making that the user has to make at any moment.
Spend some time playing with all the controls in the WinForms toolbox to see what works well.