C#, coding, development, threading, visual studio

Resolving A Dead Lock Is Your Number 1 Priority.

If your app deadlocks during development you might not want the added distraction. Surely you’ve got some feature which you need to get finished off in a hurry that your boss is pressurising you for. Maybe the screen deadlocking is something your colleague is working on, so you can just let them know and get back to the job at hand.

No.

You now know there’s a deadlock. Some deadlocks manifest readily. But others are a rare breed that only happen under rare circumstances, and perhaps even rarer on your CPU compared to those that you will deploy to. If you ignore this deadlock, it’s on your head.

The reality is: you just got lucky. Your team got lucky. You can resolve this problem here and now, without it escaping into the wild.

Stop what you are doing, forget what your boss wants you to do, or whatever task you think you need to do, and investigate the deadlock and knock the problem on the head.

Often I have heard developers say something like, “yeah, it deadlocks there sometimes”. Or worse, “yeah that’s the so-and-so’s code”. But they don’t stop to investigate. They just assume it’s someone-else’s responsibility

It can take time to resolve a deadlock. Sometimes they are pretty easy, but sometimes they can be complex beasts which take time to understand. Threaded code is more often tricky than not, and problems can be oh-so-subtle. But don’t shun it. Be a hero. Solve it.

Whenever I get a deadlock I immediately cease what I am doing. I pause Visual Studio (being my typical dev tool of choice) and put everything to one side. I won’t close the debug session until I am done. Is it half-five and I’ve got to pick the kids up? No problem. Visual Studio occasionally crashes during debug sessions but I have never had a problem when it is left paused. I’ll just leave it overnight, and come back to it with a fresh head in the morning.

I get the Call Stack up, get the Threads window open and sit there – sometimes just staring for long periods – and try and work through what’s happening. Often in large systems I’ll be working through vast swathes of code I’ve never seen before. There might be multiple context switches, some red-herrings, some code that is down-right ugly. Compiled libraries that you have to break open Refelector/dotPeek or browse Git source to understand. It can be hard, and it can take time: I’ve sat there for hours at a time trying to get things straight in my head, scratching notes on paper, perhaps even firing up another instance of Visual Studio to run through scenarios.

Maybe I’ll take a break, get a drink, some fresh air; but I won’t leave that debug session until I understand what’s causing the deadlock and how I’m going to go about fixing it.

Advertisement
.Net, C#, Design, Material Design, UI, UX, WPF, xaml

WPF Dialog Boxes In Material Design In XAML Toolkit

(Note this article refers to a pre-release version, which can be found on nuget provided pre-release versions are included in your search.)

Message boxes.  Ever a source of frustration in WPF.  MahApps has some nice dialog boxes to which I recently helped out with an MVVM API, but Material Design In XAML Toolkit can run with or without MahApps so I wanted a custom implementation which would meet these goals:

  • Look similar to the dialogs we see on Android phones
  • Have an API which is useable from XAML, code-behind, and MVVM
  • Provide full flexibility on the content of the dialog.

All software is evolution and after a reasonable attempt of doing something similar for a client – which ended up with a bit of a code-smell around callbacks from the API – I’ve come up some composable pieces which I hope are flexible, easy to use, and – most importantly – provide an attractive GUI 🙂

The cornerstone is the DialogHost control.  It’s a content control, meaning the underlying content over which the popup dialog will be displayed can be targeted; to a specific area of your app, or the entire Window content.


<md:DialogHost>
    <md:DialogHost.DialogContent>
        <dialogContent />
    </md:DialogHost.DialogContent>
    <mainContent />
</md:DialogHost>

When the dialog is open, the underlying content will be dimmed and disabled.

Material Design Dialog

DialogHost.DialogContent (associated with DialogHost.DialogContentTemplate) is your typical XAML content object property for setting the content of your dialog.  You can infer from this that you can use MVVM to bind content, but there are multiple ways of populating the content, showing the dialog, closing the dialog, and processing responses, so here’s a list of all the strategies for using the dialog (after the gif):

Material Design Dialog

Open Dialog Strategies

DialogHost.OpenDialogCommand

<Button Command="{x:Static md:DialogHost.OpenDialogCommand}" />

RoutedCommand typically used from a button where optional content can be provided via the CommandParameter.

DialogHost.IsOpen

<md:DialogHost IsOpen="True" />

