I'm trying to style some buttons in Wpf. The only thing I actually want to change is the colours used for the hover/click/focused effects.
All the tutorials I've found rely on replacing the template for the button entirely. This is great if you want to change everything about the button; However, if all you want to do is change some colours it's a monumental undertaking to reimplement properly.
The default control gives a lot of functionality for free (animations, UI automation/accessibility, tested in multiple localisations, etc). Making it look like the original is tedious enough, but making it function the same way is near impossible.
So... Instead of trying to reinvent the wheel, is it possible to load the default template, modify it and then apply the modified version? Doing this in xaml as opposed to C# would be preferable.
I had the same issue a few years ago, and I came up with this solution.
Hope this helps.
Related
I am developing a windows form. I want to change the physical appearance of the form and its controls. I was able to use the Skincrafter demo, however this is making the application substantially heavier. I am not satisfied with how "heavy" it feels when navigating through tabs, moving the window, etc. It's fairly simple program and I do not have this issue when not using skincrafter. When not using it, the GUI is very responsive and I want to keep it that way.
I've tried many different skins and the results are very similar in every case.
So I will not be using skincrafter unless someone points me out to possible reasons for this slower GUI. I followed their tutorial and didn't do anything else. Simple process. Before: fast GUI - after: slow GUI.
Can anyone recommend me another way to change the appearance of my controls/form? Is there way to programatically change the appearance of controls and form, without relying on a third party skinning software?
Note that I do not want my users to change skins. I want to apply one and that's it.
thank you
Steve
Edit:
The project is far from done so I am going to give WPF some real good thoughts so I don't end up doing this when I have a 4x times as large as it is right now.
I've already start converting and it shouldn't be much of problem. Found timer and serialport cannot be front from the toolbox and timer are replaced by dispatchtimer. No big deal so far.
One another thing that makes me want to work with WPF is that I may have the need to make graphs (plotting) to show temperature over time. I use serialport to communicate with an external USB controller (virtual COM port) that reads a bunch of temperature sensors and fan speeds. I suspect graphing to be better with WPF.
One last thing: it's just about colors/fonts but more about looks of the buttons, looks of the actual window (border shapes). What I wanted to do was something similar that is done with html and css. I do want to have custom labels to give them the look of a "digital display" for real time temperatures and fan speed measurements.
again thanks all for the help provided!
In the distant past, I added lightweight skinning to WinForms projects by subclassing the out-of-the-box controls (Label, TextBox, etc), and having that subclass read in appearance configuration (e.g. color, font) from an XML file (one could also use app.config).
That approach was easy to implement, and I saw no visible performance degradation.
If you just want a consistent, new look and don't need to enable the end user to pick from a variety of skins, the subclassing approach is very straightforward. For example, to modify the look of a Label:
public MyLabel : Label
{
MyLabel()
{
this.ForeColor = Colors.Blue;
}
}
Then, everywhere you currently have a Label in your code, use a MyLabel instead.
If you are starting a new project, I would highly recommend using WPF instead. It provides a much more flexible UI framework. One key feature is that it separates the look from the UI implementation.
For a long time now, I have been stuck with Windows Forms development (started with VB6, and has continued through to C# .NET 4.5), and I have pretty much hit the limit of what Windows Forms can do, both using pure .NET, and special effects with Native Code.
I have tried to learn WPF and XAML, but I get stuck right at WPF's new designer. It really seems very difficult to use in comparison to the Windows Forms designer.
I want to know if there are any alternatives to .NET's WPF designer, that are more suited to Windows Forms developers?
I like to blog about beginner articles for WPF, and there are a few in particular that may help you out:
Understanding the change in mindset when switching from WinForms to WPF
What is this "DataContext" you speak of?
A Simple MVVM Example
To summarize, the biggest difference between Winforms and WPF is that in WPF your data layer (the DataContext) is your application, while in Winforms your UI layer is your application.
To look at it another way, with WPF your application consists of the objects you create, and you use Templates and other UI objects to tell WPF how to draw your application components.
That's the opposite of WinForms where you build your application out of UI objects, and then supply them with the data needed.
Because of this, the designer isn't actually used that much since your application components are designed in code, and the designer is only needed to draw a user-friendly interface that reflects your data classes (typically Models and ViewModels)
And personally, I prefer to type all my XAML out by hand since it's faster and doesn't make as much of a mess as the drag/drop WPF designer does, although I do use the Designer on occasion to preview what my UI will look like.
So to your answer your question about if there's other WPF designers suited for WinForms developers, I would suggest that instead of looking for another designer, instead look to learn how to use WPF in the way it's meant to be used. Using WPF like it's WinForms means you miss out on much of what makes it so great :)
Well although, some people don't agree, I would also recomment to not use the VS designer. At least not to create an interface. If you may want to get a first impression of your implementation without starting the application, it's a good viewer at least as long no sophisticated things like Styles and Templates are used. But, IMHO, its drag and drop result should only be used as prototype and therefore be discarded after it's no longer needed.
Here are some reasons which are important for me not to use it.
The VS designer is working with fix margins and alignments (which is usually not necessary, if you're using the layout controls), means you have to touch many controls, if the requirements are changed. If you're deep in XAML and the WPF mechanics you can create an applications which can be modified with small effort, regarding the look and feel.
Since the designer is generating the xaml, the composition is not optimal and the UI may perform badly. I didn't measure it, it's just a feeling.
A much better alternative is MS Blend, although the start is everything else but easy. Its drag and drop result is much better that the result of the VS designer.
But it's a pretty powerful tool, which helps you to use pretty powerful elements to create a state of the art UI. I recommend to visit at least a short workshop to get an idea of its opportunities.
Back to your question, IMHO, and I think many people agree, get yourself a good book e.g. WPF Unleashed and later, if you want to know more about the details, WPF Pro. There are a lot of features which are different to Winforms. You won't get to know them by using any designer. I think that's the best approach.
Please also consider that there are many frameworks and libraries (e.g. MVVM light, WPFToolkit) out there, which are already solving some common problems. So it's not necessary to reinvent the wheel.
I know this is an old question but for the benefit of anyone else looking at this, I think I should redress the balance a bit - reading some of the other answers, I get the feeling that some of the 'don't use the designer' sentiment comes from not using it properly.
This tutorial is quite good to get you going and answers some of the criticisms in the other posts.
For instance, you can switch from the Winforms-like margin-based layout that is the default when you drop a control, to a more WPF-ish style by right-clicking and selecting 'Reset Layout'
This video covers similar ground.
I still prefer the VS2010 designer on balance - VS2013 seems to be a bit buggy when dragging and dropping onto TabItems **, (which my current project uses a lot) - but the VS2013 Document Outline view lets you move things around in that view too, which can be a real plus.
Really, though, to get the most out of WPF and xaml you need to be reasonably fluent in both the designer view and the xaml view and switching between them; if you shy away from the designer, you are missing out on something that can help you a lot.
** Edit - although this seems to have been improved in Update 3 for VS 2013, and in previews of VS14, to date I still get odd behaviour at times.
First of all, in WPF (XAML) in Visual Studio deisgner, you should always use the xaml code to build you UI and do not drag and drop you control! You need to keep your code clean. You can use Expression Blend to help you, it's more graphic oriented with drag and drop, but it's not free.
It's not a big learning curve, but I think you should learn how to do your xaml by hand instead of searching for alternative.
I've been through this process as you did. Afterwards I was teaching everyone in my company WPF. There are a couple of important lessons I have learned and everybody I know who works with WPF.
If you are working with UI controls in the code behind, .... Then you are doing it wrong. There is absolutely no need for you to deal with UI controls in the code behind.
You do not need the visual developer for clicking on it. You are much more productive by only dealing with XAML.
Use Copy/Paste. Do not trust in your typing capabilities. It will save a lot of headaches.
Think of the XAML just as a window that loks over the data. In the code behind you are changing the data. In XAML you are defining how the UI will interpret the data.
Converters are amazing. As soon as you get a key amount of Converters, your productivity will rocket Sky high. They will take over the role of the crazy amount of control eventhandlers that hide or resize, or what ever about UI,
It makes UI development fun. Especially once you find out how it likes to play along with Asyc processes. It really takes away a lot of the headaches that were caused by Winforms.
i am trying to research some gui technology for c# where i can display a tree view (opposed to the standard one provided.)
Essentially i want to have the gui draw a tree of data (as if you were going to draw a binary tree on a piece of paper or something) Then making each of the nodes clickable.
If this isnt available does anyone know of something where i could have a mindmap type GUI which shows links between elements and those are clickable?
I can guess people will say make one yourself, in which case i give up already ;) thats too advanced for me and as i am on a work placement i dont think i would be granted the time to make it as there are more pressing issues to get working first, like actually making the programme work!
Thank you
You can take a look at the controls in Kevin's WPF Bag-o-Tricks which has a WPF mind map style layout. Here is a nice example. If you want to use more professional components take a look at the product from Nevron Software, they have some great controls. There is also an opensource WPF graphing library - graphsharp (which I have no experience with, but I found a nice article by Sacha Barber). Since it's used in nDepend it must be pretty mature.
I hope you get some inspiration from those links :)
I also found XMind API for C#
https://xmindapi.codeplex.com/
It's free and looks easy to use.
NOTE: I am not exactly sure how to title or tag this question, so if you have any ideas, PLEASE help!
I'm currently envisioning a few possible projects that involve dynamically rendering something (whether it is a point, a line, text, or music notes on a staff, for hypothetical example), but, if I were to undertake these projects, I'm not really sure how to approach this design. What I'm curious about is sort of how programs like Word, or Geometer's Sketchpad, or Finale, create a blank "canvas" and render text, geometry, or music on it, respectively - how can this be done in C#, or in .NET, in general?
First of all, what is the best framework/platform to use: WinForms, WPF, something else? I'm open to many options, as I'm just trying to understand the different ways this can be done.
Next, how can I create such a "canvas" (if we go back to that metaphor) using the different frameworks you answered for part 1? And also, how can I render stuff onto it?
I hope my question isn't too confusing or n00bie. I just don't know how to approach such a prospect. Thanks!
UPDATE: I have now posted a follow-up question which is less broad. I have provided an hypothetical example of what I would like to accomplish. However, I will still accept an answer here, even though my question isn't fully answered.
WPF would probably suit your project well. I like the book Pro WPF in C# 2008: Windows Presentation Foundation with .NET 3.5, it covers most of the topics you're asking about.
You'll probably get better answers with a more focused question. The scope of your question is too large to be answered easily or concisely.
WPF makes it easier to refactor designs for such a project by easily moving shape drawing code between just drawing simple shapes and contents of controls. If you need the richness of custom controls, WPF allows a fairly smooth transition.
Most of the graphics can be defined in XAML which means you can export them from programs like Illustrator or anything that generates the standard SVG vector graphics, via an SVG-XAML converter.
I like WPF Unleashed and it has a nice discussion of 2D graphics and how to use the DrawingContext class for such a visual editor.
Do you know that there's an event called Paint? Everytime Windows OS needs to displays or repaint something on your form, this event is triggered. So, you create a Paint event handler, and everything is possible in that. For eg:
Word: you have a WordDocument data structure with the formatted tags and stuffs, you paint each character/ each word or each block of words one-by-one using a desired brush/paint and font. You might also wanna paint your background and stuff... If, for example the user change the font of 1 particular block, your WordDocument must change something to reflect that font change. And then you do an myForm.Invalidate() to repaint your form (and thus update your font). => Dynamically update your GUI.
Sketchpad: you need datastructures such as Line, Point, Triangle, etc. And then, each time OnPaint is triggered, you paint it dynamically. E.g: myGraphics.DrawLine(..), myGraphics.DrawCircle(..)
Similarly to Finale.
One thing you should do is to handle your data structure and drawing classes carefully, and instead of drawing everything in your OnPaint() method, you create several DrawMe(..) methods in your entity classes, and ask them to draw themselves. E.g: myCircle.DrawMe(..), myScore.DrawMe(..)
Hope that'll help,
Ben
There is no universal answer to your question - it is too generic.
Are you talking about dynamicly created controls, standard UI components (dropdowns, buttons)?
Is it vector graphics - like in drawings, or may be it is 2D image processing - or is it 3D?
I used WPF very little before and some stuff seemed very different to achieve. Coming from a winforms background, what things will seem different and take you a while to figure out.
Off top of my head, I remember not being able to specify which nodes are selected in a treeview control the way it's done in winforms, if I am not wrong.
I remember the whole MVVM principle..
But its okay now.. we are bffs now! :)
Oh, where to begin? WPF and WinForms seem very different to me. The concept of defining layouts using markup is quite different, although similar to web development. The fact that you need to make an explicit choice of a layout container (for multiple elements) is novel. I remember trying to add a bunch of elements directly within a Window and getting very confused...
I think to take advantage of all that WPF has to offer, you need to have a WPF mindset. For example, you don't have to use styles, templates, and bindings, but those concepts are where the power of WPF lies.
As Daniel stated WPF is different and it needs a different Mindset. You have to forget all the UI side assumptions you made/learned while doing Winforms or other conventional UI side development
I have comeacross so many similar kind of questions in this site. Some interesting once are listed bellow. You can find many here.
What are the most common mistakes
made in WPF development?
How to begin WPF development?
When is Winforms the correct choice vs. WPF?
For your selected node in a treeview the ModelView ViewModel approach works well. People have worked out good design patterns now for this kind of thing making the process much more easy.