I'm currently on a custom control that has a bunch of panels slaved to each other via databinding. And I ran into a bug where moving an element around would suddenly break the sync with the other panels. Nothing in the Output about data-binding failing, so i inspected it with Snoop to see that my data-binding had just up and gone away. So I tracked down the suspect code and monitored the data source with Mole as i stepped through and saw that the data-binding went away right after I set the dependency property.
Yeah, not really magic at all. A quick look at the Xaml showed that I had left this particular binding as default (i.e. OneWay). And if you have a OneWay binding and manually set the dependency property, the binding gets overwritten and goes away. Switching the binding to Mode=TwoWay restored my sync.
Just a quick note I learned the hard way when creating custom panels in WPF: If your panel has dependency properties or attached properties on its children that affect measure and/or arrange, calling InvalidateMeasure or InvalidateArrange won't necessarily do the trick. For that matter, calling these methods isn't even necessary. Instead use the FrameworkPropertyMetadata Metadata class to set appropriate FrameworkPropertyMetadataOptions.
So if you have a Dependency Property on your panel that affects the measure or arrange of its children, make sure it has FrameworkPropertyMetadataOptions.AffectsMeasure and/or FrameworkPropertyMetadataOptions.AffectsArrange set.
Similarily, if your panel has an attached property for its children, whose modification affects how that child is laid out, set FrameworkPropertyMetadataOptions.AffectsParentMeasure and/or FrameworkPropertyMetadataOptions.AffectsParentArrange.
Now layout and arrange are properly invalidated and called for you.
My current dev machine is running XP 64, which is a first for me. In the default setup IIS was not installed, so I went through Add/Remove Programs and installed it, which gave me IIS 6. This in turn has several tabs for ASP.NET, but try as you might none of these are what actually turns on ASP.NET and you just end up with mysterious 404s on a application enabled directory that's configured just like the working ASP.NET on your other machine.
Well, it turns out that ASP.NET (even though it shows up in the Properties tabs) is not installed by default and if you go to Web Service Extensions you won't see it there. So next, track down aspnet_regiis which is in the Framework directory and run
aspnet_regiis -i
Then go back to IIS Manager -> Web Service Extensions where ASP.NET should now be an available extension. Enable it and finally ASP.NET works.
Currently, a Silverlight Class Library cannot be loaded by the server side project and vice versa. This despite there being very close parity in the BCL on either side. Now, I agree that sharing actual business logic between client and server is a bit of an edge case, but when it comes to data interchange, having a single codebase for you DTOs would be very useful.
Luckily, with a bit of trickery, this can be accomplished, although it would be nice if Visual Studio could just do this for you. I've done this on two different projects, once creating DTOs that were then serialized using the JSON DataContract serializer and other other time using the normal XmlSerializer.
The basic trick is this: Two separate projects can point at the same source code files (and even the integrated source control providers will play along with this game). However, playing by Visual studio rules you can't just create two projects in the same directory because the wizards treats ProjectName == DirectoryName. Here's how you get around this:
Create a new server side Class Library, say Server.Dto.
Create a new Silverlight Class Library, say Silverlight.Dto.
Clean out that default Class.cs and update both to have the same default namespace Foo.Dto. Your solution should look something like this:
Now, right-click on Silverlight.Dto and choose Remove
Close Visual Studio
Rename the Silverlight.Dto/Properties directory to Silverlight.Dto/Silverlight.Properties
Copy Silverlight.Properties and Silverlight.Dto.csproj to the Server.Dto directory
Now, and this is the tricky bit, open Silverlight.Dto.csproj in some text-editor (notepad works, but don't try to use Visual studio for this) and change the line
Re-open your solution, right-click on the Solution in the Solution Explorer and choose Add -> Existing Project..., browse to Server.Dto and select Silverlight.Dto.csproj
Add your first shared class FooDto.cs to Server.Dto (if you add it on the Silverlight side, you need to clean up a bunch of using statements).
Select Silverlight.Dto and click the Show All Files button at the top of the panel. You should see FooDto.cs in Silverlight.Dto now
Right-click FooDto.cs and choose Include in Project, like this:
Voila, you now have two assemblies referencing the same code so that you can use the same code on both client and server sides. Just repeat the last couple of steps for every new class you want to share.
I know you could use a Web Service from within Silverlight and would automatically generate you the proxy on the client side. And I'd recommend that if your payload is dynamic. However, if your payload is generated occasionally by a server side program or periodic service, this methods lets you create Dto's, serialized in your favorite manner that can be consumed as static files with WebClient.
Interop with unix often requires dealing with Epoch or Unix time, or the number of seconds since January 1st, 1970 UTC. And if you throw java in the mix, then epoch becomes milliseconds, since they define System.currentTimeMillis() as the number _milli_seconds since the Epoch. Anyway, i figured, this was the perfect use of Extension methods. Well, almost... There's still the issue that getting a DateTime object from seconds requires a static method added to DateTime, which extension methods do not currently support. This means that instead of
Now i also added extensions on long and int but, really, that falls into the realm of stupid extension method tricks. I left them in there, only because they are part of DateTimeEx, therefore will only be available if the appropriate namespace is included and so is at least tangentially relevant in the current scope. Well, that's my rationalization, at least. With this extra extension method you now can do
The one thing to be aware of with all these helpers is that it always deals with UTC time, i.e. the DateTime that you convert to epoch time needs to have a DateTimeKind that is not Unspecified. Conversely, the DateTime you get back is UTC and if you want to deal with it with localtime, you need to call ToLocalTime() on it first.
Anyway, here's the class:
using System;
namespace Droog.DateTime
{
public static class DateTimeEx
{
public static DateTime FromEpochMilliseconds(long milliseconds)
{
return new DateTime(1970, 1, 1,0,0,0,DateTimeKind.Utc).AddMilliseconds(milliseconds);
}
public static DateTime FromEpochSeconds(int seconds)
{
return FromEpochMilliseconds((long)seconds \* 1000);
}
public static DateTime DateTimeFromEpochMilliSeconds(this long milliseconds)
{
return FromEpochMilliseconds(milliseconds);
}
public static DateTime DateTimeFromEpochSeconds(this int seconds)
{
return FromEpochSeconds(seconds);
}
public static int ToEpochSeconds(this DateTime dt)
{
return (int)(ToEpochMilliseconds(dt)/1000);
}
public static long ToEpochMilliseconds(this DateTime dt)
{
return (long)(dt.ToUniversalTime() - new DateTime(1970, 1, 1)).TotalMilliseconds;
}
}
}
In a world that is increasingly green, it is a waste of perfectly healthy computer cycles to interpret your code when you can use an optimizing JIT compiler to run your code.
I'm going to presume that's with tongue firmly implanted in cheek.
Outside of LINQ, i thought that 3.5 was a lot of cool but not vital syntactic sugar. This weekend marks the first time since November that I fired up VS.NET 2k5 to build an app targeting the 2.0 framework and I was amazed how much I'd already come to rely on that sugar. Now this might be seen as an invalidation of my preference of explicit, verbose syntax versus the terse syntax of many scripting languages. I'd like to point out that terseness and expressiveness in sytnax are two separate things. Syntactic sugar that let's me express my action in more concise code that easily conveys the meaning is not the same thing as using a terse vocabulary to keep the typing down and requiring memorization of abbreviated keywords to understand the code. Anyway, here are the parts of 3.5 I've missed more than once this weekend.
The plethora of extension methods on all things IEnumerable is largely due to LINQ, but the To* methods have become just a basic part of my vocubulary. Taking the Values of a Dictionary into an Array of the same type now is seems just painfully verbose without the ToArray() method. Compare
FileInfo[] f = new FileInfo[files.Count];
files.Values.CopyTo(f,0);
return f;
Now this I really thought of as frivolous. However, using objects that use DTOs as their initializer/storage, initialization does become rather awkward without loops or long constructors:
FileInfoData[] remoteFileData = new FileInfoData[]
{
new FileInfoData(),
new FileInfoData(),
new FileInfoData()
};
remoteFileData[0].name = "test1.mpg";
remoteFileData[1].name = "test2.mpg";
remoteFileData[2].name = "test10.mpg";
FileInfo[] remoteFiles = new FileInfo[]
{
new FileInfo(remoteFileData[0]),
new FileInfo(remoteFileData[1]),
new FileInfo(remoteFileData[2]),
};
versus
FileInfo[] remoteFiles = new FileInfo[]
{
new FileInfo(new FileInfoData()
{
Name = "test1.mpg"
}),
new FileInfo(new FileInfoData()
{
Name = "test2.mpg"
}),
new FileInfo(new FileInfoData()
{
Name = "test10.mpg"
}),
};
I needed to pass in a delegate to a function as a factory callback. Perfect scenario for a nice concise lambda. But I was in 2.0, so that meant defining a delegate and anonymous delegate syntax resulting ing
public delegate ILocalFileSystemManager LocalCreateDelegate(string localPath, string extension);
public class FileSystemManagerFactory
{
public FileSystemManagerFactory( LocalCreateDelegate localFactory )
{
this.localFactory = localFactory;
}
}
FileSystemManagerFactory factory = new FileSystemManagerFactory(
delegate(string localPath, string extension)
{
return new MockLocalFileSystemManager(localPath, extension);
});
instead of
public FileSystemManagerFactory( Func<string,string,ILocalFileSystemManager> localFactory )
{
this.localFactory = localFactory;
}
FileSystemManagerFactory factory = new FileSystemManagerFactory(
(localPath, extension)
=>
return new MockLocalFileSystemManager(localPath, extension);
);
If there is one feature of C# (well and java as well) that is the most code generated, it's getters and setters. I've never liked how code generation tools created those for me, since i liked having my private members in one place and Properties in another. So i've been typing them out for years. But with C# 3.0, we got automatic properties. The two patterns, read/write properties and read-only properties are oft repeated like this
string readwriteMember;
string readonlyMember;
public string ReadWrite
{
get { return readwriteMember; }
set { readwriteMember = value; }
}
public string ReadOnly { get { return readonlyMember; }
Not a ton of code, but certainly takes more time to write than
public string ReadWrite { get; set; }
public string ReadOnly { get; private set; }
Ho hum.. I'm in 2.0, so i'll have to deal, but I certainly hope that 3.5 has a fast pick-up rate on the client (on the server, I can still control my environment).
The last couple of nights I've been playing with some Linq to Sql and a whole lot of Linq to Objects and I have to say where coming up with complex Regular Expressions used to be one of my favorite puzzles, coming up with complex projections and transformations through Linq is quickly taking its place. Simple Linq is well documented, but when it comes to aggregation, it's a lot sparser. I expect to write more of that up once I feel more comfortable with the syntax.
In the meantime, I wanted to write up some non-obvious observation about deferred execution with Linq. Considering the gotchas with lambdas, it's easy to extend the lessons learned to linq, since it is after all deferred execution. But what's different with Linq is that, while execution is deferred, the expression tree built via a query is also immutable. I came across this trying to do some simple query re-use.
Let's start with a simple DTO:
public class Order
{
public Order(int id, int val, bool buyOrder)
{
Id = id;
Value = val;
IsBuyOrder = buyOrder;
}
public int Id { get; set; }
public int Value { get; set; }
public bool IsBuyOrder { get; set; }
}
And a set of this data:
Order[] orders = new Order[]
{
new Order(1,2,true),
new Order(2,2,false),
new Order(3,4,true),
new Order(4,4,false),
new Order(5,6,true),
new Order(6,6,false),
};
Let's split those into buy and sell orders:
var buyOrders = from order in orders
where order.IsBuyOrder
select order;
var sellOrders = from order in orders
where !order.IsBuyOrder
select order;
If we want to find the buy and the sell order with a value of 2, you'd think we could write one query and re-use it for both of those queries. Since both queries results in IEnumerable, how about we define a query source and assign the value of either above query.
IEnumerable<Order> orders2 = null;
var orderAtTwo = from order in orders2
where order.Value == 2
select order;
orders2 = buyOrders;
int buyOrderId = orderAtTwo.First().Id;
orders2 = sellOrders;
int sellOrderId = orderAtTwo.First().Id;
Console.WriteLine("buy Id: {0}, sell Id: {1}", buyOrderId, sellOrderId);
Since the query is deferred until we call .First() on it, that seems like a reasonable syntax. Except this will result in an System.ArgumentNullException because our query grabbed a reference to orders2 at query definition, even though the query won't be executed until later. Giving orders2 a new value does not change the original reference in the immutable expression tree.
A way around this is to replace the actual contents of orders2. However, for us to do that, we have to turn it into the query source into a collection first.
orders2.Clear();
orders2.AddRange(buyOrders);
int buyOrderId = orderAtTwo.First().Id;
orders2.Clear();
orders2.AddRange(sellOrders);
int sellOrderId = orderAtTwo.First().Id;
Console.WriteLine("buy Id: {0}, sell Id: {1}", buyOrderId, sellOrderId);
This gives us the expected
buy Id: 1, sell Id: 2
Let's put aside the awkwardness of clearing out a list and stuffing data back in, this code has another unfortunate sideeffect. .AddRange() actually executes the query passed to it, so we execute our buy and sell queries to populate orders2 and then execute orderAtTwo twice against those collections. The beauty of linq is that if you create a query from a query, your not running multiple queries, but building a more complex query to be executed. So, what we really want is query "re-use" that results in single expression trees at execution time.
To achieve this, we need to move the shared query into a separate method such as:
private IEnumerable<Order> GetTwo(IEnumerable<Order> source)
{
return from order in source
where order.Value == 2
select order;
}
and the code becomes:
int buyOrderId = GetTwo(buyOrders).First().Id;
int sellOrderId = GetTwo(sellOrders).First().Id;
Console.WriteLine("buy Id: {0}, sell Id: {1}", buyOrderId, sellOrderId);
This gives the same output as above, and we're only running two queries, each against the original collection. The method call means that we don't get to re-use an expression tree, since it builds a new one, combining the expression tree passed to it with the one it builds itself.
Here's a bit of code i just got through debugging...
public Point Point { get; private set; }
public void Offset(Point origin)
{
Point.Offset(-origin.X, -origin.Y);
}
Can you tell what's wrong here? Let's just say that the Offset won't take.
structs are value types, which means anytime you pass one around you get a new copy. So far so good. And that means when you expose a struct value via a property, the accessing party always is looking at a copy. Again, fine, after all when you do a set you change the stored value and if you need to manipulate it, you just manipulate the actual struct.
Enter Automatic properties and you might forget about this last detail and not realize that you never get access to the underlying value, even from within the class. I.e. when I call Point.Offset, i'm calling it on the copy that was passed to me and the resulting value is immediately thrown away. So i just went back to using the property to facade a private Point, which i can now manipulate inside of Offset. Duh.