Dependency property, to be triggered from XAML, set from code-behind or via a binding.  Content must be set in DialogHost.DialogContent.

DialogHost.Show

DialogHost.Show(viewOrModel);

Async/await based static API which can be used purely in code (for example from in a view model).  Content can be passed directly to the dialog.

Close Dialog Strategies

DialogHost.CloseDialogCommand

<Button Command="{x:Static md:DialogHost.CloseDialogCommand}" />

RoutedCommand, typically used on buttons inside the dialog, where the command parameter will be passed along to the dialog response.

DialogHost.IsOpen

<md:DialogHost IsOpen="False" />

Dependency property, to be triggered from XAML, set from code-behind or via a binding.

HANDLE CLOSE STRATEGIES

The DialogClosingEventHandler delegate is key.  It provides the parameter provided to DialogHost.CloseDialogCommand, and allows the pending close to be cancelled.

The following mechanisms allow handling of this event, via code-behind, MVVM practices, or just from the code API:

DialogHost.DialogClosing

<md:DialogHost DialogClosing="DialogHost_OnDialogClosing" />

Bubbling RoutedEvent, which could be used in code-behind.

DialogHost.DialogClosingAttached

<Button Command="{x:Static wpf:DialogHost.OpenDialogCommand}" md:DialogHost.DialogClosingAttached="DialogHost_OnDialogClosing" />

Attached property, which accepts a DialogClosingEventHandler which makes it easy to subscribe to the closing event in a more localized area of XAML.

DialogClosing.DialogClosingCallback

<md:DialogHost DialogClosingCallback="{Binding DialogClosingHandler}" />

Standard dependency property which enables the a DialogClosingEventHandler implementation to be bound in, typically from a view model.

DialogHost.Show

var result = await DialogHost.Show(viewOrModel, ClosingEventHandler);

The async response from this method returns the parameter provided when DialogHost.CloseDialogCommand was executed.  As part of the Show() signature a DialogClosingEventHandler delegate can be provided to intercept the on-closing event, just prior to the close.

More Examples

More complete usage examples can be found in MainDemo.Wpf which is part of the Toolkit solution, primarily in MainDemo.Wpf/Dialogs.xaml.

.Net, C#, Design, Material Design, UI, UX, WPF, xaml

Bending the WPF ProgressBar

There’s plenty progress loop controls around for WPF, but for Material Design In XAML Toolkit I really wanted to stick to “themeing” existing framework controls where-ever possible. Here’s examples of what were trying to achieve from Google’s own documentation, if you have an Android phone you’ll no doubt have seen these in action:

Before I tackled the style I spent a few weeks bouncing ideas around in my head.  To create the circular effect we’d have to dust off the trigonometry but I really wasn’t sure if I cold pull it all off inside a WPF Style, without creating a new control, or at least inheriting (yuck) from ProgressBar.  ProgressBar says it all.  It wasn’t really designed to go where I wanted it to go and whilst weighing things up I reflected into the ProgressBar.cs source:


//----------------------------------------------------------------------------
// File: ProgressBar.cs
//
// Description:
// Implementation of ProgressBar control.
//
// History:
// 06/28/2004 - t-sergin - Created
//
// Copyright (C) 2004 by Microsoft Corporation. All rights reserved.
//
//---------------------------------------------------------------------------

Okaaaayyy…so using the ever flexible WPF we are still taking something from 2004 and trying to theme it using 2015 design trends.  Should be fun!  There are a few TemplatePart’s which the code it expects – to draw a standard bar – but fortunately the control is also gracious enough to operate without them.

To create the looping progress ring thingy a simple arc path should do the job:

<Path>
  <Path.Data>
    <PathGeometry>
      <PathFigure StartPoint="?">
        <ArcSegment Size="?" IsLargeArc="?" Point="?" SweepDirection="Clockwise" />
      </PathFigure>
    </PathGeometry>
  </Path.Data>
</Path> 

But you’ll see from the attributes with a ? we’ve got 4 values we’ve got to complete:

  • PathFigure.StartPoint: pretty simple, start the arc at the top, on the middle of the X axis
  • ArcSegment.Size: easy again, this is the radius, so half the size of the control
  • ArcSegment.IsLargeArc: to draw anything over 180deg, this needs to be set to true. We’ll need a multiple values to figure out if we are over half way through progress: ProgressBar.Minumum, .Maximum, .Value
  • ArcSegment.Point: This is where from the StartPoint we need to draw our arc around to. Again we’ll need ProgressBar.Minumum, .Maximum, .Value, and with the wonders of trigonometry we can figure this out.

