Interface Blogs

Just back from a wonderful ten days in Tokyo. Enough material to blog about for weeks: amazing food, wonderful sights, terrific people. And don't even get me started on the toilet technology. The one we had in the Mandarin Oriental had so many bells and whistles I'm only hoping it remembers Asimov's 3 laws of Robotics when it becomes self aware, or someone's in for a world of hurt.

At one point I was wandering through Akihabara (the famous electronics district) and on the sixth floor of LAOX, wandered into their technical book section.

Nice to see Web 2.0 is just as much in fashion over there (if not more so):

They had a full section of Japanese .NET books. 

I've been learning written Japanese lately - I'm still spectacularly bad at it, but curious to see how well I could understand a technical book, I grab one - and the first one I grab turns out to be written by Interface's very own Dan Wahlin:

There's something just very groovy about that.

I'm very fond of the Flash work of Yugo Nakamura, and several years ago I remember seeing a mouse tracking application of his that was simple yet strangely addictive, so I decided to use it as inspiration for this next test:

WPF/E Mouse Tracking (WPF/E Required)

This is a bit more involved than the Egg Timer, as it incorporates ASP.NET AJAX PageMethod calls to save (and retrieve) mouse tracking information (for multiple visitors) - it's hopefully quite simple to understand.

Hit "record", record a few seconds of your own mouse movements, and that's it. Then hit "play", and watch your wonderful handiwork replay itself.

I've got a few more places I want to take this, but thought I'd throw it up there and see how it works out.

NOTE: The link is now updated from a WPF/E example to a 1.0 Silverlight example - Simon.

Well, after a while you get sick of "Hello World" for your first applications.

I thought I'd make my Silverlight learning experience public, so if you have Silverlight installed, take a look. I wanted a two-minute timer for all my GTD "less than two minute" tasks, so I wrote one.

Silverlight Egg Timer

More examples coming soon.

This was a bit of a head-scratcher. I was experimenting with multiple animations (for the sake of argument, let's say two: "upAnim" and "downAnim") in a simple WPF/E application, and could get them to work - but not repeatedly. They'd both work - just once - and then only the one declared last in the XAML would be callable. Switch 'em around, same behavior. They'd both work once, then only the one declared last would run again.

(Strangely, the "completed" event of the non-playing animation would still fire, and at the correct time, i.e, if the animation was supposed to take five seconds, the event would fire after five seconds even though the animation didn't play.)

The answer is this: make sure to explicitly stop any other playing storyboards before starting a new one. (Yes, even if the first one stopped an hour ago.) So instead of just calling the Begin method of the storyboard, call:

sender.findName("downAnim").Stop();
sender.findName("upAnim").Begin();

That should do the trick.

(Note: just read on a Microsoft board that you should start the new one before stopping the old one - this seems counter-intuitive to me, and my examples seem to work either way, but just passing it on.)

If you're using the WPF/E XAML export feature in the new beta of Expression Design, be aware that it generates what looks like an old schema reference in the Canvas element:

xmlns= " http://schemas.microsoft.com /winfx/2006/xaml/presentation"

However, in the Visual Studio 2005 WPF/E project type, it's

xmlns=" http://schemas.microsoft.com/
client/2007"

The old one won't stop your WPF/E from working, but it will stop you from getting intellisense in VS2005. I'd been working through several examples, all starting off with WPF/E from Expression Design and some old art files of mine and just thought "Oh, I guess we're not getting intellisense in this build".

*Sigh* Suffice it to say life is a lot easier without having to continually experiment and cross-reference back to the somewhat lacking WPF/E reference on MSDN.

If you're working your way through the ins and outs of ASP.NET AJAX, you'll probably come across the ScriptMode property of the ScriptManager. And it's fairly easy to see what the options are.

Now, that's all very well when they're including debug and release versions of the AJAX Extensions themselves, but what does it mean for your own scripts? If I have my own debug and release versions, what do I call 'em, and where do I put 'em? Well, the answer's fairly simple.

If you make a simple external "test.js" file, and add a ScriptReference to it, like so:

If you then add ScriptMode="debug" (which you can do either on the ScriptManager or as a property of the ScriptReference element) all it does is add "debug." to your file name, before the j.s. So "test.js" just becomes "test.debug.js", an easy way of having a place for all your debug.trace and debug.traceDump calls that you don't want in the finished version.