29 March, 2010

Recursive treeview population

As I always seems to forget the simple recursive constructs, I’ve decided to do a short how-to for that problem.
When ever a treeview is to be populated with a dynamic structure, recursive calls come into play. I’m after this structure:
Capture

First of all – I’ve this data source:

public class Foo
{
public Foo()
{
Children = new Collection<Foo>();
}

public string Name { get; set; }

public int Id { get; set; }

public Collection<Foo> Children { get; set; }
}

And this collection of ‘Foos’:

Collection<Foo> GenerateFooList()
{
var col = new Collection<Foo>();
var f1 = new Foo() { Id = 0, Name = "A" };
var f2 = new Foo() { Id = 1, Name = "B" };
var f3 = new Foo() { Id = 2, Name = "E" };
var f4 = new Foo() { Id = 3, Name = "F" };
var f5 = new Foo() { Id = 4, Name = "G" };
var f6 = new Foo() { Id = 5, Name = "C" };
var f7 = new Foo() { Id = 6, Name = "D" };

//children
f1.Children.Add(f2);
f1.Children.Add(f3);

f2.Children.Add(f6);
f6.Children.Add(f7);

col.Add(f1);
col.Add(f4);
col.Add(f5);

return col;
}
This is not important however; it is just a collection with items. Now – the important thing is the population of the treeview seen above. The population is made in code as seen here:

void FillTree()
{
//get data
Collection<Foo> data = new DataService().FooList;

//clear and add root
tvView.Items.Clear();

TreeViewItem root = new TreeViewItem();
root.Header = "Root";
tvView.Items.Add(root);

AddToTreeview(root, data);
}

void AddToTreeview(TreeViewItem root, Collection<Foo> data)
{
foreach (var foo in data)
{
TreeViewItem itm = new TreeViewItem();
itm.Header = foo.Name;

root.Items.Add(itm);

if (foo.Children.Count > 0) //if needed - call self.
AddToTreeview(itm, foo.Children);
}
}

21 March, 2010

Silverlight: cross domain calls to WCF service

I’m building a system with Silverlight (SL) on the Client side and some wcf-services supporting this client. Now – as the wcf-services are located in services.mydomain.com; and the SL client is exposed on www.mydomain.com – I’m having a problem.
It turns out that the SL cross domain calls are disabled by default, but needs to be allowed on the service (?). How bizarre is this? Why is it not the SL client that needs to be allowed to be calling out of the “native” domain (www.mydomain.com)? It seems very “reverse” to me?

Anyway – an xml-file named (clientaccesspolicy.xml) should be placed in the root of your domain (not webserver!). It seems a common misconception that it should be placed in the root of the webserver. This is not technically correct, it should be exposed like this instead: www.mydomain.com/clientaccesspolicy.xml. That this also happens to be the root of the webserver in some cases, is just pure coincidence.

Now – the really important part is this: remember to add the attribute (http-request-headers=”*”) to the “allow-from” tag (see below). Otherwise you are continuously presented with problems on the Client when calling out from the SilverLight application/control.

Code Snippet
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <access-policy>
  3.   <cross-domain-access>
  4.     <policy>
  5.       <allow-from http-request-headers="*">
  6.         <domain uri="*"/>
  7.       </allow-from>
  8.       <grant-to>
  9.         <resource path="/" include-subpaths="true"/>
  10.       </grant-to>
  11.     </policy>
  12.   </cross-domain-access>
  13. </access-policy>

04 March, 2010

Microsoft Sync Framework: where are the 2.0 assemblies?

Having installed the latest version of Sync Framework, I failed to find the assemblies in the .NET assembly reference dialog in Visual Studio 2010.

Well – they are not installed and referenced by registry (to show up in the reference dialog); but you need to find them via the “browse” dialog instead. They are located here: C:\Program Files\Microsoft Sync Framework\2.0\Runtime\x86

image

iPhone/XCode - not all cases are equal!

This bit me! Having made some changes to an iPhone application (Obj-C); everything worked fine in the simulator. But, when deploying the s...