Researchers Should Learn How To Program

Throughout most of my first year in medical school, and by most I mean the entire time, my background in engineering was useless. Sure, I could figure out how to plot the inverse of a graph without breaking a sweat, but surprisingly, that isn't an important skill to have as a doctor...doesn't really help with picking up the ladies either, seriously, Dr. Madden is a liar!

Anyways, this summer I'm doing research and I've finally been able to take advantage of my background in electrical engineering. I've found my experience in programming to be priceless. In our lab we collect our data in excel spreadsheets and then analyze them. Excel, and most other Microsoft Office products, have a scripting language called VBA. VBA is an easy language to learn, particularly if you have programmed or scripted in another language before. Using VBA, I am able to automate data analysis. For example, instead of having to calculate the mean of a column, I can write a script that will do it for me. Not that impressive when you look at a simple example like that, but you can imagine that if you have ten thousand columns per spreadsheet and you have 500 spreadsheets, then it would be nice to be able to write a ten line script just once to be able to calculate all the column means you need.

Anyways, being able to automate the analyses of the excel data has been incredibly valuable. I spent maybe a day writing scripts, but I will save at least two weeks in the end because the scripts will take me about two minutes to analyze the data collected from each patient.

Automating analyses can be a huge time saver. The time you invest in learning how to script will payoff in the end, especially if you find that you can reuse parts of your scripts in multiple studies (which is often the case).

Label Persistence on an Image in WPF

One of my side projects is an application that presents the user with an image of the human body with labels on different parts of the anatomy. The user can then click on the label and be presented with information about that body part. Here is an example of a skeleton with its skull labeled:


I am writing my application in Visual Basic using WPF. WPF is a very powerful technology that allows rapid user interface development; however, it does not have a native mechanism for label persistence. That is, if I label a part of an image, the label will not automatically reconfigure itself with the image if the user resizes the application. This means if the user resizes my application while it is displaying the above image, the skull label will no longer be on top of the skull in the image.

The solution to this problem turned out to be trivial, I am just surprised that Microsoft did not create a feature to handle this user scenario; a scenario that, I would think, is relatively common.
To solve this problem, I had to store several data points.

1. The original height and width of the image.


2. The 4 margin distances (distances between the left, right, top, and bottom of the label from the left, right, top, and bottom of the image, respectively).


3. The width and height of the label itself.

Normally a control object in a user interface is only represented by two data points, its x and y coordinates; however, I had to represent the label with the 6 data points mentioned in 2. and 3. to maintain label persistence.

Now for the algorithm:

1. On a resize event, I calculate the change of both the height and the width of the image.
   
   Dim widthMultiplier As Double = AnatomyImage.ActualWidth / oldWidth
   
   Dim heightMultiplier As Double = AnatomyImage.ActualHeight / oldHeight
   


2. I then use these multipliers to reevaluate the margins, height, and width of the label.
   
   Dim x As New Thickness With {.Top = Label1.Margin.Top * heightMultiplier, _
   .Bottom = Label1.Margin.Bottom * heightMultiplier, _
   .Left = Label1.Margin.Left * widthMultiplier, _
   .Right = Label1.Margin.Right * widthMultiplier _
   }
   Label1.Margin = x
   Label1.Width = Label1.ActualWidth * widthMultiplier
   Label1.Height = Label1.ActualHeight * heightMultiplier

Thus, the label is always in the same relative location on the image because its height, width, and margins still "own" the same relative percentage of the image.


...Seriously though, why was label persistence not a property in WPF?!