Difference between using XML for static controls and making controls programmatically? - c#

I have started using WPF and started with some games and visual apps.
In my first App I started a blank project then made a class that inherited from a window which had a canvas that I added and removed images from Dynamically, like follows:
class MainWindow : Window
{
public Canvas canvas=new Canvas();
public MainWindow()
{
this.addChild(canvas);
}
//add an image every second move it and remove it
}
This would be impossible with static XML but someone told me it is a bad idea to do controls dynamically, is it true?
Is it a performance loss?
And is there a simple and efficient method to draw, lets say, 100 images at a 30 fps without lag?


There is no performance loss / the performance loss is negligible compared to the HUGE productivity / code cleanliness gained by doing things the RIGHT way.
And XAML is not static.
There is DataBinding, and if you need to add / remove items dynamically there is the ItemsControl.
There is also the concept of DataTemplates that dynamically render specific UI depending on what Model / ViewModel objects are passed to it.
Do not manipulate nor create UI elements in procedural code. WPF is not winforms.


None of the controls are reallystatic. There is no any runtime difference.
Most likely, by using XML you meant XAML. XAML merely serves as a data source use to actually generate C# code (or the code in VB.NET or other .NET language) to compile is and to use exactly in the same was as you would do it programmatically.
You can use this fact in your work. If you know how to do certain things with XAML but don't know how to do similar thing in C# code, do the following: develop XAML-based project and build it. Then perform the search for *.cs files under the directory where your project file is located. You will find some *.cs files which was not in your source code. Those files were auto-generated with the use of XAML. Look at them.
You will be able to learn how it works behind the hood.
Good luck,

Related

Avalonia MVVM: splitting large xaml files

I am using Avalonia UI to develop a rather large single-window application using a Carousel control to switch between pages. As to be expected my MainWindow.xaml file is getting pretty large. It's currently at about 600 lines of code with only a fraction of the UI finished and I figured it's time to refactor. I have already used UserControls where ever redundant code was present.
So I was wondering: What would be the best way to shrink the size of my main window xaml file?
As I am using the MVVM version of Avalonia (I think there is another project template, correct me if I am wrong) I also have to worry about how to deal with all the bindings to my MainWindowViewModel.cs (which I cleaned up by making the class partial and splitting it into several files, each holding the code for one of my Carousel tabs).
My current plan is to outsource every Carousel page into a separate UserControl and then somehow pass references to the parent Carousel via bindings and Avalonia properties to be able to switch between pages from my backend and hopefully find a way to do this while complying to the principles of MVVM and without messing up all the bindings.
I am sure this will create new problems on it's own though and would be rather painful to rewrite so I figured I am probably not the first person to use Avalonia in a somewhat big project. So is there a better alternative to my approach?
I heard of StyleInclude but was unable to find comprehensive documentation of what it does, how it works and when it should be used.

Usage of same xaml file for silverlight and wpf application

I want to use same xaml files for silverlight and wpf version of applications.
Only difference that i need is in styling. I have used styles in xaml. But for silverlight i dont want to use any styling in my xaml files, as styling is defined a application level in the form of themes.
Is there any other way to use same xaml file for silvelight and wpf versions? Otherwise I am forced to maintain separate xaml files.

you can reuse quite a bit of xaml for both, I have projects where I'm linking all the same files, xaml and code behind and it works decently.
A couple of things to be weary of is certain things don't always match up well, for example wpf has a template selector for a itemscontrol and silverlight doesn't.
Using SizeToContent tends to produce different behaviours in the two, I recommend avoiding it, I don't think it buys you anything.
I recommend having a seperate 'base' resource where you can keep your difference in the two files. things like event triggers for example aren't nearly as filled out in silverlight. you would have a base class for each version and they would abstract their differences, you could then mark the keys the same and use them as a static resource in your linked files.
Another big gotcha is you want to watch out for the order events happen for uielements, loaded,layout and apply template events get applied in different orders so if you were to make a templated control you have to be careful there, its not a deal breaker you can work around it, just be aware.
other things to be aware of
-silverlight commands take a little more effort, you have to implement ICommand, this isn't always the case in wpf, I use my implementation to help with sharing the code though.
-wpf is the superset, it has a lot of functions that silverlight doesn't have, Usually they are convienient ways of doing things, you just want to avoid those. Good Examples would be Preview events, not there for silverlight but you can usually find an event to match the behaviour.

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.

