WPF Databinding to a Combobox

So I’m trying to hone my skills in ASP.Net while at the same time learn new technology and languages. I’ve been working with WPF since it came out, and the more I play with it the more I like it. My most recent project includes quite a bit of databinding, which I quickly learned is very different from ASP.Net.

For this posting, I’ll assume we need to databind to a Combobox. Before I begin, please note this is of course not the only way to do this. There are numerous ways to accomplish the same result, and someone probably has a better way of doing it. This just outlines one method that works, while providing type safety.

Ok, with that out of the way, first create a public class that handles a key and a value. This is to prepare for your type safe list that the Combobox requires as its datasource. It can look as simple as this:

public class myObject
    public int objKey {get; set;}
    public string objValue {get; set;}

Ok, we have a class for our type safe List. Now, go get your data and put it somewhere. In my project, I read from a SQL table, put the information into a DataSet, then iterated through the DataSet adding each row to the List like so:

foreach(DataRow r in ds.Tables[0].Rows)
    int key = Convert.ToInt32(r[0].ToString());
    string value = r[1].ToString();
    newObject.Add(new myObject {objKey = key, objValue = value });

Where the type safe list is named newObject. Ok, this will fill your type safe list with each object from the DataSet. Now you can bind the Combobox to the List the same way we did it in ASP.Net, only the naming changed slightly. Instead of DataSource, it’s called ItemsSource. The DataTextField and DataValueField properties are now DisplayMemberPath and SelectedValuePath. So to bind to the Combobox you can do this:

combobox1.ItemsSource = newObject;
combobox1.DisplayMemberPath = "objValue";
combobox1.SelectedValuePath = "objKey";

That’s it. You will now have your Combobox filled with your data, and the key from your database query is set to the value of each item.

Problems installing SQL 2008

I had originally installed SQL 2005 Express on my laptop, and something happened during the installation and it got corrupted. I was unable to uninstall, whether I used Add/Remove programs, ran setup.exe ACTION=uninstall from the command line while in the SQL root path, even if I used msicuu2 and msizap to look for the GUIDs associated with SQL 2005. Nothing worked. I thought installing SQL 2008 Express might “fix” or overwrite something and then get me the latest version to play with anyway. Couldn’t have been further from correct. Now I had two corrupt installations and no way to remove either one.

After much research online and trial and error, I was at a point of giving up and wiping the hard disk. I HATE wiping the hard disk for something like this, I feel like I failed somehow. Outside of serious corruption there’s always a way to fix something software related, right? Well, I stumbled upon an MSDN posting later today where users were having similar issues, and one person suggested removing the following registry entry:

HKLMSOFTWAREMicrosoftMicrosoft SQL Server90

So, I went back into Add/Remove Programs, removed all things SQL, stopped all SQL services and set them all to Disabled, restarted the computer, made sure visual Studio 2008 had SP1 installed (because once before it barked at me saying that was required) and tried the install again. Voila! Everything installed perfectly except Full Text Search. Since I’ve been without a local database on my development machine for the past two years, Full Text Search is the least of my problems right now! I’m just thankful I finally have something to work with.

So, if anyone is having problems with the Express SQL versions, or something similar is happening that is preventing you from upgrading to either SQL 2008 Express or SQL 2008 Enterprise or Standard, check out this MSDN thread and see if it helps you:


Setting a Silverlight slider control at initialization

I recently ran into a problem where I needed a Silverlight slider control pre-populated with a specific value when the page loaded, but if you use the slider`s ValueChanged event in the code behind file, it dies. Why? Because as the page loads and initializes, the code behind is trying to run and the slider control hasn`t finished being created yet. Putting the values I wanted them to start at worked fine, as long as you put them after the Initialize(); call in Page_Load, but I still wanted the ValueChanged method to fire when the value changed on the slider. Here`s what I did to make sure the ValueChanged method fires and I can still pre-populate the slider at initialization:

Slider slider = (Slider)this.FindName(“slidername”);
if (slider == null)
// Do something

The first line there looks to make sure the control was created before even continuing. If it exists, it then will allow whatever you want from it without throwing an error.

Error creating a new SSIS project in BIDS 2005

I recently encountered an issue where I hadn’t created an SSIS package in a while, and when I opened BIDS 2005 and said “Create New Project”, after naming the project and proceeding it barked at me, saying “Failed to save package file with error 0x080040155 ‘Interface not registered’. Turns out somehow my MSXML assembly files got unregistered. The way to fix this that worked for me, was to re-register msxml3.dll, msxml4.dll and msxml6.dll. Some said to just do 3 and 6, which would probably work, but it doesn’t hurt to register all three anyway. That did the trick!

Problems with OLE DB and ODBC on 64 bit systems

So, for the past few months a DBA and I were trying to figure out why all of our SSIS packages, connection strings and data sources all work fine on Server 2003, SQL 2005 and of course in dev, but not on our production SQL 2005 server. After extensive research (which was probably right in front of our faces the whole time) we stumbled over the following KB article:


Which very briefly explains how the OLE DB and ODBC providers are only available on 32 bit systems, and our production SQL 2005 server is 64 bit. Since 64 bit performs so much better, and SQL is a resource hog to begin with, this seemed like the best solution. Then when we installed ILM 2007 (64 bit) and wanted to connect to the database (also 64 bit), and things kept failing, we’d beat our heads into the wall trying to figure out why. According to the KB article, there is no plan to support these providers in a 64 bit environment, and the best solution is to just emulate a 32 bit environment, such as run the application in 32 bit mode. Not that easy when you’re custom-writing interfaces, applications and queries. However, thanks to my co-worker’s friend he pointed out a way to run an SSIS package on a 64 bit server and make it think it’s 32 bit!

While creating the package in VS2005, go to Project->Project Properties. Look for the element called “RUN64BITRUNTIME” and change it to False. Then save and deploy the package as usual. Finally, you cannot execute the package from the UI or even from a SQL job. You’ll need to execute it from the command line using DTEXEC utility. To automate this, use a SQL job to call the DTEXEC utility command, either through xp_cmdshell or a batch job. More details can be found by reading this article from SQL Server 2008 Books Online.

So, there is a workaround to this apparent roadblock. The best part of all of this? There is allegedly support for these two providers in SQL 2008. We haven’t had a chance to test this yet, but that explains why they’re not supporting 64 bit versions in SQL 2005….just get SQL 2008!

Posts and ramblings about SharePoint, software development, and other things I thought were cool