I have recently reviewing someone's code and come across a User Control whose UI is like this screenshot
This control has no code in its code behind file, i am thinking we could move all the xaml code of this user control to a control template and use it whereever required. I want to know if this a good practice and should i do so?
Is their any performance and design benefit of one approach over another?
I want to know if this a good practice
So first we should define good practice? I will give the agile good practice point of view: do it only if you need it. Thus for you the answer is in your question:
use it whereever required
Is it required in any other place? If so, use a Control Template. If not, use a User Control, which will be more readable for the next developper anyway (Keep It Stupid and Simple).
Since ultimately this is going to be a UserCotrol,Now suppose some other team working on other module require this control and they want Loaded event of the Datagrid within this Control, Now if you create it as datagrid within usercontrol then they can easily access that datagrid and subscribe Load Event to it. If you will do it in ControlTemplate then it will be difficult if not impossible.
Related
I know how to create a simple XAML interface for a page, but I spend a lot of my time copying and pasting code since I have no idea how to create reusable XAML in a proper way, I know about styles but they don't quite fill the role. What I would prefer to do is to call them in the following way:
<CustomElement attribute1="bla" attribute2="{Binding somethingElse}"/>
Just like all the other GUI objects in the Silverlight framework.
Any help or hint would be useful.
Basically there are two options. Both solutions act like any other Silverlight control. They can be inserted at random places in pages like you would normally insert a Button or a StackPanel. The option of choice depends on the specific reuse scenario.
Create a UserControl. These define their own XAML layout and are very easy to create. Consider looking at ScottGu's tutorial.
Create a custom control. Custom controls also define their own XAML layout but through templating and styling. They are harder to create but support templating; this means other developers can decide that they will use the code behind your control, but specify a completely different layout. For more information look at Silverlight templating.
For a (much) better understanding, please look at this page comparing the features of UserControls and custom controls more in-depth.
First of all, I want to let everyone know that I'm very new to the MVVM concept, and have looked pretty extensively for some explanation of what I want to do, but to no avail.
In the program I'm working on, I have a UserControl with a few buttons on it, which need to control the navigation of the main window. I have 3 different "pages" I want to be able to switch between in my main window. Instead of pages, I decided (for whatever reason, correct me if this is not the best approach) to use a UserControl for each page, and switch the visibility to the correct one. I need the data to persist while switching, so I don't believe that creating new instances of the Usercontrols will work.
My question is: How can I bubble the events from my "NavBarView" to the main window in a way that will allow me to switch the visibility, but in a MVVM way? I know I may be completely going about this the wrong way, and I'm happy to take any suggestions on a better way of achieving this navigation.
I have to use WPF, so WinForms is not an option. Too much transparency and custom controls for WinForms.
I would make the "NavBar" part of the main window if possible and use that to control the sub controls in the forms. I would be careful nesting User Controls. If you can avoid it I would (key indication is are you going to reuse it somewhere else). I took over a project a while back that had a main window with 3 separate highly coupled user controls that had to all work together and it was a nightmare. The only way I could get it to work somewhat safely was to have them all set their data context to the same view model. If I had to do it from scratch - would have taken a completely different approach with a single view.
I am currently working on this big project (a GUI to control hardware) that was written in C# with .NET 3.5. Now the next revision of hardware will be coming, and some of the changes are such that some of the controls that we had before are not needed, and some new controls need to be added too. Since the changes are huge, it would require almost a month to go through every control and put a condition to make it visible or not.
I was wondering if there is any other way to tackle this problem easily other than manually conditioning the whole project. Thanks in advance.
If you can make the decision to make visible or invisible based on some attribute of the control, such as its name, or tag, you could write a method that could walk a window's controls, and programmatically hide the ones you wanted hidden. For controls like a label you might key on the text of the label.
Written correctly the method could be written so that it is re-entrant so that for controls that contain other controls, the method would call itself for each of the current controls children.
The hardest part about this would be to determine how to decide programmatically make the on or off decision.
If that's not possible, another solution might be to write a small app that would read the code and list the controls you want to examine, allowing you to make a decision based on your knowledge of the application. The app then could make the changes necessary to set an attribute on the control in code so that its hidden when the code is compiled.
You usually have to design for these kinds of things, and by the sounds of it, it isn't designed for this.
but quite often, this kind changes appears quite large, but often isn't THAT big of a deal.
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.
All in WPF:
Developing a wizard application, user has to answer a number of simple questions before brought to the main app. The main app is then prefilled with the information obtained from the wizard.
I started with a Window which I then planned to add usercontrols to. The main window would have the user control in the first row, then Next and Previous buttons to control moving between the controls in the second row. This way I could easily control the logic to switch between screens like:
WizardControl1.IsVisible = false;
WizardControl2.IsVisible = true;
But for some reason, user controls do not have setter for IsVisible. Hurray.
So then I thought I would just use seperate windows for each section of the wizard. The problem with this approach is that now when stepping between, the window opens in random positions, and by steppign through the wizard with next, the next window pops up randomly which is really distracting and frustrating.
So how can I develop a wizard properly? I don't get why this is so hard...not exactly rocket science... replacing text and controls and storing input after pressing next/previous!
Thanks
Check this link:
http://www.codeproject.com/KB/WPF/InternationalizedWizard.aspx
This is the article about building wizard in WPF by Josh Smith, it's seems to be nice pattern.
I found it's helpful for me, hope you'll too.
There is also an open source Avalon Wizard control on codeplex.
I'd probably aproach this using data binding and template selectors. Have the wizard form bind to a "WizardData" class, which exposes a list of "WizardPage" base classes.
The WizardData class can expose properties defining the correct info on the forms, and display a control for the main page that uses a template selector to determine the proper control to display based on the actual type of the particular wizard page.
It sounds like more work than it is, really. It also gives you the benefit of good separation between code and UI (all "work" is done by the WizardData and WizardPage classes), and the ability to test logic independent of the UI.
It's also a very WPF/MVVM way of approaching the problem.
I recognize this does not directly address your question, but I thought I'd mention it as a possible alternative. I've used Actipro's Wizard control with pretty good results, and when I have needed support, they have been very responsive. I am not affiliated with them in any way; I just like not having to write the plumbing to manage a wizard.
The property is called "Visibility".
I find that I do better when I dynamically add and removing controls rather than hide them.
I was looking for a Wizard solution too. I have the need to stick with stock WPF components so I implemented the wizard using a standard form and a tab control.
I only hide the tabs at runtime so there available in the IDE. At runtime just use Back, Next, Finish... to navigate thru the tab items
works good