No worries though, we can wrap all of these little calculations in a bunch of IValueConverter and IMultiValueConverter implementations.  In reality then, bending a straight progress bar into a circle is pretty simple.  The PathFigure – now, peppered with a bunch of value converters – looks a bit like this:


<PathFigure StartPoint="{Binding ElementName=PathGrid, Path=ActualWidth, Converter={StaticResource StartPointConverter}, Mode=OneWay}">
<ArcSegment Size="{Binding ElementName=PathGrid, Path=ActualWidth, Converter={StaticResource ArcSizeConverter}, Mode=OneWay}" SweepDirection="Clockwise">
<ArcSegment.IsLargeArc>
<MultiBinding Converter="{StaticResource LargeArcConverter}">
<Binding RelativeSource="{RelativeSource TemplatedParent}" Path="Value" />
<Binding RelativeSource="{RelativeSource TemplatedParent}" Path="Minimum" />
<Binding RelativeSource="{RelativeSource TemplatedParent}" Path="Maximum" />
<Binding ElementName="FullyIndeterminateGridScaleTransform" Path="ScaleX" />
</MultiBinding>
</ArcSegment.IsLargeArc>
<ArcSegment.Point>
<MultiBinding Converter="{StaticResource ArcEndPointConverter}">
<Binding ElementName="PathGrid" Path="ActualWidth" />
<Binding RelativeSource="{RelativeSource TemplatedParent}" Path="Value" />
<Binding RelativeSource="{RelativeSource TemplatedParent}" Path="Minimum" />
<Binding RelativeSource="{RelativeSource TemplatedParent}" Path="Maximum" />
<Binding ElementName="FullyIndeterminateGridScaleTransform" Path="ScaleX" />
</MultiBinding>
</ArcSegment.Point>
</ArcSegment>
</PathFigure>

(I don’t think WordPress wants to format that…)

We’re not done there though.  Material Design has extra animation flourishes to provide the extra pzazz.  If you look at the determinate loop in the video above, you’ll see that the whole ring is rotating in addition to drawing out the arc representing completion.  Something, a bit like this:

ProgressRingDoubleRotate

By applying a RotateTransform to the Path itself, and using yet another converter to calculate the rotation according to the percent of completion we can pretty close to the Google effect.


<Path.RenderTransform>
<TransformGroup>
<RotateTransform x:Name="RotateTransform" CenterX="{Binding ElementName=PathGrid, Path=ActualWidth, Converter={StaticResource RotateTransformCentreConverter}, Mode=OneWay}" CenterY="{Binding ElementName=PathGrid, Path=ActualWidth, Converter={StaticResource RotateTransformCentreConverter}, Mode=OneWay}">
<RotateTransform.Angle>
<MultiBinding Converter="{StaticResource RotateTransformConverter}">
<Binding RelativeSource="{RelativeSource TemplatedParent}" Path="Value" />
<Binding RelativeSource="{RelativeSource TemplatedParent}" Path="Minimum" />
<Binding RelativeSource="{RelativeSource TemplatedParent}" Path="Maximum" />
</MultiBinding>
</RotateTransform.Angle>
</RotateTransform>
</TransformGroup>
</Path.RenderTransform>

I’ve actually built further animation storyboards on top of this to try and get close to the indeterminate effect.  It’s not quite perfect yet, but close enough for what I released in version 1.0 of Material Design In XAML Toolkit.  Here’s a gif of how things were looking in that release:

Progress Loops

And, in keeping with my original challenge of staying close to the original .Net Framework controls, usage is pretty straight forward:


<ProgressBar Style="{StaticResource MaterialDesignCicularProgressBar}" Value="50" />

To see it in action run up the demo project which is part of the main source.

The actual final style can be found here:

https://github.com/ButchersBoy/MaterialDesignInXamlToolkit/blob/master/MaterialDesignThemes.Wpf/Themes/MaterialDesignTheme.ProgressBar.xaml

And – as there are a whole bunch of converters – they warrant their own namespace here:

https://github.com/ButchersBoy/MaterialDesignInXamlToolkit/tree/master/MaterialDesignThemes.Wpf/Converters/CircularProgressBar

.Net, C#, Design, Material Design, UI, UX, WPF, xaml

