Jeremy Simmons: The Blog

I've resolved to start making the shift to WPF. It's about time. The technology has only been around for a good 3+ years. So far, I'm very excited by what I see. An invaluable reference has been Programming WPF 2nd edition by Chris Sells. Specifically the appendices. The explination of Xaml, and the Xaml Extensions removes the veil of confusion from all of the arcane looking symbols going on in the Xaml code. Thanks for the awesome book Chris! I was going through an article published in MSDN Magazine, Data Binding in WPF by John Papa. I encountered a very frustrating bug and I felt the need to let the next developer know about the solution I uncovered. (The next developer is sometimes me. I do very much love finding my own posts months or years down the road that help me out). Maybe this will help you out.

So, I'm building my Xaml out, and I have a perfectly good XmlDataProvider in my Resources.

<XmlDataProvider x:Key="MoreColors" XPath="/colors">
    <x:XData>
        <colors>
            <color name="pink"/>
            <color name="white"/>
            <color name="black"/>
            <color name="cyan"/>
            <color name="gray"/>
            <color name="magenta"/>
        </colors>
    </x:XData>
</XmlDataProvider>

I Created the Binding to my Listbox as such.

This whole thing is working in the Designer (Visual Studio 2008), but is displaying nothing at runtime. I whisk away to the MSDN Documentation for XmlDataProvider and find this clever little note.

The root node of the XML data has an xmlns attribute that sets the XML namespace to an empty string. This is a requirement for applying XPath queries to a data island that is inline within the XAML page. In this inline case, the XAML, and thus the data island, inherits the System.Windows namespace. Because of this, you need to set the namespace blank to keep XPath queries from being qualified by the System.Windows namespace, which would misdirect the queries.

Is it possible that this is the explination to the Debug output I'm seeing in Visual Studio at runtime?

System.Windows.Data Error: 47 : XmlDataProvider has inline XML that does not explicitly set its XmlNamespace (xmlns="").

I add the missing xmlns="" to the root xml element (as shown below), and things begin to work at runtime.

<XmlDataProvider x:Key="MoreColors" XPath="/colors">
    <x:XData>
        <colors xmlns="">
            <color name="pink"/>
            <color name="white"/>

In searching for the answer to this solution, I also came across this post Why WPF databinding is an awful technology. I hope this is not shared feeling of frustration many of us receive by wasted hours of our day with the Moteur de recherche du jour (search engine of the day). It's a really useful tool if you can convince it to give you the right answer, and people have posted about the particular phrase you're looking for.

Good luck reader, with your journey to WPF enlightenment. It has been worth my time.

When you have a ListView control in Windows Forms, and you don't want the horizontal scroll bar to show up, you need to set the size of the columns to be the same 'Width' as the ListView.
What exactly is the 'Width' you should use here? Yes careful reader, I've been quoting Width because we need to take a closer look at what's going on.
Lets look at a dead simple example to clearly illustrate why this is a concern.

When I create a new Windows Forms application in Visual Studio, I get a standard sized form. Dragging a ListView control from the toolbox will create a control with the dimensions defined as

private void InitializeComponent()
{
   ...
   this.listView1.Size = new System.Drawing.Size(121, 97);
   ...
}

I added the following code to constructor of the Form after the InitializeComponent() call;

void Form1()
{
   InitializeComponent();
   
   listView1.Columns.Add("Name");
   for (int i = 0; i < 20; i++)
   {
      listView1.Items.Add(new string((char)(i + 33), 10));
   }
   // Naive width
   listView1.Columns[0].Width = listView1.Width;
}

What we end up with looks like the image below.

This is definately not what we wanted. Even though none of my data is forcing my scroll behavior, my column definition definitely is. I could change this to use the ClientSize of the Control, I know that's smaller. The documentation on MSDN for Control.ClientSize makes these remarks about the property.

"The client area of a control is the bounds of the control, minus the nonclient elements such as scroll bars, borders, title bars, and menus..."

This will work right? I'll just make a quick change to the code, recompile and... drat. No love.

    // Setting the width on the Column
   //listView1.Columns[0].Width = listView1.Width;
   //listView1.Columns[0].Width = listView1.ClientSize.Width;

}