Preview of code-only WPF controls in VS2010 - how?

I hope I am able to illustrate the problem using a lot of images. First of all, I was no real fan of XAML (Silverlight issues, crashes in Preview, and so on...)
Now, with VS2010 the situation has become better. There are still a lot of things I like better in code, but I also want a preview in my VS.
So, take a look at the following control: It is really simple, a todo details list. The first screenshot shows the code of the control, pretty straighforward:
CodebasedControl http://img28.imageshack.us/img28/2263/invoicea49.png
There is no XAML, so obviously no preview. Of course, I could encapsulate it in another control, like shown in the next screenshot:
CodebasedControl http://img11.imageshack.us/img11/9515/invoicea48.png
But, in that case I have an additional file I do not want or need.
So I had the idea to move the init stuff inside the contructor of a XAML control. For simplicity, I used simple elements. But they do not show up in the preview...
CodebasedControl http://img99.imageshack.us/img99/5547/invoicea47.png
CodebasedControl http://img512.imageshack.us/img512/9625/invoicea46.png
Finally, I know I could use the controls in other parts of my app when creating UIs. But I am using layout manager, PRISM and a lot of other stuff, so I just want an easy preview of some specific control I created (without having to have a XAML wrapper file for each control)
Thanks for help, and sorry for the post structure, but I though with images it is better to understand...
Chris

Ok,
I found a way. Basically I am tricking VS by changing the XAML, but keeping the code-behind linked to the file. It the same like the wrapper solution, but without having a dedicated extra class or file. I am using the "xaml-infront" file for preview.
This solution only works with pure code controls, I have to do more research for mixed controls (at least I think so.. but it is enough for me for now).
Please be aware, the code behind is NOT partial anymore. It could be placed anywhere else, what I am doing here is basically only related to file-names and visual studio "readability"..
See screenshots for explanation:
alt text http://img15.imageshack.us/img15/5456/invoicea50.png
Some space for easier reading
alt text http://img186.imageshack.us/img186/1545/invoicea51.png

Is XAML in WPF equivalent of .Designer.cs in Windows Forms apps?

Is XAML in WPF equivalent of .Designer.cs in Windows Forms apps?
Does it just provide compile-time state for the UI?
I am not sure but it looks like you can do things programmatically with XAML at run-time.
If I have a basic UI state where everything is added at run-time, then should I be looking outside the XAML stuff?

It's probably safe to look at XAML that way - although it's not entirely accurate. The XAML is compiled into BAML, and parsed at runtime - where the Windows Forms designer.cs file is just another C# file built by the designer. XAML is never directly translated into C#.
You can do everything done in XAML via code, though. Charles Petzold's WPF book actually takes this approach. It builds entire WPF applications in code before he ever introduces XAML.

In addition to Reed's input, I should mention that:
XAML uses XML syntax to define UI, but Form does not.
In XAML, it is much easier to separate UI from the logic by using code-behind-design. As UI is only XML, and they can be designed totally independent of any code-behind changes.
Minor changes like Button where you can set Content instead of Text, so you can set anything whereas it could be only text.
Data Binding and Dependency properties are way easier and better in WPF comapring to Windows.Form
Very easy and cool way to handle your design, as you can find there are many cool examples on the net.
You can use tools such as Snoop to visualize your 3D design, and can inspect and verify all your controls and events by selecting the UI. You can see what events are handled or not. This is a very cool tool, and you can find similar ones.

Categories

Resources