C# .NET

Winform Progress Bar Marquee Style Not Working

Tim Huffam — Wed, 22 Jul 2009 02:19:52 GMT

When trying to run a .Net winforms app with a progressbar on it, I found that if it was run from a non-standard class, the marquee style did not work.

The reason was because we were running the app from our own loader class, instead of the usual winforms program.cs. This was because we were instatiating it from VB using COM interop - I thought this was the cause of the issue - but it turns out that this is not the case...

The problem was that our own loader class did not enable the windows XP visual styles (apparently the Marquee style is only supported on platforms later than and including Windows XP - with visual styles enabled).

So the solution (to make the Marquee style work) is to include the following line of code before instantiating your form:

Application.EnableVisualStyles();

HTH
Tim

Async web service/WCF calls updating the UI on the UI thread (using WinForms)

Tim Huffam — Wed, 08 Jul 2009 02:56:40 GMT

To update the UI with values returned from an asynchronous WCF/web service call you need to make sure the coding updating the UI is running on the UI thread. Depending on how you've performed the async remote service call, often this is done on another thread - so when the handler executes upon completion of the call it is not on the UI thread and causes a threading exception.

Within winforms, the solution is to use the Invoke() method eg the following method would be on your form or user control and could be safely called from the async service call handler:

public void UpdateCustomerName()
{
if (this.InvokeRequired)
{
    this.Invoke(new EventHandler(delegate
      {textBox1.Text = presenter.Customer.Name;}));
}
else
{
    textBox1.Text = presenter.Customer.Name;
}
}

If you're using something like the MVP pattern (in winforms) then you could make your presenter base class provide some generic handling for it with these 2 members:

protected delegate void UIDeligate();/// <summary>
/// Invokes the specified method in the UI thread. This is useful for executing view methods, that update the UI, from an asynchronous callback handler in the presenter.
/// Eg: <code>OnUIThread(new Presenter<ITestView>.UIDeligate(View.BindCustomers));</code>
/// </summary>
///
/// <example>
/// The folling code executes the view method BindCustomrs() in the UI thread.
/// OnUIThread(new Presenter<ITestView>.UIDeligate(View.BindCustomers));
/// </example>
/// <param name="method">Method to invoke.</param>
protected void OnUIThread(UIDeligate method)
{
if (disposed) return;
Control control = View as Control;
if ((control != null) && (control.Created))
control.Invoke(method);
else
method.DynamicInvoke();
}

These allow your presenter to handle the thread synchronization for you (as it would be the one handling the the callback processing). In this case your UI method, in your form or usercontrol, would look like this:

public void UpdateCustomerName()
{
textBox1.Text = presenter.Customer.Name;
}

and the presenter implementation class would call it like this:

public void customerService_CustomerUpdate(object sender, EventArgs<Customer> e)
{
customer = e.Data;
// Previously we would have done:
// View.UpdateCustomerName();
// but now we do this:
OnUIThread(new Presenter<ITestView>.UIDeligate(View.BindLivingExpenseRates));
}

So now the view does not need to care about any threading/async issues.

You could also use the <methodname>Async method and <methodname>Completed event in the generated WCF client proxy - as from what I've seen the <methodname>Completed event magically executes on the UI thread (have no idea how/why). See this article for a good example.

HTH
Tim

Turning on code coverage/instrumentation in a TFS Build

Tim Huffam — Wed, 17 Jun 2009 04:32:14 GMT

This requires a testrunconfig file that has been configured correctly. To do this I did the following:

In VS2008, right click on Solution Items folder and select Add - New Item...
Select Test Run Configuration and enter the name WithCodeCoverage.testrunconfig.
Open/edit this file in VS.
Select the 'Code Coverage' item on the left, then selected (checked) the assemblies I wanted to instrument
Click Apply to save these changes.

Note that you can select which is the active test run configuration from under the Test menu in VS2008.

Now we need to update the TFS build...

Open your TFS build file (eg TFSBuild.proj)
In the section starting with
<PropertyGroup>
<!-- TEST ARGUMENTS...
Add the following line (after the comments and before the closing of PropertyGroup):
<RunConfigFile Condition=" '$(IsDesktopBuild)' != 'true' ">$(SolutionRoot)\DEV\Release1\Source\WithCodeCoverage.testrunconfig</RunConfigFile>
(update accordingly to suit your build server paths).

That's it. Queue a build to test - you may need to verify your server build paths to get it working (I did).

HTH
Tim

How to turn on unit testing in your TFS build

Tim Huffam — Wed, 17 Jun 2009 03:54:27 GMT

The following will make your builds (running on a TFS Server) execute your unit tests after the build:

Open your build file (eg TFSBuild.proj). VS2008 has a nice xml editor for this.
Search for the RunTest node and change it from:
<RunTest>false</RunTest>
to:
<RunTest>true</RunTest>
Look for a section that starts with:
<ItemGroup>
<!-- TEST ARGUMENTS ...
and add nodes within this (after the comments and before the closing of the ItemGroup node) - one entry for each unit test assembly you have eg:
<TestContainer Include="$(OutDir)\My.App.UnitTests.dll" />

Thats it - check in this file and queue a build.

An error I got while getting this working indicated that the MSTest.exe could not be found - this was because TFS Client had not been installed on the build server - once these were installed it worked fine.

Something else you may want to do is ensure that a build is triggered every time someone checks in. To do this, edit your build definition (right click on your build within Team Explorer and choose "Edit Build Definition...") - click on the 'Trigger' item in the list on the left and make sure the "Build each check-in (more builds)" item is checked.

HTH
Tim

How to unit test against resources (localization) values within Visual Studio 2008

Tim Huffam — Fri, 22 May 2009 21:07:55 GMT

When unit testing you sometimes need to test that values are being set to the correct literal/constant value - and this value is often stored in a resources file.

However, for some reason the VS2008 'Create Private Accessor' feature did not work for me for resources (maybe be cause they're all static properties and the generated _Accessor classes need to be instantiated). So to make these resource available within the unit test project I simply made the Resources class public (by default it's internal).

To do this:

Open the resource file (eg Resources.resx) using the Visual Studio resource editor tool (just double click on the .resx file).
At the top of the editor tab there is a drop down box labelled "Access Modifier" - change this from Internal to Public and save the file.
Rebuild the project.

Your resources will now be accessible in your unit tests.

HTH
Tim

Script to remove unchanged files in TFS/VS2008

Tim Huffam — Thu, 22 Jan 2009 21:31:34 GMT

TFS has a wonderful feature whereby it marks files as changed, even though there are no changes. These files show up in the Pending Changes window in Visual Studio (VS 2008).

To work around this, add the following external command to your VS tools:

First you need to install TFS Power Tools
In VS go into Tools - External Tools and click Add
Enter the following details:
Title: Unchange
Command: C:\Program Files\Microsoft Team Foundation Server 2008 Power Tools\tfpt.exe
Arguments: uu /recursive /noget
Initial Directory: $(SolutionDir)
And check 'Use Output Window'
Click Ok

That's it. To test, view the Pending Changes window - usually after a 'Get Latest' is when it lists unmodified files as changed - then click Tools - Unchange.

Thanks to Duncan Smith for this gem of info.

The fact they created a tool for this makes you wonder!

HTH
Tim

How to move/drag objects in Silverlight (2.0)

Tim Huffam — Wed, 05 Nov 2008 18:24:43 GMT

The following code shows you how you can make Silverlight controls/objects moveable by dragging them with the mouse.

Page.cs:

<UserControl x:Class="MovingObjs.Page"

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

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

Width="400" Height="300">

</Grid>

</Border>

</Canvas>

</UserControl>

Page.xaml.cs:

namespace MovingObjs