What is going on here?!
As it turns out, the calculation for ClientSize in the constructor is completely correct. The control hasn't been drawn yet, and it has no knowledge of whether it will need to use a vertical scrollbar to display the data. That's just fine control. I know how to fix you. I know how wide a scroll bar is, and I can figure that out on my own... Just watch me.

   // Setting the width on the Column
   //listView1.Columns[0].Width = listView1.Width;
   //listView1.Columns[0].Width = listView1.ClientSize.Width;
   listView1.Columns[0].Width = listView1.ClientSize.Width - SystemInformation.VerticalScrollBarWidth;
}

Ha! Take that ListView. Now my column displays perfectly, and I have no Horizontal ScrollBar to contend with. Just to prove it to you, I'm going to check how wide it should be after the form shows up, to make sure I'm right...

      //listView1.Columns[0].Width = listView1.Width;
   //listView1.Columns[0].Width = listView1.ClientSize.Width;
   Debug.Print("ListView is {0} px wide and has a client width of {1} px", listView1.Width, listView1.ClientSize.Width);
   Debug.Print("VerticalScrollBarWidth: {0}", SystemInformation.VerticalScrollBarWidth);
   Debug.Print("Calculated width: {0}", listView1.ClientSize.Width - SystemInformation.VerticalScrollBarWidth);
   listView1.Columns[0].Width = listView1.ClientSize.Width - SystemInformation.VerticalScrollBarWidth;
   this.Load += new EventHandler(Form1_Load);
}
void Form1_Load(object sender, EventArgs e)
{
   Debug.Print("Loaded width: {0}", listView1.ClientSize.Width - SystemInformation.VerticalScrollBarWidth);
}

Debug Output:

ListView is 121 px wide and has a client width of 117 px
VerticalScrollBarWidth: 17
Calculated width: 100
Loaded width: 100

Uh-oh. I have a bad feeling. It seems like the Width of the ClientSize after the control has been painted is different than before it was painted. Could it be that when the VerticalScrollBar is painted, the control does in fact know how much room it has left to use to paint on the screen?! Isn't that in fact, exactly what the Remarks of the ClientSize property told me? Do the numbers above not in fact make perfect sense!? Is 117 - 17 = 100?! Yes... sigh. Perhaps I should have meditated on the implications that the remarks on MSDN were accurate from the begging.

"The client area of a control is the bounds of the control, minus the nonclient elements such as scroll bars, borders, title bars, and menus..."

As it turns out, the correct time to set the width of a ListView Column is AFTER you've determined that there will be scrollbars painted on the control.

What was that format string again? You know, the one for the GUID where you only output the guid, but with no formatting?

using System;
public class GuidTest
{
    public static void Main()
    {
        string[] guidFormats = {"N", "D", "B", "P"};
        Guid g = new Guid();
        Array.ForEach(guidFormats, delegate(string t)
        {
            Console.WriteLine("{0}:{1}", t, g.ToString(t));
        });
        Console.ReadLine();
    }
}

N:00000000000000000000000000000000
D:00000000-0000-0000-0000-000000000000
B:{00000000-0000-0000-0000-000000000000}
P:(00000000-0000-0000-0000-000000000000)

That's right. Now I remember.

Edit: 1/8/2010 - I've forgotten again... Darn.

I should create a mnemonic device to remember this

N = Nothing

D = Dashes

B = Brackets

P = Parenthesis

http://msdn.microsoft.com/en-us/system.guid.tostring.aspx

Sometimes you just need a file with nothing particular in it so you can test a web-page with a <input type="file"/>

Rather than write a snippet of code, or use a utility, you can use the operating system to do this.

On WindowsXP, you can use FSUTIL to do this.

FSUTIL FILE CREATENEWFILE <path> <sizeInBytes>

FSUTIL FILE CREATENEWFILE C:\20mbfile.txt 20971520

I want to get a Process ID for the current Application in C#, so which is faster (and does it really matter).

Lets find out!

