I have a Button in Silverlight. I need to change its style at runtime. The style of this Button needs to change multiple times during the life of the application. Is this possible in Silverlight? If not, what is a good workaround?
Thank you!
Consider using the VisualStateManager to change the state of the button as appropriate.
You could create your own states for each of the different styles you wish to show.
Yes, it's possible, but I'd think hard about what exactly you're trying to do by changing the style itself because there's probably an easier way. You've probably already run into the fact that you can't simply assign a new style to the button with something like MyButton.Style = (Style)FindName("NewButtonStyle"). So you do need some kind of alternative.
The VisualStateManager is the first and easiest way of handling most kinds of changes that you would normally want to do to a control. You can pretty easily set changes to occur on the normal sorts of visible states (hover, focus, mousedown, mouseup) and it'll animate those state changes correctly from whatever state you're in to whatever other state you need.
If the kind of change you're looking for is more extensive, changing the type of control to, say, a ContentControl and then catching the mousedown/mouseup events from there might be a better workaround. This is obviously a bigger deal (and you lose the simplicity of having a button), but you'd be able to get whatever changes you wanted to pretty easily by just swapping out the Content property.
Somewhere between the two (and something I'll mention because it's possible, not because I recommend it) would be to actually manipulate the Style definition itself. The Button will pick up the changes and adjust itself. I'm going to repeat myself here though: I don't recommend this and I can't envision a scenario where I'd prefer doing this over using the VSM or using something other than a Button entirely. But it is possible to get into Application.Current.Resources["Style"] as Style and muck about with whatever you please. The bigger question then is why and whether what you're doing can be done some other way that would make more sense for whoever's going to maintain your code later. Personally, I expect Styles to be pretty static and I think that's the general consensus too.
Sure you can....
if you have a style stored locally you can access it like that :
rec1.Style = (Style)this.Resources["style1"];
Related
I've thoroughly checked the custom controls topic, spent several hours looking into custom controls written by other people. I've written my own custom button, to feel it better. I've read all the google answers around the "why custom controls", "advanced custom controls examples" and such.
My question is, WHY?
Why would I (or anybody) go through 9 circles of hell to create his own custom control, when one can just adjust an existing control to his needs (using styles and templates). I actually didn't find any explanation on google, just tons of examples, mostly from people who sound even less educated than me.
I imagine there IS such need, when talking about some complicated DataGrid with, I don't know, every cell being a button or something (and still I believe I could do it with a regular DataGrid)... But I've not found anything more complex than a beautiful button. Is there nobody sharing a complicated code on the topic?
There are different levels of element customization in WPF, depending what class you extend from. Each has its own uses and is implemented differently. It is not clear from your question if you are asking about a specific type of control or about all of them in general. So, I will tell you what I think about different ones.
UIElement or FrameworkElement
Extending UIElement gives you the lowest level custom control where you have complete control over the layout and rendering. FrameworkElement is slightly higher level as it does most of the common layout stuff for you while also allowing you to override key parts of it. The main idea with these is that they do their own rendering rather than composing other elements together.
I have made a number of custom FrameworkElements over the years. One example is a ruler similar to one you might find in a program like Photoshop. It has a bunch of properties providing customization for how it is displayed as well as showing markers indicating mouse position relative to the ruler (and a number of other little optional features). I have used it in two different professional projects. I think the main benefit is that it is extremely easy to drop in and set properties/bindings on wherever desired. Build it once, use it over and over.
Control
Extending Control introduces the concept of compositing multiple elements/controls into one reusable component via control templates.
I have used this one less often, but still find it very valuable in the right circumstances. Again, the main benefit here is reusability. You create a control with properties that make sense for what you want to do, then hook up those properties to the properties of the controls in it's control template. Really, this is the same as applying a new template to an existing control, with the added feature of being able to define your own dependency properties. You also have the ability to perform custom logic in the control's code if you need to.
I may be misreading some of your text, but you seem to imply that making a custom control is considerably more difficult than making a control template for an existing control. I have found that the two are nearly identical in most cases using this approach, the only difference being whether you have a code behind you can use.
User Control
A user control is really only slightly different from a custom control practically speaking. Only, instead of defining a control template, you define the visual content directly.
This is probably the most common type of custom control. It is basically the standard method for making XAML based content in a WPF application. These can be reused like other controls, but are more suited for single use such as the content of a dialog or window or something else that is specific to a single application.
Some Other Control
You can also extend an existing control to add additional functionality to it. This way, you still get all the features the control offers and only have to implement the additional bit.
For example, I have a custom control called an AutoScrollRichTextBox that extends RichTextBox. So, it does everything a RichTextBox can do. It also has the ability to automatically scroll to the bottom when content is added to the text box (which it only does if the text box was already scrolled to the bottom before the addition content was added).
I could have implemented that feature as an attached property instead of an extension of the control (and maybe I should have), but it works, and I have used it in three different applications (as an output window and as a chat log). So, I am happy with it.
In the end, it really is just a matter of how self-contained, reusable, and easy to drop in you want a control to be. If there is already a control that does what you want, and you just want it to look different, then you should definitely use styles and templates to achieve that. However, if you want to make something that doesn't already exist, limiting yourself to using only styles and templates will make the implementation work harder and make the end result less reusable and more difficult to set up additional instances (unless all instances are identical).
The examples of making things like buttons that look different are not examples of what you should use a custom control for. They are just examples of how someone would go about making a custom control for the purpose of teaching the details of the process. If you actually want a customized button, just customize a button.
I've stuck with one pretty trivial problem (at first look).
Simplified version of my situation looks like this:
I want multiple Background(for example) colors to be applied to SAME Control and to be able to clear only some of them (by condition). WPF does not offer such capability, I can set only one value for each DP.
So, I want to apply Yellow then Green then Red colors successively to Control object and then be able to reset Red so that Control will be with Green background (on the other hand, reseting Green leaves background Red). Looks pretty simple, have you ever created such Decorator for Control? I believe DP internally use such behavior, but there are no public APIs for it.
Please, do not suggest using triggers or any other kinds of conditional DP setting, I really need to set multiple values for single DP and to be able to manage them
Its not a good idea to say "do not suggest" ... Anyway, Well its not possible, and WPF does not do this, what you might meant is the value precendence but this List is fixed, you can't just add another layer in between, for good reasons. The whole system relys on that. Otherwise you could not set one value and use triggers to override it and don't need to take care of resetting the value. Also animations, Style inheritence etc. wouldn't be possible if people start to mess with this list.
So you don't like the trigger idea ... Why? Its exactly for that.
Ok, if you don't like it, how about adding an attached property for Background1, Background2 etc. You also could make Background as an attached property and make it inheritable. You could make an attached behavior, listen to property changes and modify your Background color. You could use a MultiBinding or PriorityBinding.
Well alot of stuff is possible if the obvious solution is not desired :)
As you know, the built-in themes all define styles for the standard controls such as the TreeView control. We're trying to create something that looks an awful lot like a TreeView but isn't actually one, nor is it a subclass of one. It just has parts that we want to look like one for consistency.
For instance, our control too has a selected item whose background we'd love to match to the appearance of the background for the selected item in a TreeView (or more accurately the TreeViewItem) for the current theme. (You can't simply use highlight color as the themes have nice gradient brushes and borders, not just a solid brush.) Same with our expand/collapse togglebuttons. We want them to look just like the ones used in a TreeView for the current theme. (i.e. Sometimes a triangle, sometimes a box with a '+' in it, etc.)
Now while we can simply rip open Expression and copy the styles ourselves (or at least the parts that we need), we'd have to do that for each and every theme that MS provides. Plus, that wouldn't handle newer themes. And in a purest standpoint, that's duplicate styling information which just sits wrong with me.
Also, if someone styles the actual TreeView(Item), we want to pick it up as well. Since the parts that we want to style are required parts of a TreeView, we feel pretty confident that they're in there somewhere style-wise.
Not even sure what I want to do is possible but if anyone knows, they're most likely here on SO!
Yet another question close to a month old without even a comment. Very odd for the SO community to not chime in at least once! Guess it's not possible.
Well, what we ended up doing was using 'Show Me The Template' (Google it) to get the templates for the part (we don't have Expression), then manually managing them ourselves instead of using the built-in styles. NOT at all what we wanted to do since we don't know of a way to get the nice gradients that are defined in the system already without duplicating them, but the end result does match perfectly so there's that. As such, this too is getting marked as the answer. I'll gladly change it if someone else actually gives me one that works (or is close enough! Just need something people! Feel like I'm posting in a vacuum here!
I have a question regarding a ComboBox in silverlight and it's selected item.
I would like to determine what triggered the SelectionChangedEvent, was it the user selecting a new item in the list or was it programatically set?
While ideally I would like to solve this using the CommandPattern (I am essentially using a modified RelayCommand (http://joshsmithonwpf.wordpress.com/2008/11/17/emulating-icommandsource-in-silverlight-2/). I am open to other suggestions.
I have also played around with the SelectionChangedEventArgs, which has an OriginalSource property, which upon first inspection may appear to help, however it is null (regardless of the manner in which the item was selected.)
Any ideas, other than setting an internal flag? :)
Thanks
Unfortunately this is a tough thing to determine, since the framework works pretty hard to simply bubble up any changes or user events in this situation as that selection changed event.
If you really need to, you could write a simple ComboBoxWrapper that is effectively the flag you're talking about - so you could derive from ComboBox, try overriding or hiding the CLR setter for SelectedItem, and then maintain state that way.
Any particular scenario in use here? There may be another way to approach a solution.
I've made it a personal rule to inherit every UI control before using it. In a previous life I'd always considered this one of the less useful things you could do because the justification always seemed to be "I might want to change the font on all the buttons at once"... a motivation that never paid off... once... ever.
Two recent projects have changed my mind about the practice, though. In the first, we needed a consistent "ValueChanged" event so that we could easily implement a "dirty" flag on our forms without a massive switch statement to choose between a Textbox's "TextChanged" event, or a ListBox's "SelectedIndexChanged" etc. We just wanted one consistent thing to listen for on all controls, and subclassing the built-in controls bought us that pretty easily.
In the second project, every effort was made to get by with the base controls because the UI was expected to be pretty simple, but a few months in, it became obvious that they just weren't going to cut it anymore, and we purchased the Telerik control suite. If we had inherited all the controls to begin with, then changing our derived controls to inherit from the Telerik controls would have applied the changes for us globally. Instead, we had to do some searching and replacing in all the form designers.
So here's my question: What are the relative strengths and weaknesses of
Simply adding a Class, and making it inherit from a control.
Adding a new "Custom Control" and inheriting.
Adding a new "Component" and inheriting.
All three have the same effect in the end, you get a new type of Button to put on your forms. I've seen all three used by different people, and everyone seems to think that their way is the best. I thought I should put this discussion on StackOverflow, and maybe we can nail down a concensus as a community as to which one is the "right" way.
Note: I already have my personal opinion of which is "right", but I want to see what the world thinks.
If both 1 & 2 are inheriting, then they are functionally identical, no? Should one of them be encapsulating a control? In which case you have a lot of pass-thru members to add. I wouldn't recommend it.
Peronally, I simply wouldn't add extra inheritance without a very good reason... for example, the "changed event" could perhaps have been handled with some overloads etc. With C# 3.0 this gets even cleaner thanks to extension methods - i.e. you can have things like:
public static AddChangeHandler(
this TextBox textbox, EventHandler handler) {
testbox.TextChanged += handler;
}
public static AddChangeHandler(
this SomethingElse control, EventHandler handler) {
control.Whatever += handler;
}
and just use myControl.AddChangeHandler(handler); (relying on the static type of myControl to resolve the appropriate extension method).
Of course, you could take a step back and listen to events on your own model, not the UI - let the UI update the model in a basic way, and have logic in your own object model (that has nothing to do with controls).
I use composition. I simply create a new UserControl and add the controls I need. This works fine, because:
I never use that many properties anyway, so pass-through methods are kept to a minimum.
I can start with a naive approach and refine it later.
Properties for look and feel should be set consistently across the site. Now I can set them once and for all.