PrimordialCode

Recently I’ve been asked to build a proof of concept of an application involving the use of a webcam and a microphone to record some streams and elaborate them after.

At first I’ve tried with the new Silverlight support for webcam and microphone...it’s extremely easy to obtain the raw streams of data from both the devices...but after that you’re left to yourself: no support for whatsoever compression or multiplexing algorithm (I looked around and found nothing suitable to my needs) and due to the short time available I had to give up on Silverlight.

I started to look at what I could use on a WPF/C# solution, we have more options here:

• Wrapper libraries over the good old (and complex to use) DirectShow
• Windows Media Encoder 9
• Microsoft Expression Encoder

All these 3 technologies do the job, but DirectShow and WME (which actually have the richest set of features) are no more supported (or will be dropped soon), they also aren’t managed assemblies.

So I decided to go for the ‘new’ Expression Encoder (also a new version should be out in the next months); it turns out that it’s quite simple to use...from my 2 days of experiments it turns out that it have 2 big problems:

1. The lack of a good documentation and samples...what you have on MSDN is quite frankly poor compared to the standard documentation we’re used to have from Microsoft
2. Although it’s very ‘easy’ to use it still lack some of the features WME have...but I hope they will be integrated in the future release.

Enough talking, I’ll just post you some snippets from the demo application I’m building, here’s the class I started with to access and encode the streams coming from the webcam and the microphone:

public class EncodingService : IDisposable
{
   readonly LiveJob _job = new LiveJob();


                
            

In the past month I was working on some cool new features to extend this blog engine:

• Dynamic Pages - to add some basic CMS-like capabilities to Dexter.
• Better Windows Live Writer experience - to manage more details in blog posts and in dynamic pages, you can now create, update and delete both posts and pages directly in WLW.
• A Silverlight 4 Back Office project - I really don’t like to do data entry in Asp.net :).

The first two new features will be added to the Trunk shortly - they are currently under test in my own blog - so let’s give those two beauties a look, here’s how the lower property bar of WLW looks like when dealing with Posts:

• You can have a full hierarchical view of all the categories you have in your blog (and you can add new ones).
• You type in the keywords/tags associated with a post in the keyword box (it has auto-complete support).
• You can the specify a date for the post (even a future one, in this case the publication will be deferred).
• You can specify the Slug (that will be used in the post address) or leave it blank and let Dexter auto-generate it for you.
• You can specify an Abstract for the Post or let Dexter auto-generate it for you.

We now have support for creating/modifying and deleting Dynamic Pages directly in Windows Live Writer:

In the lower property bar you can specify:

• A parent page for the current page you’re editing.
• A page order to decide how the pages are sorted in the same level.
• The Slug (that will be used in the post address) or leave it blank and let Dexter auto-generate it for you.

To modify or delete a page just push the open button and select ‘pages’ in the Open dialog window; you can then select a page and edit it or delete it:

Here’s a screenshot of the new dynamic menu in action:

In this screenshot the tabs: ‘About’, ‘Resources’ and ‘Tools and Utilities’ are dynamic pages.

To check the full source code of this project navigate to our CodePlex page: Dexter Blog Engine

Related Content

• A Windows Live Essentials Suite Beta is out...hot to workaround the ‘no internet connection’ setup problem (26/08/2015)
• A Windows Live Essentials Suite Beta is out...how to workaround the ‘no internet connection’ setup problem (26/08/2015)
• PrimordialCode is now powered by the open source Dexter Blog Engine (03/08/2010)
• QuiBrowser.it powered by Dexter Blog Engine (26/08/2015)
• Build: Windows 8 (26/08/2015)
• More related document (9)

Yesterday a friend of mine showed me some WPF code: he defined a transformation in XAML and was trying to alter it at runtime changing part of its transformation matrix (he was doing that substituting the scale transform matrix as a whole); he kept trying but he never saw any result (the object was always rendered with the same dimensions).

I looked at the code and at first I was surprised too to not see it working as expected, I gave him a quick explanation (which, in all honesty, I have to admit it was partially wrong :D) and suggested another way to alter the things that worked.

Later on I had time to double check the things and found what was my wrong assumption...but let’s start from the beginning.

Here’s a snippet of the XAML he posed me:

...
<Ellipse x:Name="spinningWheel" Width="128" Height="128" Canvas.Left="64" Canvas.Top="64" RenderTransformOrigin="0.5,0.5">
  	<Ellipse.RenderTransform>
		<TransformGroup>
			<ScaleTransform x:Name="spinningScaleTx" CenterX="0.5" CenterY="0.5"/>
			<SkewTransform/>
			<RotateTransform/>
			<TranslateTransform/>
		</TransformGroup>
  	</Ellipse.RenderTransform>