namespace ProcessIDFaceoff
{
class Program
{
[System.Runtime.InteropServices.DllImport("kernel32.dll", SetLastError = true)]
static extern int GetCurrentProcessId();

static void Main(string[] args)
{
for (int i = 0; i < 3; i++)
{
new Program().RunTest();
}
}

public void RunTest()
{
const int times = 1000;
System.Console.WriteLine("PInvoke,Native");

for (int j = 0; j < 20; j++)
{
using (new DisposableStopwatch(System.Console.Out))
{
for (int i = 0; i < times; i++)
{
int pid = GetCurrentProcessId();
}
}
System.Console.Write(",");
using (new DisposableStopwatch(System.Console.Out))
{
for (int i = 0; i < times; i++)
{
int pid = System.Diagnostics.Process.GetCurrentProcess().Id;
}
}
System.Console.WriteLine();
}
}

class DisposableStopwatch : System.IDisposable
{
private System.Diagnostics.Stopwatch watch;

public DisposableStopwatch(System.IO.TextWriter logger)
{
watch = System.Diagnostics.Stopwatch.StartNew();
}

#region IDisposable Members

public void Dispose()
{
watch.Stop();
System.Console.Write("{0}", watch.Elapsed);
}

#endregion
}
}
}

Yields something like this.

PInvoke,Native
00:00:00.0003477,00:00:00.0004451
00:00:00.0000705,00:00:00.0003653
00:00:00.0000675,00:00:00.0003550
00:00:00.0000677,00:00:00.0003782
00:00:00.0000679,00:00:00.0003586
00:00:00.0000674,00:00:00.0003772
00:00:00.0000677,00:00:00.0017131
00:00:00.0000706,00:00:00.0004838
00:00:00.0000689,00:00:00.0053451
00:00:00.0000676,00:00:00.0003648
00:00:00.0000677,00:00:00.0003676
00:00:00.0000677,00:00:00.0003659
00:00:00.0000677,00:00:00.0017793
00:00:00.0000766,00:00:00.0004811
00:00:00.0000694,00:00:00.0004966
00:00:00.0000690,00:00:00.0004918
00:00:00.0000704,00:00:00.0003739
00:00:00.0000677,00:00:00.0003609
00:00:00.0000769,00:00:00.0003749
00:00:00.0000677,00:00:00.0034804
PInvoke,Native
00:00:00.0000704,00:00:00.0004326
00:00:00.0000695,00:00:00.0014194
00:00:00.0000770,00:00:00.0002896
00:00:00.0000681,00:00:00.0003052
00:00:00.0000705,00:00:00.0003009
00:00:00.0000711,00:00:00.0003472
00:00:00.0000708,00:00:00.0038629
00:00:00.0000681,00:00:00.0003193
00:00:00.0000678,00:00:00.0003672
00:00:00.0000679,00:00:00.0003150
00:00:00.0000675,00:00:00.0003610
00:00:00.0000679,00:00:00.0003227
00:00:00.0000674,00:00:00.0061228
00:00:00.0000704,00:00:00.0004289
00:00:00.0000701,00:00:00.0004732
00:00:00.0000696,00:00:00.0004107
00:00:00.0000697,00:00:00.0003274
00:00:00.0000678,00:00:00.0003034
00:00:00.0000679,00:00:00.0004169
00:00:00.0000688,00:00:00.0047879
PInvoke,Native
00:00:00.0000703,00:00:00.0004419
00:00:00.0000697,00:00:00.0004428
00:00:00.0000699,00:00:00.0003065
00:00:00.0000678,00:00:00.0003064
00:00:00.0000674,00:00:00.0003073
00:00:00.0000674,00:00:00.0015432
00:00:00.0000694,00:00:00.0004473
00:00:00.0000704,00:00:00.0053116
00:00:00.0000680,00:00:00.0003242
00:00:00.0000698,00:00:00.0003293
00:00:00.0000721,00:00:00.0003163
00:00:00.0000720,00:00:00.0003264
00:00:00.0000716,00:00:00.0039090
00:00:00.0000700,00:00:00.0004544
00:00:00.0000703,00:00:00.0003519
00:00:00.0000678,00:00:00.0003039
00:00:00.0000677,00:00:00.0003300
00:00:00.0000678,00:00:00.0003068
00:00:00.0000677,00:00:00.0070403
00:00:00.0000727,00:00:00.0003814

Looks faster to me. By at least 3x-5x in most cases. That's maybe worth the consideration to PInvoke it.

A colleage approached me and asked how he could convert some ASP Classic code to ASP.Net 2.

Here's the snippet

Dim user 'DOMAIN\USERNAME

Const DomainAuthority = "dc.hq.domain.com"

user = Request.ServerVariables("AUTH_USER") ' BASIC Authentication

