As an example, let's say we wanted to listen to the MediaElement's BufferingProgressChanged event, but we want to stop listening once buffering has exceeded 50%. The following code does work:
.. but this code will never unsubscribe from the event:
When not using a quoted string to specify the event handler, you have to save the value returned from addEventListener. The return value is a token that is "just an integer value to track the order in which handlers were added for each object-event combination" (read MSDN for other subtleties in the event registration methods).
A proper unsubscribe looks like the following:
You can still detect a double click using a mouse up event handler and a timestamp - but should you? The omission of a double-click event wasn't because of a technical limitation – the omission is a deliberate design decision. Silverlight is built for the web, and many consider double-clicking on the web to be a usability no-no.
Here is what Peter Chng has to say:
I'll admit that while I was first confused by this action, I thought little of that user's comment - I mean, how hard can it be to learn a simple action like that? But, after some more thinking, I've come to agree with the comment - breaking the pattern of how a user navigates on a website is not a good idea, even if it's done to try to make your website feel more like a desktop application.
The New York Times website includes a feature that launches a search (in a pop-up window) when you double click a word inside an article. Digital Inspiration believes this behavior is user unfriendly, while Dion thinks the feature is a bug.
You might also have noticed the only mouse button events in Silverlight are LEFT mouse buttons events. Edit (I haven't kept up with changes in the other lifestyle...)
Macs don't have a right mouse button, and my guess is they never will (adding one now would be like admitting defeat). Exposing a right-click event could only invite more usability problems.
Silverlight has some wonderful potential. Just remember to innovate – don't aggravate.
Phil dug up an old post of mine on conditional compilation, but defining a constant in web.config didn't appear to work for him. I didn't see anything wrong with his approach, so I downloaded the solution and did some spelunking.
With this page ...
... and this web.config ...
... then the page behaves as if only the QUUX is defined.
To understand the scenario I added <compilation debug="true"> to the web.config. Debug settings leave behind a .cmdline file in the temporary ASP.NET files directory. The .cmdline file contains the exact commands to invoke the C# compiler, and the abbreviated form looked like this:
I went in thinking the compilerOptions would be additive, but after a smack on the forehead, I realized the compiler options in the @ Page directive override the web.config compiler options. Remove the compilerOptions attribute from the @ Page directive and BAZ becomes defined.
The behavior does seem to follow the principle of least surprise, even if it did catch us off guard.
Consider the following diagram to track the votes in a contest. Each voter can register only one vote (a score from 1 to 4) for each contest entry.
For any given voter, you'll want to present a screen showing every entry in the competition, along with the score assigned to the entry by the voter (if a score exists). To fetch the data with SQL, I'd write something like:
The query should yield a resultset like the following:
EntryID EntryName VoterID Score 13 EntryA 1 4 14 EntryB 1 2 15 EntryC 1 NULL ...
I thought the query would be difficult to express in LINQ, but I stumbled into a solution just by keeping a "SQL" mindset:
The LINQ generated SQL looks amazingly similar to the hand generated SQL, which is a comforting sight!
Most server-side applications run on machines under our control. We know what the application's environment will look like long before deployment.
Building and packaging an ASP.NET application to deploy inside of any corporate firewall is a bit more challenging. Here are a few lessons I've learned from five years of building a commercial web app.
I'll blog again as soon as this little operation finishes....