Develop Reference

Change view when using WinForm and MVC

As part of a school project, a group and I will develop a Windows application using C#.
We are not very experienced in C# but has some basic understanding for it. We do however have experience from other languages and platforms.
We would like to build an application in which the layout is split into two primary parts: the menu, which will reside to the left and the content which will be to the right.
The menu will be more or less static and when an entry in the menu is chosen, the content will be changed.
We have not been able to figure out the best way for achieving this nor have we been able to find good material on this. The idea is to have one window and add a view (as far as I can understand, this should be a UserControl?) to this window. This control will be the menu.
Now, our question is if anyone can point us in the right direction to achieve the navigation in the program. Say, when a menu entry is clicked, how will we change the content of the window and how will we manage which view is active? I suppose that every view (in the "content area") will have a controller.
We are interested in the "best practices" for this when using WinForms and the MVC pattern.
We hope that someone can help us further in this project.

If I were you I would seriously consider using WPF instead of winforms.
It, and the use of the MVVM pattern, allows you to do some pretty impressive stuff with far less code than if you are using winforms. If you don't already know winforms then it might also be a slightly less steep learning curve as WPF is a better thought out framework (at least in my opinion).
If you go the WPF route spend some time getting to understand how bindings work and how to bind your ViewModel to the UI. Once you have a good understanding of proper UI separation you are able to do far more than you could with the old WinForms framework.
I found this link quite useful when I first started looking at WPF. Especially the RelayCommand.

If you are using Winforms the options that you have got is:
-dynamically clearing forms and generating content on menu navigation
-using mdi container form, which can be parent to a number of child forms
If you are using for WPF you could use Pages in a Frame control loaded based on used menu selection. You could also use MVVM pattern to build your app.

How to use C# with WPF

I want to create a UI for my application.
What really confuses me is how to actually do it. I know that Microsoft has introduced WPF.
I have also seen some examples, but what I am not getting is whether or not WPF a seperate language? How can I use C# with WPF?
Lets say I want the user to click on a browse button, select a file and display it's content on the UI. I want to do it using C# while WPF providing the UI, is this possible?
Any good resources for a newbie like me?
EDIT
What i didnt understand, will i use WPF for my UI or windows form for my UI while my actual code is in C# ?
I think i am being lost here ? WPF seems something else that supports c#. is that true ? i thought WPF was only for UI while the actual code would be in C# or VB.
I have taken wpf unleashed but it explains wPF and not how to use C# with it. Atleast in the starting chapters ?
I know i am being dumb here but i am really confused

Yes it is definitely possible. Take a look at this article about Mode-View-ViewModel (MVVM) from Microsoft, which is a good introduction to using Xaml (the markup language for WPF) with C#.

Since you are familar with WinForms I will explain it like this.
WinForms provides the GUI and it is similar to what WPF does.
WPF however mainly uses XAML, a markup language based on xml to design the visual elements. It is a presentation foundation on its own that could be used without XAML but it is certainly a big part of it.
When creating an application it will be either WPF or WinForms you can't combine the two (well easily anyway I know there are a few ways to get around it)
You can interact with WPF the same way you interact with WinForms elements.
You can create a Window. On there you can place a grid, where you can then place controls such as a button or textbox. Then in the code behind it is exactly the same as referencing a control in winforms. for example in the page_load function doing
txtInput.Text = "A String";
So what should you choose? (Please note I am about to give you a few things to compare I realize this hardly describes both technologies to its fullest)
WPF
Pros
- Great for visually appealing designs
- You have XAML based control over your visual elements. Meaning you can change the way your form looks by writing xaml instead of doing all through the visual studio IDE pressing buttons.
Cons
- Bit of a performance hog. It has come along way with .net 3.5 sp1 but still chews up quite a few resources
- Not as many controls built for it as WinForms, mainly because its a newer technology.
- Can become complex as syntax for binding information to controls doesn't include intellisense.
WinForms
Pros
- Familiar and well used technology so your development will be faster
- Better performance
- More controls built for it
Cons
- More effort to build a visually appealing design
- Its not new and exciting so to speak. I know we all like to learn new things :)

