I'm new to CSS and am not entirely to sure how if I understand how classes work. Why is that even though I'm modifying the color of text for .testClass the change also applies to text in testClassing?
Related
New to Fluent UI React.
I have been tinkering around with the framework and read through all of its documentation that I can find. My understanding is that CSS-in-JS approach is encouraged when it comes to component styling. I see there are two ways to do so–via the styles prop and via the use of the mergeStyleSets utilities function + the className prop. Here is a codepen to illustrate what I mean here.
My question is, do they serve different use cases or are they pretty much the same? How do I decide which one to use? Thanks.
I've tried both and am leaning more toward mergeStyleSets because it gives me one way to predictably target everything and I don't have to learn the "magic class names" buried deep within each component and what it does or does not affect. Having said that, for certain key components, like DataGrid, there's a lot of styling involved and the classes exposed are not too difficult to learn and are helpful for getting the best out of those components.
This is particularly the case when you have to do selectors for things like "hover" or "active" or "before/after". Trying to get that working via magic class names exposed by "styles" was much more confusing for me than using the "mergeStyles" approach on the raw HTML directly.
So for me, I've been cherry picking from the framework, using it for color themes, elevation, and highly complicated components like DataGrid, but not for things like Stack or Stack Item.
I'm building a simple text editor that relies on Draft.js for decorating the text (mainly highlighting). I really like how simple it is to build a reliable input that has custom syntax highlighting.
However, I do not like the fact that I have to expose the entire editor state to do this. I'd prefer to have an editor that has just a value property that takes a string and passes a string trough the onChange prop.
This seems a reasonable thing to be able to do, yet I'm dumbfounded by how hard it is to transfer selection state.
Because of how draft.js is implemented, I find this hard to do. I need to create a new editorState based on the value prop every time it changes, which is doable, But it is hard to transfer selectionState between the old editorState and the new one because the selectionState relies on opaque identifiers that are unique to each state.
Has anyone tried to accomplish this? Is draft.js overkill for this an should I use a simpler solution that also works? I'm only using the decorators so I guess it would not be super-hard to just rebuild that part.
I’m trying to extend an Expander’s header (the ToggleButton part) to allow for some more custom features. Being rather new to extending WPF controls using ControlTemplates, I have already accepted by now, that I will have to completely replace the Expander’s template by my own (without being able to reuse originally defined components, or even styles, which makes this quite a bit annoying in my opinion – but that’s not what the question is about).
However, I wanted to introduce some properties which change the way the component looks and works. So I created a new subtype of Expander which simply defines the new dependency properties I want to use. But I noticed that, given that I want to use those properties within the template for the ToggleButton, which is nested inside of the one for the Expander, I cannot use those properties like that. So I had to subtype ToggleButton too, define the dependency properties for that type as well, and make the Expander’s template pass the values through to the ToggleButton template.
So I ended up with two new types in the namespace (nesting the new ToggleButton type inside of the Expander subtype didn’t work?), a complete copy of the Expander’s template with only a single line changed (where the ToggleButton was inserted, passing through the new properties), and then the actual desired changes for the ToggleButton template.
And here comes the question: Is there any way to make this less complicated? To reduce the amount of work that needs to be done just for extending a subcomponent of another’s template? Or just a way to use the parent’s (Expander) properties inside of the ToggleButton template without having to subtype that one as well?
I ended up using what jberger suggested in the comments:
Using the following binding expression I did not need to duplicate the DependencyProperties into another component for the ToggleButton, but could just access the Expander’s properties inside the nested template:
{Binding CustomProperty, RelativeSource={RelativeSource
FindAncestor, AncestorType=local:CustomExpander}}
Sadly, but as expected, one apparently cannot reuse template parts from the default. However in this case I could leave out parts from the original template that I didn’t need in my copy. For example the different styles for non-default expanding (i.e. other than Top), as my expander is specialized to that layout.
This however rendered the ExpandDirection property useless, but I personally can accept that. It might lead to a follow-up question though; if one should rather build the component from scratch (based on Expander’s base, instead of Expander itself).
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"];
I wanted to know which one amongst Style and UserControl would be better to use in WPF?
For example:
I have created an image button in two different ways.
One uses Style and ContentTemplate property is set.
It uses one other class with dependency properties.
The other way is I have created a UserControl which has a button and its content property is set.
The file UserControl.xaml.cs also contains the dependency properties.
For Code details see the answers of this question:
Custom button template in WPF
Which one would be better to use? In which scenario should one go for Style or UserControl or any CustomControl?
Styles are limited to setting default properties on XAML elements. For example, when I set the BorderBrush , I can specify the brush but not the width of the border. For complete freedom of a control’s appearance, use templates. To do this, create a style and specify the Template property.
Styles and templates still only allow you to change the appearance of a control. To add behavior and other features, you’ll need to create a custom control.
For example,
To create a button like a play button use styles and templates, but to create a a play button which will change its appearance after pausing it use UserControl.
For this type of thing I would go with Style, even though I'm not really adept with graphical tools. I tend to produce a basic, boring style that I can get started with and then prettify it once the application functionality has been verified.
The nicest thing about WPF is being able to distance much of the graphical look, feel and behaviour away from the code.
This allows you to change the style of your application without revisiting the code and indeed means that you can change styles on the fly at runtime.
There is an awkward line to tread with regards to how much behaviour is placed within the XAML and how much is placed within the code. A rough guide would be to decide on what behaviour must always be present within the UI and place that in the code, everything else place within the XAML.
Think of the code as being an abstract class with defined interfaces and the XAML Styles as being classes based on that class and you'll get an idea of what I mean.
Conversely, I know that people who are far more adept at the GUI work prefer to put more functionality in the XAML and others who prefer the code side, because they find the GUI work slow or difficult.
When thought of that way you'll see that there's never really a right or wrong answer, just better solutions that suit your skills.