Version 1.0 of Material Design In XAML has arrived!

Well, this project kinda came out of nowhere, but has proven to be pretty popular and I’ve really enjoyed getting it to this state: version 1.0!   It’s officially a non-alpha, non-beta, totally live thing!!

I’ve cranked up my contributions over the last month to push it over the line for its for first official release, recently adding runtime palette switching via the PaletteHelper/Swatch API, a new ColorZone control to help you design your layouts, and more granular control of ripples and shadows.  A few styles and animations have also been tweaked to really improve the look and feel.

To go with version one I’ve completely re-worked the demo app, as illustrated in the video.  It’s really worth checking, it might just give you some inspiration for your WPF apps!

And if you haven’t seen I recently launched a new home page for the project: materialdesigninxaml.net, which includes a Get Started section.

There’s still plenty more to come for both Material Design In XAML and Dragablz but I will be treating myself to a little break for a week or two!

Material Design, react.js, UI, UX

React.js and Material Design Lite

I’m a bit of a React.js fan lately, and with the arrival of Google’s Material Design Lite, I decided to combine them for a little project I’m throwing together.  Turns out to be pretty easy.  To simplify the Getting Started, you need to include a .css and .js file in your page:

<link rel="stylesheet" href="https://storage.googleapis.com/code.getmdl.io/1.0.0/material.grey-blue.min.css" />
<script src="https://storage.googleapis.com/code.getmdl.io/1.0.0/material.min.js"></script>

…and then show a Material Design button using the following class names:

<button class="mdl-button mdl-js-button mdl-button--raised mdl-button--accent mdl-js-ripple-effect">
  Button
</button>

The small gotcha for using templating techniques for dynamic pages such as with React.js is that for buttons, and other items, dynamically added you need to call a bit of script to upgrade the button:

//where button is your DOM element
componentHandler.upgradeElement(button, 'MaterialButton');

But when we come to create our React class, that’s easily handled in componentDidMount, leaving my Material Design Lite button class looking like this:

var MdlButton = React.createClass({
	handleClick: function() {
		this.props.onClick();	
	},
	render: function() {
		return (
			<button ref="btn" className="mdl-button mdl-js-button mdl-button--raised mdl-button--accent mdl-js-ripple-effect"
					onClick={this.handleClick}>
				{this.props.content}
			</button>
		);
	},
	componentDidMount: function() {
		componentHandler.upgradeElement(React.findDOMNode(this.refs.btn), 'MaterialButton');		
	} 
});

One small thing to note is the second arg to upgradeElement where we are passing in ‘MaterialButton’. As of now the docs aren’t overly clear on this, but it’s the name of the Javascript function object defined in the source. So, if we want to create a check box React class we can dig in to the Material Design Light source code in GitHub, and confirm that we’d pass ‘MaterialCheckbox’ into upgradeElement.

No doubt the community will provide a full library for this in time, but it doesn’t take much to combine these two libraries.

.Net, C#, RX

Dealing with RX Exception, “Failed to start monitoring system clock changes”

With some pain we recently uncovered a risk in using Observable.Timer(...) in Reactive Extensions.

The system is a WPF real-time trading system, utilising RX heavily.  Some of our users access the system via Citrix, and it was these users who first started experiencing the issue.  Sporadically a thread pool callback would cause the system to crash with an unhandled exception.  The exception being thrown from inside RX:


