In follow up to the problem I’ve been running into with StringFormat in Silverlight…. yes, there really is a bug with it. Tim Heuer blogged about it a little more. Check out his post StringFormat and CurrentCulture in Silverlight for a workaround.
As I write more Silverlight code, I get more frustrated with its quirks.
Let’s say I have an app that’s tracking GiveCamp participation. Let’s say that my foreign friends over in Europe organized a GiveCamp, to add an international factor. Now let’s say that we’re tracking the number of devs working on projects each hour. And let’s make a Silverlight app for that!
The daily chart may show the number of devs, broken by hour. On the X axis, I’ll see time in my familiar “8:00 PM” format. My foreign friends should see that same time as “20:00”. I set the StringFormat property on my DateTimeAxisLabel (from the Silverlight Toolkit) and it works wonderfully.
But let’s say I want to add a tooltip to each point to show the time (IndependentValue) and number of devs (DependentValue). I toss a couple of TextBlocks in my ToolTip template, using StringFormat to format them. These are the same format strings that I use on my axes, so they should respond similarly, right? That’s what I would’ve expected.
But as I run my internationalized app, I see “8:00 PM” in my tooltips, and so do my foreign friends! Wait… what?!?
Time to add code to get internationalization working properly, since WPF and Silverlight aren’t getting it right out of the box.
So here’s my call to the WPF/Silverlight teams – please, for the love of doing what’s right – have the StringFormat formatting default to the CurrentCulture rather than to its current default culture (en-US). It only seems natural for an app to run on its CurrentCulture, unless the developer specifies otherwise.
The Microsoft response to this Connect ticket by closing it as “By Design” really disappoints me. I can only hope that the Visual Studio team wakes up and realizes the importance of having WPF and Silverlight apps default to the CurrentCulture from an internationalization point of view. This “feature” of defaulting to “en-US” is more of a headache for those of us who do develop for an international audience and probably is just as much of a headache for my developer friends who aren’t in an en-US culture.
Just my 2 cents, from a frustrated Silverlight dev…
As I’ve been working on a major Silverlight project recently, I was talking with some app devs, who kindly reminded me that I can’t account for every click and every end user behavior. But I’m determined to user-proof my app as much as I can. I want the user experience to be as enjoyable as possible. (Yes, a UX tie… this is a Sarah on User eXperience – SUX – post in disguise.) These are just some of the considerations that I’ve been thinking about wh
ile working on my out-of-browser (OOB) Silverlight app.
How do I handle OOB behavior when the app is in-browser?
Silverlight in the browser really gets cranky when it sees those Application.MainWindow calls. So I’ve had to make sure that OOB-specific calls are hidden away well enough that the in-browser side doesn’t see them. Of course, there’s the Application.IsRunningOutsideOfBrowser Property – very handy for checking if the app is running OOB first before making those calls.
Of course, if the app is starting in the browser, some other things to consider include:
- An in-browser interface. What’s the app going to do while it’s in-browser?
- How will the end user install the app? Do you have them right-click on the app and install from the Install menu or do you add functionality to the in-browser app and use the Application.Install Method?
Sometimes, things appear in the SUX (Sarah on User eXperience) series because they work contrary to my expectations. Silverlight is one of those things.
For a web technology, Silverlight is more an app developer’s domain than a website developer’s domain. It really requires an application development train of thought. In these past few weeks, I’ve been working on a Silverlight app and running into quirks that probably wouldn’t have thrown me off if I spent more time writing apps rather than websites. However, I typically focus on websites more than apps, which is a slight paradigm shift. So imagine the frustrations I ran into with Silverlight, thinking that a web technology would be aligned with the web train of thought.
For one, they don’t do margins the web way. Margins in the web world – think CSS attributes – are top-right-bottom-left. Margins in an app world (and in the Silverlight realm) are done left-top-right-bottom.
Another thing that required a little searching was finding a dropdown box. Yes, as a website developer, I’m used to the terms dropdown, DropDownList, or even the old <select> lists. But as I look at my toolbox, I’m not seeing any of those terms. Ah… but there’s ComboBox, similar to the control I was familiar with back in my VB 6 days. Ugh… another app term, not the web developer term.
The last grumbling I have on this is the lack of transparent window support. Transparent PNG supported was enhanced in Silverlight 4, which I really like. But there still isn’t any support for transparent windows. On this project, we would’ve loved to have a transparent window, especially on an out-of-browser app. Sure, we could’ve done this in WPF, where transparency is supported. But WPF on a Mac isn’t supported – Mono doesn’t have plans on implementing it. Silverlight, on the other hand, is supported on Macs, which is why we planned going this route. Until they port transparent window support from WPF into Silverlight, we’ll work with the technology constraints and go with a custom chrome. But transparent windows would be awesome!
Thankfully, I’m getting around Silverlight a lot better than I anticipated, but I still need to remember that I need to treat it like an application tool and not necessarily a web development tool. Don’t get me wrong – it is a web technology after all. But first and foremost, it is a subset of an application development tool, not a web development tool. Once I get that through my head, I understand why they went this route.
While playing around with Silverlight 4 and working on my demos for my talk on Tuesday at the Cleveland WPF User Group, I came across a peculiar situation.
I’ve got a webcam demo and wanted to see just what I could do with it to add my touches to it. Of course, being the curious one, I had to wonder… “What if I denied access to my devices? How does this really work?”
My setup, for reference:
And the permissions:
From what I was able to find out in my testing, it looks like the permissions work properly when in the browser (using Google Chrome). However, when I run this as an out-of-browser app, it looks like the permissions are getting ignored.
Here’s my app in the browser:
And when it’s outside of the browser, I get this:
Is this really how these permissions are supposed to be working? Am I missing something? As an end user, if I told an application not to use my webcam but installed it to my desktop for other cool features (maybe an enhanced Twitter client or something), I wouldn’t want it to access my webcam.
* Edited 5/16/2010, 1:32AM Eastern Time*
So after seeing Dave Swersky‘s comment and looking into some other configurations, this is what I found out:
- Webcam/mic permissions apply in-browser as expected
- Webcam/mic permissions apply as expected when out-of-browser without elevated permissions.
- Explicit webcam/mic deny permissions are being ignored when out-of-browser with elevated permissions.