...

I was playing around with the DataForm control offered by the Silverlight 4 Toolkit and I realized it’s missing an IsEditing property I could have used to bind to other interface elements (and disable them while I am editing something in the DataForm).

This property will be especially useful if you use the DataForm with the AutoCommit property set to false: in this case you cannot change the CurrentItem while you are in edit mode, because the control itself will throw an exception.

Adding this property isn’t too hard because the control offers a couple of events (BeginEdit/EndEdit) you can use as a starting point. So, in my first attempt, I derived a new DataForm control, added a new IsEditing DependencyPropery and overridden the OnBeginningEdit() and OnItemEditEnded() function to set the property to the correct values.

It worked, but I had a subtle problem: the OnBeginEdit() is fired the first time when you click on the form (and you can disable the rest of the interface, but if you have AutoCommit set to false and you do not want to edit nor change the item anymore you have no way to have the EndEdit fired, because to fire it you need to switch the focus to another control...but all your interface is now disabled...and you are stuck! You are forced to edit something to be able to cancel the operation).

Solving this problem wasn’t totally hard, all you need to do is to change the IsEditing property only when you are interacting with editing controls or when the underlying bound object gets changed; so I’ve wired my state changes to the OnKeyUp() of the DataForm and to the PropertyChanged() event exposed by the bound object.

The resulting class worked quite well: the IsEditing property gets changed every time you type something in an control or when you change a property of the bound objet without keyboard interaction (like using a Slider or with a DatePicker control).

Here’s the code for the ‘new’ DataForm.

public class CustomDataForm : DataForm
{
   #region "IsEditing"
   
   public bool IsEditing
   {
       get { return (bool)GetValue(IsEditingProperty); }
       set { SetValue(IsEditingProperty, value); }
   }


                
            

Ladies and Gentlemen, DotNetMarche and UgiAlt.NET are proud to introduce to you this very interesting initiative: an entire day devoted to Object Relational Mapping, NHibernate and related technologies.

It will take place next Fall in Italy on 9th October; for more info and details check this post, the official NHDay website and follow us on twitter (tag #nhday).

The event is open to everyone, even non Italians, cause almost all the sessions will be presented in English; if you are interested and want to attend or contribute head to the website and get in touch with us.

Related Content

• The NHibernate Day is coming...this Saturday! (10/06/2010)
• #nhday - after event thoughts (10/11/2010)
• NHibernate - First impressions on ConfORM (26/08/2015)
• NHibernate - Customize the Linq provider to call your user defined SQL functions (10/01/2010)
• Hands on ConfORM: mixed mapping techniques (26/08/2015)
• More related document (21)

Let’s move on to the next step and remove all the code on the view that is directly related to the commands the user can give through buttons. To do so we use a new feature of Silverlight 4: Commanding.

Since the release of Silverlight 2 the runtime offered a class -ICommand- that we could use to implement a commanding framework. WPF had a full implementation of a commanding framework while in Silverlight it was completely left to the user (a couple of solutions can be found on the web).

With the release of Silverlight 4 every control that derive from ButtonBase now expose two new properties - Command and CommandParameter - you can use in binding with an ICommand object allowing for a declarative approach when it comes to respond to click events raised by those controls; we can now implement a pure form of MVVM without having to rely on external frameworks.

There are some good resources available out there about the basics of commanding in Silverlight, here are two of them:

SILVERLIGHT 4'S NEW COMMANDING SUPPORT

5 Simple Steps to Commanding in Silverlight

However we will follow a slightly different approach...ICommand is an interface, so it is well suited to be used with an IoC container :D. Defining our own set of commands - be it by registering them with names or by defining new interfaces that derive from ICommand and registering them - we can leave to the container the responsibility to configure the ViewModels with the actual instances of those commands that will be later on used with binding.

This opens up for a lot of possibilities: you can control the lifetime of a command object through the container (transient or singleton, allowing you to share the behavior if needed) and you can ‘spam’ the same command in different sections of your interface easily (binding to the same property of the ViewModel); even better you can use AOP techniques to add behaviors to your commands (like logging or tracing abilities to have some usage stats of you application).

Let’s see a first time implementation; let’s define a base class for our commands:

public abstract class BaseCommand : ICommand
{
    bool canExecuteCache;