It is not a seperate language. WPF employs XAML, a derivative of XML, to define and link various UI elements. As in web development, both layouts and specific themes are well suited to markup, but XAML is not required for either. Indeed, all elements of WPF may be coded in a .NET language (C#, VB.NET). The XAML code can ultimately be compiled into a managed assembly in the same way all .NET languages are.
You can implement your requirement in easily WPF.
To get a hands-on in WPF start with this article, http://10rem.net/blog/2010/02/09/getting-started-with-wpf--hello-world-in-multiple-flavors
Happy coding..

WPF is part of .NET framework, so it's not related with specific programming language. Please read MSDN's "Introduction to WPF" - http://msdn.microsoft.com/en-us/library/aa970268.aspx

Workflow with C# in Visual Studio

I normally code with PHP, I am used to opening up my editor of choice and going away at it, coding classes,methods, etc. It is fairly easy as there is no GUI to worry about.
Last night I spent the whole night following a couple tutorials with C# in Visual Studio, it's turning out to be harder then I thought it would be. Once thing that I am not use to is, all the tutorials have you add a form object like a text box or button, then have you double clikc it to get to the code part, you then enter some code for that method. Then back to the form and re-peat
This seems very hard as you are never really working on "just the code" so 1 question is, is it always like that or just because i'm new and following tutorials?
Another question, when I see source code online to do certain functions, say I see a class I would like to try using, how can I use that class in the existing form class created by VS, do you somehow import other classes or do you add them right to the form code you are working on?
I'm sure that didn't make much sense but hopefully it does to someone, i'll try wording it better if not.
I should add that this was with WPF, also I feel like you have to learn 2 languages, the C# which has very similar syntax to PHP so that doesn't seem too difficult and the for GUI that's like a whole diff language

You can download the classes you are interested into.
Then you go to the Solution Explorer panel and you add existing items.
This will COPY the files to your project.
In order to use those classes you need to declare that you wan to use them.
So, what you have to do is to say something like
using FooNamespace;
Then you are ready to use the classes.
The name space is declared right before any class. You can go edit it.
Now about the forms. Each form is a Class and it consists of three files
ClassForm.cs
ClassForm.designer.cs
ClassForm.resx
You ONLY need the first one. Right click and view code. You can go there and use it.

Many questions, Many answers
Difficulty and Repetition
you can add form objects via the designer or you can hit the source button (CTRL-PgDn). From there you can edit elements in asp and html just like any php IDE. I do most of the work in source. I am a real programmer so I can never do the drag and drop. With intelligence and time you learn the properties and what to do.
to make complex pages you just have to know what you are doing.
What I started with VS I had the same feelings as you, but i have gotten into the flow of it.
As far as the code behind, you are just hooking methods up to the asp elements that get called by the built in code. You can add your own classes, functions, everything in the code behind or in separate files, just like c++, php, whatever.
Hope that helps, VS is really powerful and runs smooth when you learn where things are, been using it for years now and I'm still learning. Bottom line, never use drag and drop and just play with it.

unfortunately the .net world love drag-drop controls. so most tutorials are designed around this concept. drag a textbox on the to form. drag a button onto the form. double click button image to get the click handler.
it's not needed, it's just the approach for most people using visual studio. being that this is a WPF project everything can be done from code, or xaml markup. you don't need the WYSIWYG editor.
as for adding/referencing classes first you need to reference the assembly the class is located in. your core .net types (part of the BCL, base class library) are automatically included as references. then you add a using statement to the appropriate namespace. then you can instantiate the object.

There are ways to have a C# interactive window; see this question. Alternatively, you don't need to use a form, but you could also create a command-line application.
As for the second question, you can add a new class to your project and then use it in your form. There's really no additional step, except that if the namespaces are different, then it is easier if you import that namespace (via using).

Partly, yes, because you're new and using tutorials.
Partly, no, because you're working with forms, and you really don't want to hand-code those by hand.
If you just want to play with C#, and not concern yourself with forms and display, look for information on Console application. Instead of worrying about buttons and textboxes, your worst nightmare will be Console.WriteLine();
Here are some console-based C# tutorials:
C# Station tutorial
C# Yellow Book - it's a PDF. It's good.

Yes, it is exactly because you are following the video tutorials which are almost always tailored for beginners... Most of us making a living working in VS, developing WPF solutions do not even use the visual editor but instead work directly with XAML to build our UI and have very little or no code in the code behind files following the MVVM pattern.
To answer your second question, most of your classes that "do stuff" which is not directly intertwined with the UI should be in a separate class library (dll file) and should not even be referenced directly by your main UI project (in order to facilitate loose coupling) but instead accessed using some form of Dependency Injection, typically utilizing Interfaces.
The code that responds to user interaction should be in your ViewModel classess which are typically a data context for your views and these VM classes are typically using service agents which implement different Interfaces in order to use code stored in the class libraries mentioned in the previous paragraph.
Now, it is possible to just double click on a button and write all your code in that method created for you in the code behind file just like with Winforms, but just like in the Winforms world that leads to code that is hard to maintain, that is tightly coupled to your user interface and very difficult to test so try to resist that instant gratification and invest some time in learning the MVVM pattern, DI and OO design patterns which facilitate code reuse, decoupling and testability...
Hope this helps...

It really depends on what you are trying to learn. I don't think I would start off with WPF if I was using C#. I would start off with a console application to get the basics of the language down, then move down to a simple WinForms application, and finally to WPF where you started.
But yes, your questions about how the editor works is correct. It's how that platform works.

WPF: slow template instantiation

I have a WPF application, and it's slow.
It is NOT the rendering. Firstly, the rendering is quite simple, and secondly, I looked at it with WPF Performance Toolkit - nothing.
It is NOT in my own code. Firstly, the unit tests work fast, and secondly, if I replace all DataTemplates with blank ones, everything works fast.
So far, it looks like the slow part is template instantiation. That is, when you start the application, and open some complicated screen, it takes a lot of time. And by "a lot" I mean "a lot". Sometimes can be as much as 3-5 seconds - for example, when there's a datagrid with 100 rows. But when you go to another tab, and then go back to that same screen, it opens fast (as long as its viewmodel stays put).
This is very annoying not just because it's slow, but because I can't do anything about it. If I had some control over the slowness, I could, maybe, display some "opening, please wait" message or something...
Besides, when I look at some other WPF applications (most notably, ILSpy), they seem to work reasonably fast, despite the large amounts of data. This makes me believe that I'm probably doing something wrong. But I have no idea where to start.
Any ideas? Any classic mistakes? Any tips?

My exerience comes from working on the WPF mind mapping application NovaMind
A couple of months ago we completely rewrote our intermediate layer to solve the performance issues we had experienced. In a nutshell, creating our user controls seemed to be way to slow. Unfortunately I couldn't find a great way to profile the performance as neither the WPF Performance Suite nor commercial applications such as ANTS Profiler give you any detailed information on this part of the WPF process. (I asked this question back then)
We resorted to manually test our application by trial and error and removed parts of our user controls to see what exactly is the culprit.
In the end we solved the performance issues by completely rewriting our controls. We also cut down on the complexity of our visual tree dramatically. Before the rewrite, one of our most used user controls, when inspected with Snoop, consisted out of 61 different things, now there are only 3. Wherever possible we only added things to the visual tree on demand. (As you know in XAML even when you set things to Collapsed, they need to be created first).
Finally we were forced to write our own rich text rendering control as the built in RichtextBox is ridiculously slow and the visual tree of the RichtextBox is quite complex.
I don't know if this will apply to your situation but I would recommend that you investigate your user controls and see if they are complex. Maybe you have things that you could trim.
Low hanging fruits would be parts that are only rarely visible or can be created in a lazy manner. You could create these parts from code behind when necessary rather than having them in XAML. This should help you a lot.
Otherwise virtualization is your friend, if possible. In our case we couldn't do that unfortunately.

This sounds similar to a problem i was having. I posted the fix here: WPF UI Automation issue . Just posting for the benefit of searchers, as it took ages to resolve.
Following comment on link only answer, here is the crux of that post:
I did the following:
Downloaded Hotfix - - http://archive.msdn.microsoft.com/KB978520 (may not be required)
Downloaded Hotfix - - http://archive.msdn.microsoft.com/KB2484841 (definitely required even if you have Windows 7 / .NET 4)
Improved the code further (the validation was causing an excess of objects) - Why does WPF Style to show validation errors in ToolTip work for a TextBox but fails for a ComboBox?
It may be that only Number 3 was required, but it worked. Just posting here so people dont lose the days I lost in memory profilers etc.

User Control in your data template, is not completely bad idea but if you crave for performance then you should consider switching to lighter control. For example, having a UserControl just hosting a TextBox is very bad idea, as UserControl is made up of ContentControl, ContentControl hosts ContentPresenter and ContentPresenter will host TextBox so if you notice your Visual Tree, it has three new layer of UI Elements. Reducing Visual Tree will certainly improve the performance.
Most likely, I would suggest creating Custom Controls that may be a completely a new control having few dependency properties that can relate to data you want to present and you can have its own custom template in generic.xaml. Second, you can just simply derive a control from existing controls and redefine its default template in generic.xaml.
This approach will certainly work better as you will be reducing your Visual Tree, thus reducing Visual State Manager's job.
Changing theme or template will be slower then changing the element that hosts content. And let the element have the default template in its own generic resource dictionary.

Try moving all the resources up as
far as they'll go, preferably into
app.xaml
Check if you could use StaticResource
instead of dynamic ones, static ones
are alot faster
If possible, try using depedency
properties in your VMs, especially if
you have alot of them at once or if
they have alot of properties. That will keep wpf from having to do a bunch of reflection.

You mention you are using a DataGrid with, say, 100 rows. A likely culprit of your perf problems is that whatever datagrid you are using isn't doing virtualization, and so your visual tree is gigantic.
Normally, long startup time in WPF screens points to a large visual tree.
I'm not sure if you're using a datatemplate per row, or some 3rd party grid that binds columns, or what - but lets say you have 8 columns with controls. Depending on your grid/validation/etc, this could be a visual tree of 20-60 items per row. If you have a combobox, then each item in the dropdown may be created per row as well.
To fix this just takes watching the details, and taking measures as you go:
Use a virtualizing control as much as possible. This means using a virtualizingstackpanel inside list controls, and making sure your 3rd party controls do as well (many stock WPF controls do now by default)
Do not overuse UserControls, composite controls, etc. Adding depth adds time, and putting in extra visual tree depth in a datatemplate or other repeated area adds up fast.
If all else fails, show a simple screen and add controls through code to improve perceived performance

how to design a calendar control

I need to design a calendar control which should be added to our companie's application (I know there's already quite a lot calendar controls but I shall develop our own one...).
How should I start, should I use a kind of table to display the days or should I completely draw my own grid? How can I do this (I do not need rdy-to-use code, I just need some ideas...)
The application is written in C# as a WindowsForms application (thanks for the hint, forgot to mention this in first case...)

Seeing your comment about WinForms and:
I need to develop an own one because it must be integrated in an already existent application, I need full access in means of style and functionality
makes me suggest to use ready project http://www.codeproject.com/KB/selection/MonthCalendar.aspx and modify it if necessary. I use it in my own little project and it works like a charm. It provides full source if necessary so you can integrate it easily and modify if you think it's not fit enough.
In the end if you end up not using it, you can peak at the sources and functionality it implements and do it your own way.
To me redoing it from scratch is a bit pointless especially with such a good / free one.

If you are developing a web application then I would seriously look at using jquery. A good calendar control should be done client side so I would be looking at some form of java script solution. If you look at jquery-calendar.js as a good example you will see the complexity involved in developing your own control.