Initializing a combobox to a blank value might be harder than you think

Combobox troubles again today. No matter how hard I tried to have Comboboxes in my dialog form to initially display blank (SelectedIndex = -1), as soon as the dialog was displayed, the combos would always show the first item in the List that populated it. Despite being set to -1 explicitly. It was driving me nuts.

When created at runtime using a List as DataSource, getting this (empty combos) might be harder than you think

The situation: I had a dialog form that should have a variable number of comboboxes on it, determined at runtime. So the form had an Init method where I dynamically added the comboboxes, and set its DataSource to a List of items (directly, no BindingSource). The form also has a LoadData method, that sets the SelectedIndex of each combo to the actual value from the data, or to -1 of it was unknown or uninitialized at that time. This was to be able to make the combo appear blank instead of preselecting the first item, which was undesired. The caller of the dialog executes Init(), LoadData() and finally ShowDialog().

I was expecting a blank combobox, but it showed the first item in the list preselected. I triple checked that the SelectedIndex was correctly set to -1 at the end of LoadData(), but as soon as the form was displayed, it was 0. What the *** happened there in between and “who” was secretly setting my property!? Lees meer over dit bericht

SVN Commit failed, access forbidden

Yesterday I had to commit a project to a fresh and new repository on a Subversion server (VisualSVN Server). So I checked out an (empty) working copy, inserted the files, and committed. The files were added, but immediately after that, TortoiseSVN complained: commit failed (details follow): access to ‘/svn/(RepoName)/!svn/act/(someguid)’ forbidden.’ Errr… what?

Commit failed, access forbidden -- but I do have write access?

So I verified with the server admin that I had read and write permission, which was the case. Googling for answers turned up a possible suspect: casing of the repository name. Turned out my casing was different than what the admin had created. RepoName should have been Reponame (example, of course). With the wrong casing in the svn url, I was able to do checkouts, updates, browse the repository and everything else… but not commit.

So if you ever encounter an error something like this, check your casing. Even on Windows filesystems.

BTW: check out the improvements in the updated TortoiseSVN 1.7, impressive.

Edit (26-01-2012): As Steve pointed out in the comments, the unexpected case sensitivity is not limited to the repository name. Also check the domain part of your user’s logins.