user = Mid(user, InStr(user, "\") + 1)

Set user = GetObject("WINNT://" & DomainAuthority & "/" & user)

For Each grp in user.Groups

   If grp.Name = "GroupName1" Then GroupFlag1 = True

   If grp.Name = "GroupName2" Then GroupFlag2 = True

Next

This doesn't compile in a VB.Net web-app.

In order to fix this, lets first add a reference to the types we're using.

At the project level in the Solution Explorer, right click and select Add Reference

Switch to the COM tab, and Choose the "Active DS Type Library"

This will automagically add some things to your project.

These are the magical COM Interop DLLs that are generated for you, and allow you to use the objects inside that library.
Dim up a few objects, to use a bit later.

Dim usr As IADsUser
Dim grp As IADsGroup

Set a reference to your user the same as always, using the WinNT ADSI provider.

usr = GetObject("WINNT://" & TheDC & "/" & UsrName)

Now that the compiler knows what the grp object's type is, it won't puke on you

For Each grp In usr.Groups()
  If (grp.Name = "foo" Or grp.Name = "bar") Then
    ' Do something with it
  End If
Next


There are better ways to do this though, Stay tuned for how to totally pimp this out, the ASP.Net 2.0 way.

I've had to do this way too many times, and keep forgetting to document how here.

Referencing an article http://www.activedir.org/article.aspx?aid=110. It occurred to me that you can impliment the snippet very easily in VBS.

1. Connect to the of the current workstation rootDSE
2. query for all User objects using an indexed attribute to get results as quickly as possible, also with little load on the server
3. get a full IADsUser object using the LDAP ADSI provider
4. do something with each user.

Here's what I wound up with.

Option Explicit ' Enough said. Don't write production code without it.

Dim objConnection, objCommand, objRecordSet, objRootDSE, objUser

Dim start, strDomain
start = Now

' AD (NTDS) is, afterall, just a service that sits on top of a
' JET Blue-based Extensible Storage Engine (WikiPedia Active_Directory)
' So why not just treat it as such and use a Database-esque provider to access the data?

Set objConnection = CreateObject("ADODB.Connection")
objConnection.Open "Provider=ADsDSOObject;"

Set objCommand = CreateObject("ADODB.Command")
objCommand.ActiveConnection = objConnection

' Get Domain name from RootDSE object.
Set objRootDSE = GetObject("LDAP://RootDSE")
strDomain = objRootDSE.Get("DefaultNamingContext")

' One could just as easily do (&(objectClass=User)(objectCategory=Person))

' I found this approach using indexed attributes to produce a speed gain of several magnitudes.

objCommand.CommandText = _
"<LDAP://" & strDomain & ">;" & _
 "(&(sAMAccountType=805306368)(!(objectClass=inetOrgPerson)));" & _
 "adspath;subtree"

Set objRecordSet = objCommand.Execute

While Not objRecordset.EOF

  ' Here is an IADsUser object using the ADSI LDAP provider.

 Set objUser = GetObject(objRecordset.Fields("adspath"))
 
 WScript.Echo objUser.name ' Do your work here! woohoo!
 
 objRecordset.MoveNext
 
Wend

WScript.Echo "Retrieved (" & objRecordSet.RecordCount & ") records in (" & DateDiff("s", start, Now) & ") seconds"

objConnection.Close

Javascript closures

<SCRIPT type="text/javascript">
function CreateRandomNumbers(count, max)
{
 var a = new Array();
 for(var i = 0; i < count; i++)
 {
   a.push(Math.floor(Math.random()*max)+1);
 }
 return a;
}

var smallRandomNumbers = CreateRandomNumbers(20, 20);
var largeRandomNumbers = CreateRandomNumbers(20, 500);

function makeGreaterThanPredicate(lowerBound) {
    return function(numberToCheck) {
    return (numberToCheck > lowerBound) ? true : false;
  };
}

function filter(sortby, arr)
{
  var l = arr.length;
  var a = new Array();
 
  for(var i = 0; i < l; i++)
  {
    var currentElement = arr[i];
    if(sortby(currentElement)) a.push(currentElement);
  }
  return a;
}

function dumpArray(obj)
{
  var l = obj.length;
  document.write('[');
  for(var i = 0; i < l; i++)
  {
    document.write(obj[i]);
    if(i != l-1)
    {
    document.write(',');
    }
  }
 document.write(']');
}
function dump(obj)
{
  var switchToken = typeof(obj);

  switch (switchToken)
  {
    case 'object':
      dumpArray(obj);
      break;
    default:
      document.writeln("Unknown type:");
      document.writeln(obj.toString());
  }
  document.writeln("<br/>");
}
var greaterThan10 = makeGreaterThanPredicate(10);
var greaterThan100 = makeGreaterThanPredicate(100);
dump(smallRandomNumbers);
dump(filter(greaterThan10, smallRandomNumbers));
dump(largeRandomNumbers);
dump(filter(greaterThan100, largeRandomNumbers));
dump(filter(makeGreaterThanPredicate(250), largeRandomNumbers));
</SCRIPT>

More DOS Scripting goodness. This snippet appends some arbitrary location to your PATH variable, so you can call the executables inside of it.

@ECHO OFF
ECHO %PATH% | FIND /I "C:\Folder1\Folder2\Folder with Spaces\bin\Release"
IF ERRORLEVEL 1 SET PATH=%PATH%;C:\Folder1\Folder2\Folder with Spaces\bin\Release

That, ladies and gentleman, will save you minutes of grief. Isn't that what it's all about anyway? makes it all worth while.

I've found myself using this pattern alot lately. I figured I'd post it for posterity.

---

@ECHO OFF

SET NOWD=%DATE%
SET mm=%NOWD:~4,2%
SET dd=%NOWD:~7,2%
SET yyyy=%NOWD:~10,4%

:: ECHO mm=%mm%
:: ECHO dd=%dd%
:: ECHO yyyy=%yyyy%

SET NOWT=%TIME%
SET hour=%TIME:~0,2%
SET min=%TIME:~3,2%
SET sec=%TIME:~6,2%
SET ms=%TIME:~9,2%

:: ECHO NOWT=%NOWT%
:: ECHO hour=%hour%
:: ECHO min=%min%
:: ECHO sec=%sec%
:: ECHO ms=%ms%

SET LOGFILENAME=%yyyy%%mm%%dd%_%hour%%min%%sec%%ms%.txt

:: ECHO %LOGFILENAME%

:: make sure to use a double arrow to append, not 'create'

ECHO %DATE% - %TIME% >> %LOGFILENAME%

ECHO Whatever your program should do >> %LOGFILENAME%

 

Some people (like myself) should learn not to touch a compiler on Monday mornings (before the third cup of coffee at least)

I don't know why I couldn't remember how to do this, but I feel like a noob.

I was just trying to build a Xml Document in memory with a XmlWriter and a MemoryStream simple stuff right?

XmlWriterSettings settings = new XmlWriterSettings();

settings.Indent = true;

settings.OmitXmlDeclaration = false;

MemoryStream strm = new MemoryStream();

using (XmlWriter w = XmlWriter.Create(strm, settings)) {

...

}

Now what if you want to get that back into a string? Say for use in a web-service query or something. like, I don't know, the SharePoint 2003 Search Web Service.

That conversion back to a string might look something like this.

string s;
System.O.MemoryStream ms;
System.IO.StreamReader sr = new System.IO.StreamReader(ms));
s = sr.ReadToEnd();
sr.Close();
ms.Close();

Of course later in the day, I decided to actually download the Research Service SDK, grab a copy of the QueryPacket Schema I was working against, generated a class against it with the XSD tool, and subclassed it to make sure I was submitting a valid search request. All was well with the world again, and I didn't feel so horribly inept for a Monday morning. Yeah me!

I realized I haven't blogged in 5 months. How pathetic is that.

Here's some quick coding goodness. This will insert the current date formatted per the user's Locale into the div. One of them is IE specific, the other is a more standards-happy way of doing it. As always, code should be valid XHTML!

<div id="CurrentDate"></div>
<hr />
<div id="CurrentDate2"></div>

<script type="text/vbscript" language="vbscript">
<!--
<![CDATA[
    Document.all("CurrentDate").innerText = FormatDateTime(Now(),1)
]]>
//-->
</script>

<script type="text/javascript" language="javascript">
<!--
<![CDATA[
    var now = new Date();
    now.getDate();
    document.getElementById("CurrentDate2").innerText = now.toLocaleDateString();

]]>
//-->
</script>