-
-
I don't know about you, but I hate (with a passion) blinking/flashing/rotating junk on web pages when I'm trying to do research. The distraction is bad enough, but Flash is a big security problem (so I've been told--I've never personally had a problem with it) and takes time and bandwidth on my very limited pipe to the rest of the world.
I use FireFox as my daily browser (IE, Chrome, and Safari for testing), and have installed the Flashblock add-on in FireFox. It's a miracle! No more Flash (unless I want it). This add-on allows you to choose, on every page, whether to display the Flash content or not. Pages load faster, there's no distractions, and no Flash stuff unless I need it. If you're interested, the link is here:
https://addons.mozilla.org/en-US/firefox/addon/433
-
-
In general, it's no problem to modify WPF resources at runtime. You can use the TryFindResource method to search the same path as the XAML parser, given a starting point, and a name for the resource. like this:
Button btn = (Button)sender;
var brush =
(SolidColorBrush)(btn.TryFindResource("TextBrush"));
if (brush != null)
{
brush.Color = Colors.Red;
}
The problem comes in trying to modify application-level resources. In order to optimize for performance, application-level resources are frozen (that is, their IsFrozen property is set to True), so WPF "knows" that it doesn't need to monitor them for changes. What if you want to modify one one of these resources? That requires cloning the resource, making changes, and then applying it, like this (this example attempts to swap the colors in a RadialGradientBrush). One note: Because this code actually changes the content of the resource, in order for the markup to "notice" the change, the resource must be declared as a DynamicResource in the markup (as opposed to the more common StaticResource):
Button btn = (Button)sender;
RadialGradientBrush brush =
(RadialGradientBrush)(btn.TryFindResource("BackgroundBrush"));
if (brush != null)
{
// Swap the colors in the RadialGradientBrush:
Color color = brush.GradientStops[1].Color;
if (brush.IsFrozen)
{
// If it's frozen, you must create a copy,
// modify it, and then apply it. This requires the
// consumer of the resource to be dynamic.
RadialGradientBrush newBrush = brush.Clone();
newBrush.GradientStops[1].Color =
brush.GradientStops[0].Color;
newBrush.GradientStops[0].Color = color;
Application.Current.
Resources["BackgroundBrush"] = newBrush;
}
else
{
brush.GradientStops[1].Color =
brush.GradientStops[0].Color;
brush.GradientStops[0].Color = color;
}
}
-
-
Currently working on courseware for both Silverlight and WPF concurrently (perhaps not the wisest recent decision). My theory was (and note the past tense) that they both use XAML to describe their UIs, so how far apart could they be? I have spent the better part of a week creating a simple (actually, not simple at all) demo project to show off some of the simple controls in WPF and Silverlight (you know the drill: Button, TextBox, Slider, CheckBox, RadioButton--all the old favorites). Turns out that the behavior is very, very different between WPF and Silverlight, often in mystifying ways. Things that work in one environment aren't available in the other. The cut-down .NET Framework in Silverlight is far more limited than you would imagine (although it seems like a miracle that it works at all.)
My suggestion, if you're creating an app that you want to run both in WPF and Silverlight (and I'm not sure why anyone except courseware authors would do this): Create the Silverlight version first. Because its behavior is so limited, you're better off converting from Silverlight to WPF than the other way around. Beware, however, that some things work in Silverlight and not in WPF, so there are issues no matter which direction you go. (For example, in Silverlight, the MediaElement control will play a WMV file stored as a resource in the current project. I cannot get the WPF version to play the video--I ended up using an external file path instead.)
Do not fall into the trap: WPF and Silverlight may look and feel similar, but in fact, they're very different, with distinct issues and learning curves.