System.InvalidOperationException: Failed to start monitoring system clock changes.
at System.Reactive.PlatformServices.PeriodicTimerSystemClockMonitor.NewTimer()
at System.Reactive.PlatformServices.PeriodicTimerSystemClockMonitor.TimeChanged()
at System.Reactive.Concurrency.ConcurrencyAbstractionLayerImpl.PeriodicTimer.Tick(Object state)
at System.Threading.TimerQueueTimer.CallCallbackInContext(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.TimerQueueTimer.CallCallback()
at System.Threading.TimerQueueTimer.Fire()
at System.Threading.TimerQueue.FireQueuedTimerCompletion(Object state)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()

Being on Citrix I started hypothesising that this might be some kind of CPU load issue. Then we had another “normal” desktop user encounter the exception. Her application kept crashing and upon investigation I found another process on her 4 core box taking 25% CPU. Killing that process-which seemed to have gone rogue-suddenly cleared our application of the RX error. So again, it pointed to CPU bound slowness.

The actual RX source which throws the exception can be seen here, inside the NewTimer method.

If you use Observable.Timer(...) RX will internally create a new PeriodicTimerSystemClockMonitor instance and subscribe to its SystemClockChanged event. And this class creates a timer to raise the event. Everytime this timer calls back into TimeChanged a time threshold is checked. If the callback was too slow, a new timer will be generated within NewTimer. Again, the length of time it takes to create this timer is checked. If the SYNC_MAXDELTA milliseconds threshold is broken, another attempt is made. The loop allows for 100 attempts. If after this time the timer hasn’t been created within the allowed time threshold the offending InvalidOperationException is thrown.

At which point your application will die.

It took a few attempts of reading the code before I understood this; it is not immedietely easy to get this set-up in debug. I wanted to add some logging to give us an idea of how slow the timer recreation was. To achieve this I had implement a custom IPlatformEnlightenmentProvider (and set via: PlatformEnlightenmentProvider.Current = new CustomPlatformEnlightenmentProvider(); ), which unfortunately involved some reflection so I could instantiate existing classes internal to RX. But now I am able to get RX to use a ConfigurablePeriodicTimerSystemClockMonitor where I can get some logging going and experiemnt with the time thresholds.

The two classes are at the end of the article. The important thing is I can see when RX decides the callback is too slow and that a new timer is required. And then, when the exception is finally thrown inside NewTimer, I can see how slow the timer creation operation was:

if (n >= _syncMaxRetries)
{
    _logger.Warning("Failed to start monitoring system clock changes (Configurable Impl). diff={0}", diff);
    throw new InvalidOperationException(
        "Failed to start monitoring system clock changes (Configurable Impl).");
}

With all this in place I sat back and waited for the crash reports to come in. The first exception report looked like this:

Failed to start monitoring system clock changes (Configurable Impl). diff=489.0552

So in this case, a call which RX wants to happen within 10ms is taking nearly half a second. As of writing I have questions outstanding with our Citrix team, CPU usage/spikes/load, mem etc. I am also pondering other things: did a gen2 GC collect kick in? What other process are running? Do we also have a memory leak? etc etc. Perhaps clutching at a few straws 🙂

So what’s next?

I’ve got options, mainly two, but I don’t particularly like either:

  • Make the time check much more relaxed. But how relaxed? There is no line in the sand here…
  • Remove all usages of Observable.Timer. And stand guard over every developers’ check-ins for the application’s lifetime?!

Right now we are still contemplating our next step, collating information. I’ll try an update this post with our final approach. I will also try and solicit a response from the RX team for their opinion on this.

UPDATE: Solution From Microsoft

Kudos to the RX team at Microsft who very quickly came back with a possible solution. There’s a couple of gotchas, but its very workable. The suggestion is to “create a custom system clock monitor using SystemEvents.TimeChanged“.

So we rely on the Win32 event to notify RX of changes to the system clock, instead of the more complicated PeriodicTimerSystemClockMonitor which has all the time checks and constraints at the root of the problem we are seeing.

There’s a couple of small issues:

  • We will still have to use our custom IPlatformEnlightenmentProvider, which uses reflection to instantiate RX internal classes. This leaves us slightly vulnerable to future re-workings to the innards of RX. UPDATE: dealt with; see UPDATE 2 below.
  • The solution requires a message pump (which apparently is why RX doesn’t use this method by default). Luckily for us, being a WPF application, we have one.

So I’ve created a new class:

public class SystemEventsSystemClockMonitor : INotifySystemClockChanged
{
    private int _refCount;
    private EventHandler<SystemClockChangedEventArgs> _systemClockChanged;

    public event EventHandler<SystemClockChangedEventArgs> SystemClockChanged
    {
        add
        {
            AddRef();
            _systemClockChanged += value;
        }
        remove
        {
            RemoveRef();
            _systemClockChanged -= value;
        }
    }

    protected virtual void OnSystemClockChanged(SystemClockChangedEventArgs e)
    {
        var handler = _systemClockChanged;
        if (handler != null) handler(this, e);
    }

    private void AddRef()
    {
        if (Interlocked.Increment(ref _refCount) == 1)
        {
            SystemEvents.TimeChanged += SystemEventsOnTimeChanged;
        }
    }

    private void RemoveRef()
    {
        if (Interlocked.Decrement(ref _refCount) == 0)
        {
            SystemEvents.TimeChanged -= SystemEventsOnTimeChanged;
        }
    }

    private void SystemEventsOnTimeChanged(object sender, EventArgs eventArgs)
    {
        OnSystemClockChanged(new SystemClockChangedEventArgs());
    }
}

Then inside our CustomPlatformEnlightenmentProvider I can return it when asked inside GetService. I haven’t reflected that change in the implementation listed below so beware, understand what’s happening, and choose your INotifySystemClockChanged implementation wisely before using this in your system…

UPDATE 2: Slight improvement…

I’ve only just spotted that the RX factory method CurrentPlatformEnlightenmentProvider.GetService() is marked as virtual. So I can inherit from this, override and provide my custom class where applicable. This resolves any issue I had regarding reflection. Now the enlightenment provider is pretty simple:

public class CustomPlatformEnlightenmentProvider : CurrentPlatformEnlightenmentProvider
{
    public override T GetService<T>(object[] args)
    {
        var t = typeof(T);
        if (t == typeof (INotifySystemClockChanged))            
            return (T)(object)new SystemEventsSystemClockMonitor();            

        return base.GetService<T>(args);
    }
}

Happy days…

Customised RX classes, from before Microsoft proposed solution, which were used during investigation:

public class CustomPlatformEnlightenmentProvider : IPlatformEnlightenmentProvider
{
    private readonly ILogger _logger;
    private readonly bool _useCustomImplementations;

    public CustomPlatformEnlightenmentProvider(ILogger logger)
    {
        if (logger == null) throw new ArgumentNullException("logger");
        
        _logger = logger;

        _useCustomImplementations = Session.IsRunningRemotely || Debugger.IsAttached;
        if (_useCustomImplementations)
            _logger.Info("Platform enlightenment will run ConfigurablePeriodicTimerSystemClockMonitor.");
    }

    public T GetService<T>(params object[] args) where T : class
    {
        var t = typeof(T);
       
        if (t == typeof(IExceptionServices))
        {
            var type = Type.GetType("System.Reactive.PlatformServices.ExceptionServicesImpl, System.Reactive.PlatformServices", true);                
            return (T)Activator.CreateInstance(type);
        }

        if (t == typeof(IConcurrencyAbstractionLayer))
        {
            var type = Type.GetType("System.Reactive.Concurrency.ConcurrencyAbstractionLayerImpl, System.Reactive.PlatformServices", true);                
            return (T)Activator.CreateInstance(type);
        }

        if (t == typeof(IScheduler) && args != null)
        {
            switch ((string)args[0])
            {
                case "ThreadPool":
                    return (T)(object)ThreadPoolScheduler.Instance;
                case "TaskPool":
                    return (T)(object)TaskPoolScheduler.Default;
                case "NewThread":
                    return (T)(object)NewThreadScheduler.Default;
            }
        }

        if (t == typeof(INotifySystemClockChanged))
        {
            return (T) (_useCustomImplementations
                ? new ConfigurablePeriodicTimerSystemClockMonitor(
                    TimeSpan.FromSeconds(1), 
                    _logger,
                    syncMaxRetries: 100,
                    syncMaxDelta: 10)
                : (INotifySystemClockChanged) new PeriodicTimerSystemClockMonitor(TimeSpan.FromSeconds(1)));
        }


#if HAS_TPL46
        if (t == typeof(ITaskServices))
        {
            return (T)(object)new TaskServicesImpl();
        }
#endif

        if (t == Type.GetType("System.Reactive.Linq.IQueryServices, System.Reactive.Linq"))
        {
            //
            // We perform this Debugger.IsAttached check early rather than deferring
            // the decision to intercept query operator methods to the debugger
            // assembly that's dynamically discovered here. Also, it's a reasonable
            // expectation it'd be pretty hard to turn on interception dynamically
            // upon a debugger attach event, so we should make this check early.
            //
            // In the initial release of v2.0 (RTM), we won't have the corresponding
            // debugger assembly available yet, so the dynamic load would always
            // fail. We also don't want to take the price of (an attempt to) a dynamic
            // assembly load for the regular production case.
            //
            if (Debugger.IsAttached)
            {
#if NETCF35
                var name = "System.Reactive.Linq.QueryDebugger, System.Reactive.Debugger";
#else
#if (CRIPPLED_REFLECTION && HAS_WINRT)
                var ifType = t.GetTypeInfo();
#else
                var ifType = t;
#endif
                var asm = new AssemblyName(ifType.Assembly.FullName);
                asm.Name = "System.Reactive.Debugger";
                var name = "System.Reactive.Linq.QueryDebugger, " + asm.FullName;
#endif
                var dbg = Type.GetType(name, false);
                if (dbg != null)
                    return (T)(object)Activator.CreateInstance(dbg);
            }
        }            

        return null;
    }
}

public class ConfigurablePeriodicTimerSystemClockMonitor : INotifySystemClockChanged
{
    private readonly TimeSpan _period;
    private readonly ILogger _logger;
    private readonly SerialDisposable _timer;

    private DateTimeOffset _lastTime;
    private EventHandler<SystemClockChangedEventArgs> _systemClockChanged;

    private readonly int _syncMaxRetries = 100;
    private readonly double _syncMaxDelta = 10;
    private readonly int _maxError = 100;

    /// <summary>
    /// Creates a new monitor for system clock changes with the specified polling frequency.
    /// </summary>
    /// <param name="period">Polling frequency for system clock changes.</param>
    /// <param name="logger"></param>
    /// <param name="syncMaxRetries"></param>
    /// <param name="syncMaxDelta"></param>
    /// <param name="maxError"></param>
    public ConfigurablePeriodicTimerSystemClockMonitor(TimeSpan period, ILogger logger, int syncMaxRetries = 100, int syncMaxDelta = 10, int maxError = 100)
    {
        if (logger == null) throw new ArgumentNullException("logger");

        _period = period;
        _logger = logger;
        _syncMaxRetries = syncMaxRetries;
        _syncMaxDelta = syncMaxDelta;
        _maxError = maxError;

        _timer = new SerialDisposable();
    }

    /// <summary>
    /// Event that gets raised when a system clock change is detected.
    /// </summary>
    public event EventHandler<SystemClockChangedEventArgs> SystemClockChanged
    {
        add
        {
            NewTimer();

            _systemClockChanged += value;
        }

        remove
        {
            _systemClockChanged -= value;

            _timer.Disposable = Disposable.Empty;
        }
    }

    private void NewTimer()
    {
        _timer.Disposable = Disposable.Empty;

        double diff;
        var n = 0;
        do
        {
            _lastTime = SystemClock.UtcNow;
            _timer.Disposable = PlatformEnlightenmentProvider.Current.GetService<IConcurrencyAbstractionLayer>().StartPeriodicTimer(TimeChanged, _period);
            diff = Math.Abs((SystemClock.UtcNow - _lastTime).TotalMilliseconds);
        } while (diff > _syncMaxDelta && ++n < _syncMaxRetries);

        _logger.Info("Took {0} attempts to start new timer.", n);

        if (n >= _syncMaxRetries)
        {
            _logger.Warning("Failed to start monitoring system clock changes (Configurable Impl). diff={0}", diff);
            throw new InvalidOperationException(
                "Failed to start monitoring system clock changes (Configurable Impl).");
        }
    }

    private void TimeChanged()
    {
        var now = SystemClock.UtcNow;
        var diff = now - (_lastTime + _period);
        if (Math.Abs(diff.TotalMilliseconds) >= _maxError)
        {
            var scc = _systemClockChanged;
            if (scc != null)
                scc(this, new SystemClockChangedEventArgs(_lastTime + _period, now));

            _logger.Warning("Clock Monitor exceeded max error, initiating new timer. Vars: now={0}, _lastTime={1}, diff={2}", now.ToString("O"), _lastTime.ToString("O"), diff);

            NewTimer();
        }
        else
        {
            _lastTime = SystemClock.UtcNow;
        }
    }
}

 

.Net, C#, MahApps, UI, WPF, xaml

Using MahApps Dialog Boxes in a MVVM Setup

Finally, after a couple of years of take, take, take; I’ve made a contribution to MahApps.  Working in a financial institution it’s not always easy to commit back to open source projects, so with a little bit of out-of-hours work I’ve solved a little problem I’ve seen a few people asking: “how do you use MahApps dialog boxes in an MVVM setup?”  And now my conscience is clear. 😉

Now You Can Launch a Dialog Box From a View Model.

There’s a couple of simple things you have to do:

1) Use an attached property in your Window to register your view model with the dialog sub-system.

