Dot Net What Not Posts

If you’ve ever had to write or read a regular expression, you won’t need any convincing that a tool to make this easier would be useful!

If you aren’t familiar with regexs (as they are colloquially known) then it’s worth getting to know, as they can be amazingly useful at times. Sadly, they can also be amazingly difficult to write, and impossible to read afterwards!

Here are a few tips for taking away the pain.

Does this sound familiar…

User: Your app just crashed
You: What happened?
User: It crashed
You: (sigh) What were you doing at the time?
User: Using the app
You: (sigh) What specifically were you doing?
User: I was clicking in that box
You: Which box?
User: You know, the one on the window you get when you click the other button
…and so it goes on

Read how we managed to get useful information about errors without having to suffer speaking to the users!

Not a common requirement, but as it can happen, and was an interesting one to solve, I thought it worth documenting. The scenario is this: For a medical system, there are a number of treatment sites (ie bits of the human body) that must be checked. For each treatment site, there will be a number of check types that need to be done. We needed to display this information in a grid like this (this is a prototype, so only shows True and False, rather than having checkboxes that can be altered)… The treatment sites are listed in the first column, and are pulled from a database table. The interesting bit here is that the 2nd column onwards are not fixed, these are also pulled from a database table, making the grid dynamic. We don’t know in advance what columns will be needed (other than the first one of course).…

A hopefully enlightening story.

I had the need to get the latitude and longitude for UK postcodes. Knowing that another developer had recently done a lot of work doing similar things using the Google Maps API, I had a look at the code she had written. Following the Google guidelines, she had ended up adding wads of C# classes, defining the various data types that the API returns, as well as a lot of helper methods to parse the data. I had that horrible sinking feeling you get when you can see a small design requirement blow up out of all proportion.

Whilst contemplating the problem, I had an epiphany, and realised that I could solve the problem in a much simpler way, albeit with some initial effort. I thought the technique might be useful to others, but more significantly, thought that the idea of thinking outside of the box may be of interest.

I just came across an, erm interesting issue when exporting some data to a CSV file. When I tried to open the file in Excel, I got the rather helpful error message “The file format and extension of ‘filename.csv’ don’t match. The file could be corrupted or unsafe. Unless you trust its source, don’t open it. Do you want to open it anyway?” If you click the Yes button, then you get the even more helpful error message “Excel has detected that ‘filename.csv’ is a SYLK file, but cannot load it. Either the file has errors or it is not a SYLK file format. Click OK to try to open the file in a different format.” At this point, you go and look to see if there are any jobs going on the cashiers at Tesco! Turns out that the fix is very simple. If you export an ID field…

I kept having problems when I opened a XAML file, in that the designer would show the following… This makes it somewhat hard to design a view when you can’t see the design! It turns out that when the XAML designer loads, it attempts to run code in your view model. There is some (questionable) justification for this, but overall, it’s a huge pain, and is one of the reasons why editing XAML files can be such a slow and tedious process. However, there is a way to mitigate the problem. If you can identify which parts of your code are causing issues, you can add code to prevent them from running when you are in Visual Studio. First you need to add the following line to the top of your code file… …then wrap the offending code in a check as follows… Apart from the fab method name (who…

We have found a problem whereby when a window loads, some of the buttons are disabled. Clicking anywhere on the window (even on the title bar) enables the button, but this doesn’t give a good user experience. Thankfully the fix is simple. You need to find a place in the view model code where all the data has loaded, all events have been raised, and all INC properties have been set. Then you add the following lines… That will fix the issue. Ideally you would do this in the base view model, but this requires having somewhere in there where you know all data has been loaded. If you have that, then consider yourself amongst the blessed

I recently came across a situation where I needed to delete all the data from a table and reinsert it (don’t ask why, it was quite sensible actually). I wanted to avoid anyone reading from the table while it was in an intermediate state, ie with part of the data in and part not. I did a quick search on using transactions in EF, and came across an article (not linked for reasons that should become apparent) that strongly recommended not using them at all. This all seemed sensible advice, until I read the comments. A lot of people criticised the article as giving very bad advice. Amongst the links was one to an MSDN page that explained how to use transactions with EF6 onwards. This was much cleaner than the advice in the previous article, and being from Microsoft, one hopes it is more authoritative. It’s worth reading the whole…