I’ve posted a new version of the Random Album Chooser. This is in response to the first piece of feedback I received. I couldn’t believe how pleased it made me feel to find out I had a user! I suppose after spending all my working life writing software for others this was the first that was all mine – my idea and my execution.

I’m not charging for the software, but if you’d like to make a donation, download through this button:

I replied with thanks and asked if there was anything missing. He (assuming it is a he) replied with a problem with long file names and a suggestion that I close the application or minimise it to the tray after sending the tracks to the music player. Unfortunately I wasn’t able to repeat the bug straight away, and as I’ve got a little time on my hands, I decided to implement the close/minimize option.

I decided that a three-way choice of do nothing, minimise or close was needed – that would cover all possibilities. However, I had to remind myself of how radio buttons work – which doesn’t do one’s confidence much good I can tell you! A quick Google search later and that was soon remedied and the configuration dialog updated.

Update Configuration Dialog

I also added a configuration element for the type of music file. Eventually I’ll get the application to check for a list file types rather than just the one so if your library is a mixture of mp3, wma and ogg files it will cope – but that’s for another day.

I thought that getting the application to minimise to the tray would be hard as I couldn’t immediately see the way to do it, but I found some code on the web and I was amazed at how easy it was. I then thought about setting up the application so that the normal minimise function could be customised so the user could choose to minimise to the task bar or the system tray. That was harder so I left it for the time being.

In the meantime my user had sent me some more information which showed that the bug with the long file names was actually in System.Diagnostics.Process.StartWithShellExecuteEx(). He also sent me the full path of the tracks he was trying to play. As well as the actual filenames being long one of the folder names was really long. I could now start looking at the bug properly, I could set up a test directory structure that mimicked what the user had and I copied a small mp3 file several times and renamed them appropriately.

With the directory structure I set up to test the problem I found that the argument list was 3231 characters long and I got an exception raised. It wasn’t the same as the one reported and I had two different ones on different occasions – which indicated a serious problem. If I renamed the folder with the long name to something shorter, the argument list came down to 1559 characters and I didn’t have any problems sending all the tracks to the music player.

I did some checking and actually read the documentation and found out that the problem was Process.StartInfo.Arguments being too long.  There’s a limit of 2003 characters on the string – which seems a strange number to pick, but I guess there must be a reason.

So I needed to modify code. I thought the best solution was to check the length as I built up the argument list and only add the next track if it’s still under the 2003 char limit. There only remained the question of how to warn the user that not all the tracks will be played.

A little bit more pondering yielded the answer. The simplest answers are usually the best. In this case I if there are too many tracks or their names are too long, put up a message box:

Arguments Too Long Error Dialog

The user can then decide whether they want to play the tracks that have been added or try again with a different album.

Obviously this isn’t ideal as the entire album doesn’t get played. I looked at using the StartInfo.WorkingDirectory property to see if I could remove the path from the file names before sending them to the player. This didn’t work with MediaMonkey or Windows Media Player, but did for Winamp so another configuration option is required – though how I’m going to explain when and why you should change the option I don’t know. I’ve added the option for now – mainly so I can test other possible solutions more easily.

Another solution could be to pass as many tracks as possible to start with and then passing the remaining tracks once the player has been launched. This would, I feel, cause more headaches as the mechanism for doing this will be different for different music players. This is also getting into the territory of having a configuration page for each different music player and as, ultimately, this program was written for my benefit it doesn’t seem worth the effort.

Yet  again, I’m reminded that no matter how much testing you do as a developer there’s something you always forget. Unit tests might have helped – if I’d remembered to check the documentation for Process.Start() and found the length limit to Arguments in the first place!

It also shows that even the simplest of applications can have quite complicated configuration issues.

© 2009, Chris. All rights reserved. If you republish this post can you please link back to the original post.