Assuming your View’s DataContext is set to the view model from where you want to launch the dialog, add these attributes:


<Controls:MetroWindow 

        xmlns:Dialog="clr-namespace:MahApps.Metro.Controls.Dialogs;assembly=MahApps.Metro" 
        Dialog:DialogParticipation.Register="{Binding}"
 >

2) Grab & Use DialogCoordinator to open dialogs.

You can instantiate DialogCoordinator directly, or, good citizens will probably want to inject in the interface IDialogCoordinator into their view model.  This will play nicely with TDD, and is agnostic to whatever DI framework you may be using.

Without a DI framework you could just do something like this:


new MainWindowViewModel(DialogCoordinator.Instance);

Opening up a dialog from your view model is now easy, using the IDialogCoordinator instance.  To most methods the first parameter named “context” will typically be your view model.  This is how the coordinator will match the view model to the window (with what was registered in step 1) and display the dialog.  If you have multiple windows open, the dialog will display on the correct window.  Show your dialog from inside your view model just like this:


_dialogCoordinator.ShowMessageAsync(this, "Message from VM", "MVVM based dialogs!")

If you want to see this in action and follow the code through open up the MahApps MetroDemo project (part of the MahApps source code), and launch from the “Dialogs” Menu:

Dialogs via MVVM in MahApps
Dialogs via MVVM in MahApps

