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.
Related
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.
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,
I was wondering is there any option of using Stylesheets for .NET Windows controls ?
If not, which is the best way to make the UI look consistent.I need to use VS 2005 to make
the changes in the UI.
Regards
We derive usercontrols from all controls in our system -- all the derived classes do is set the style from a central list of constants defining colours and fonts. Then we use these controls on our WinForms for a consistent look and feel.
If we want to change the style, we just change the list of constants.
This also allows is to perform UI tricks like setting the background colour of controls to a different colour when they are being edited.
If you want to make your UI consistent and pretty, why don't you give WPF a try? You will be able to organize your styles in resource dictionary, then reference to it in all the other projects.
Well guess he's talking about WinForms. Then you cant use Stylesheets. Havnt coded that much of WinForms. But guess you could have an "Settings/sheet" class that have properties of different style you are using and then set them when creating your controls.
you can use Stylesheets in web pages only not in Windows controls.
Even ASP.NET controls, which ultimately render HTML, are notoriously CSS-unfriendly. The reason is that they use tables extensively for layout, and they set a lot of inline style tags which of course do not honor the style sheet. Some work has been done to create wrappers for these controls, but it was incomplete the last I looked.
It's a shame, but our team will not use the out-of-the box controls most of the time. We've rolled our own and packaged them into an internal library. While the Microsoft controls would have been very useful, they simply don't meet our criteria for clean, accessible, styleable HTML.
Microsoft seems, finally, after something like 10 years, to have realized that this is important to a modern development team. The control output of ASP.NET MVC is far cleaner and behaves itself quite well with respect to CSS. Whether they'll eventually revisit the core ASP.NET controls is anyone's guess.
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.
I created a pretty fancy winforms app for my company. We had a graphic designer create the GUI, which was a pain to implement, all graphical buttons, lots of layered backgrounds and logos, animations, etc.
But now my company wants to resell it under different brands. But since I mostly coded it well, I told my higher ups I could have a totally rebranded version done in under a week. Basically all I would do is change a bunch of settings in an xml settings file, swap out the graphics with a new set, and build.
Problem is if they want 5 or 6 different brands, I'd have 5 different builds to support (I really should be supporting 1, with diff templates)
The problem is its not easy (as far as I know) to swap out the images in a winforms app. I have all the graphical resources in a single folder, but once each file is entered into its respective image list or container in visual studio, the only way to get it to update is to remove it and re-add it, changing the source folder doesnt cause the embedded image to refresh. This would be incredibly tedious for each build, there has got to be an easier way.
Add On:
So after some further investigation, I am leaning torwards some sort of resx file editor. However the ones I have seen so far are more focused on translating strings to various languages, and are either very weak, or can not at all edit binary resources like bitmaps/png's. Though if you open a resx file in an xml viewer (I use notepad 2 with .resx set to use xml sytax highlighting) MS is kind enough to tell you exactly how each type is compiled (mostly variations of base 64)
I think your goal should be having "brandable" resource files; you're essentially localizing your application, except you just have a few different versions of English.
You can use ResGen.exe and ResourceManager to load an external resources file, so you could use 5 different "resources" files but keep your code base the same.
This post may also help...
http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/b388c700-0e07-452b-a19e-ce02775f78a6/
Edit: BTW, I will second the comment that if you're going through a great deal of effort on this, consider WPF... Most of those "graphical" elements could possibly be done natively especially if it's gradients and stuff, not to mention the easy templating.
What I would do is just load all the graphics of the disk at start up from a folder and create any imagelists needed as appropriate, instead of doing this in the designer. If you are worried that someone would steal the graphics, then I would create a simple file format (possibly encrypted) for my graphics and a small simple app for you or the designer to use to convert into this format from regular files. Then it's just a question of swapping out this folder between different brands.
If most of your forms are similar (i.e. same logo, same buttons on the bottom, etc.) you can use visual inheritance on WinForms to define a set of "Base Forms" from which your actual forms inherit.
If you develop a set of "Base Forms" for each of your brands, each set in a separate assembly you can plug-in the needed work to generate a new brand is reduced to generate a new set of Base Forms.
Hope it helps
It's too late now, but WPF would have been a better choice than WinForms, as it is easier to skin.
However have a look at what DevExpress does for WinForms, as their controls have a skinning system. It is not too hard to swap a DevExpress winform control for a standard winform control.
I think you should be thinking about creating user controls for the dynamically replaceable areas of the form. At runtime, you could swap out one assembly out for another.