{

public partial class Page : UserControl

{

private bool moving = false;

private double offSetX;

private double offSetY;

public Page()

{

InitializeComponent();

}

private void brdMovable_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)

{

moving = true;

Point offset = e.GetPosition(brdMovable);

offSetX = offset.X;

offSetY = offset.Y;

}

private void brdMovable_MouseLeftButtonUp(object sender, MouseButtonEventArgs e)

{

moving = false;

}

private void brdMovable_MouseMove(object sender, MouseEventArgs e)

{

if (moving)

{

Canvas parent = (Canvas)this.brdMovable.Parent;

Point p = e.GetPosition(parent);

double x = p.X - offSetX;

double y = p.Y - offSetY;

txtBlkTest.Text = "X: " + x.ToString() + ", Y: " + y.ToString();

this.brdMovable.SetValue(Canvas.LeftProperty, x);

this.brdMovable.SetValue(Canvas.TopProperty, y);

}

How to remove TFS workspaces

Tim Huffam — Thu, 09 Oct 2008 14:10:29 GMT

This will actually remove the your workspaces - unlike the VS/TFS Source Control Explorer which simply does not display them - duh!

From the VS command prompt:

tf workspaces /remove:*

ASP.NET SQL Server error: The connection was not closed. The connection's current state is open

Tim Huffam — Tue, 09 Sep 2008 17:48:33 GMT

The following error occured when 2 requests hit an ASP.NET (2.0) web app (using SQL Server 2005) at the same time:

The connection was not closed. The connection's current state is open

Normally this only occurs if you have a connection that is not being closed. However in our case all connections where being closed using a try-finally block (personally I prefer using a using block).

This error only occured when the 2 request were initiated from different machines.

It turns out that the error occured because the same username was being used for all requests (we were not interested in the username in the app - and simply validated the request through a token and set the username to the same static string for all requests). As soon as we made the username unique (by appending a guid to it) the error ceased to occur.

This indicates that ADO.NET uses the username as part of it's connection pooling management.

*** UPDATE 17 Nov 08 ***
After more testing we proved this theory incorrect. We found that the root cause of the original exception (connection state is open) was because we used a static member in one of our ORM classes - this held on to the connection, and it never got closed (hence the exception) - once we converted this to a non-static variable the problem disappeared. However, adding the GUID to the ASP.NET username did have the above mentioned affect in several scenarios - which still leads me to believe the username has some relation/use in the connection pooling management (not sure why - as it's the process's identity that things run as - not the user's).

HTH

Tim

Task Oriented Programming

Tim Huffam — Tue, 09 Sep 2008 05:10:06 GMT

For some time I've been wondering if there's a better way to program business logic. Years ago I used to write COBOL, then moved onto a 4GL, bla bla bla... and today I find myself well entrenched in OO with Microsoft's .Net. Development times don't seem to be much better these days - and the complexity of things seems to have mushroomed.

We went from barely-a-3GL to 4GL back to 3GL plus an explosion of things you need to consider. We started with procedural code then moved to OO and seem to have got stuck there. But somehow I think we need to revise our use of OO. Business logic is predominantly procedural code - even if written in OO; it starts, follows a process, performing stuff until finished eg Customer.UpdateCreditLimit()

OO is really good for modelling things - as per the classic OO examples of a bicycle or car. And thus they model business things quite well too - like an Invoice or a Customer.

However, I've found that the more object oriented the code gets - the less productive, maintainable and flexible it becomes. Not saying leave OO - far from it - it's brilliant. It's just that we need to learn when to say 'when'. The use of patterns has helped a huge amount - but these can also caused similar problems - when being applied where they aren't really needed - resulting in overly complex software (read: inflexible and unmaintainable and unproductive). It's a fine line - and it's not easy to get the balance.

A major break through in this area is LINQ. This has meant we have less clutter in our apps catering for ORM (brilliant). This has resulted in code very similar to the old 4GL days (essentially 4GLs were just SQL based code anyway) - where all you care/code about is the business logic - caring not a jot about how or where a Customer or Order got created - and in this age of SOA - that becomes more important (as a Customer could come from many different sources - local RDBMS, company ERP, external CRM etc). I guess you could say LINQ allows you to focus your code to be more domain specific (not saying it's a DSL).

I have been playing with workflows for donkeys of years and found that although the individual workflow systems themselves can range from very simple to incredibly complex - the individual tasks they perform need not be. This had lead me to start thinking about applying this principle to code design at a reasonably low level.... what if we developed tasks as objects. Each task has just one job (I've heard some people say this is how objects 'should' be coded anyway). It has properties that can be get/set. Keeping things dead simple, eg:

public class AdderTask
{
    public int Addend1 { get; set; }
    public int Addend2 { get; set; }
    public int Result { get; set; }
    public AdderTask(int addend1, int addend2)
    {
        Addend1 = addend1;
        Addend2 = addend2;
    }
    public AdderTask Execute()
    {
        Result = Addend1 + Addend2;
        return this;
    }
}

To run this you'd simply do this:

int result = new AdderTask(1, 2).Execute().Result;

Exposing the task's properties means you can build up get and set statements - and because the Execute method returns the task object itself you can easily use it in a single line as if it was a method on it's own - or retrieve it's property values after the Execute (these tasks would easily be adapted to work within a workflow system).

This style lends itself to expanding; rather like building blocks, you can build large workflows out of these task oriented blocks. The workflows themselves coded just like these tasks - whereby all the business logic resides within the Execute() method.

Adding LINQ to the mix takes this to the next level - allowing you to build software that is simple to develop and understand.

I've been building a sizable system using this technique and I'm finding that I'm converting code developed using standard OO practices over to this methodology as it makes code more easily reused - but most importantly: easier to read and maintain.

In summary:

All input and output parameters should be implemented as properties (getter and setter accessors).
Provide a constructor that accepts all required parameters. A default constructor (with no parameters) is optional (I've found I never need these - but if you were to use these tasks in a workflow system they may need this).
Provide an Execute() method that takes no parameters and returns the object instance eg return this;
The object should clean up after itself.

Other notes:

Originally I created a similar type of class for workflows - but I found that these ended up being no different in concept to tasks. Likewise I've found that some tasks needed to call other tasks - so I've ended up just implementing everything as tasks. On reflection this is actually quite valid - because, as I found when building large orchestrations using Biztalk, workflows become atomic tasks themselves when used within the context of a large orchestration (which may run many workflows and external tasks) - and the orchestration, from a highlevel could also be considered an atomic task.
I've found using System.Transactions.TransactionScope great for scoping transactions around many tasks when creating a macro task that runs many sub tasks.

Suggestions/comments very welcome - I'd like others to expand or comment on this.

Tim