This should make it into release 1.2.0.

Design, Material Design, UI, UX

Open Sourcing a Logo

Open source doesn’t have to just apply to code.  I’ve been applying my XAML skills to Material Design In XAML Toolkit to help other developers quickly craft good looking user interfaces in WPF.  I’m pretty happy with the results, and in some of my own projects I’ve produced some striking applications using the toolkit.  Despite doing this, I readily admit I’m no designer.  For such a visually focused code library I really wanted a logo, but knew I could never do the task justice.

So I threw the task out to the community.

I created an issue on GitHub, tweeted a bit, posted on Reddit.  And waited.  Pretty much bang on 2 weeks later a result came back from a young guy called Sam, and I’m really happy with it:

Material Design In XAML Toolkit

Sam or “snalty” can be found on Twitter, and you can see some of his other designs on his blog.

In summary, a great bit of collaboration helping to push Material Design In XAML Toolkit further along.

.Net, C#, Material Design, UI, UX, WPF, xaml

Material Design Themed TimePicker and Clock Controls for WPF

I’ve managed to get the existing WPF controls; DatePicker & Calendar themed as part of Material Design in XAML Toolkit as described in this blog post.

But the fun part was cranking a couple of brand new controls to build the Material Design time picker experience:

  • TimePicker
  • Clock

These are sibling controls to the existing DatePicker and Calendar controls.  I wanted to keep the API experience similar so you can dive straight in without any kind of learning curve.  The Clock can be used in isolation, or use the DatePicker for an easy picker/popup/drop down behaviour.

Here’s a static glimpse at the picker:

Material Design Time Picker

And here’s a gif of the clock in action:

Material Design Clock Demo

There’s nothing complicated about using these, but you will need to get Material Design In XAML Toolkit referenced and set up in your app. Follow the initial tutorial, and head over to GitHub to download the source/examples project.

.Net, C#, Material Design, UI, UX, WPF, xaml

Material Design DatePicker/Calendar Style for WPF

Howdi,

After a bit of toil I have the DatePicker and Calendar WPF control styles done for Material Design in XAML Toolkit. I hope you guys like it!

(Edit: TimePicker & Clock now also available, blogged here)
Material Design templates for DatePicker/Calendar primitive controls.
Material Design templates for DatePicker/Calendar primitive controls.

Please note that the behaviour is not quite identical to that which you might see on Android. These are templates for the existing WPF DatePicker and Calendar primitive controls, and thus, some of the behaviour around month/year selection is driven by the nature of those controls. There is no modal dialog, as I don’t want these templates to get confused with any requirement/API used to manage dialogs in WPF.

I must say that I believe that it is testament to the original design of WPF/XAML – which is now a mature technology – that I could slot these styles in pretty much seamlessly for a control whose code base is around 8 years old. Note that some extra code has gone in to the Material Design Toolkit, bit this is wrapped inside the new templates and thus if you consume these templates you need never concern yourself with it.

Getting started:

If you haven’t taken a look at Material Design in XAML Toolkit yet (or indeed Dragablz) here is a blog post to get started, or download the source from GitHub and fire up the demo projects:

  • MaterialDesignColors.WpfExample
  • MahMaterialDragablzMashUp

Thanks due: