Let’s run a query with the results sorted by order of upcoming birthdays:

SELECT *,
IF(MONTH(`dob`) < MONTH(NOW()) ||
	(MONTH(`dob`) = MONTH(NOW()) && DAY(`dob`) < DAY(NOW())),
	MONTH(`dob`) + 12, MONTH(`dob`)) AS `adjusted_month`
FROM `person`
ORDER BY `adjusted_month`, DAY(`dob`), `name`

An alias called adjusted_month is used.

If the month of birth is earlier then the current month, or if it is the same and the day of birth is earlier then the current day, adjusted_month is set to the the month of birth + 12. Otherwise adjusted_month is just set to the month of birth.

The results can then be sorted by adjusted_month and the day to get the desired result.

One way to find the number of options selected:

$("select[@name='my_list']>option:selected”).length


All I needed to do was to draw a series of characters onto an image, each one having a different Color value. Easy right? Straightforward code, plug it in to the Ascgen and… wait… we get the output required. After a quick profile of the application, it was clear that the problem was with the external function and there was nothing that could be done to speed things up to an acceptable level.

Before digging into api functions, I decided to look back to the older method of drawing strings: Graphics.DrawString.

The code is less straightforward, but, despite having to create a new SolidBrush object for every Color, it works quickly. An image that took around 10 seconds with TextRenderer takes milliseconds with DrawString. The only obvious problem was that DrawString shifted the text right a fraction, but a quick google leads to a solution: using StringFormat.GenericTypographic in the call.

Now, the next obvious step was to use DrawString to improve the speed of drawing text all in one Color, and that’s where it all goes wrong: DrawString adds extra space between characters, and there doesn’t seem to be a way to stop it.

Applying the same code as before and printing each character separately (after first having to split it into a string array) gives the text spaced correctly. However it’s actually marginally slower then calling TextRenderer once on the whole string, and far more complicated.

Ideally I’d like to put the two together, so I need to either find a way to speed up TextRenderer or a way to fix the spacing in DrawString.

Let’s assume that you’ve created a form and added a RichTextBox called richTextBox1. Rather then going to the properties window to add the events, you’ll need to do it yourself.

Add the following in the constructor of the form:

richTextBox1.AllowDrop = true;
richTextBox1.DragDrop += new DragEventHandler(richTextBox1_DragDrop);
richTextBox1.DragEnter += new DragEventHandler(richTextBox1_DragEnter);

Type in the “+=” and press tab to automatically complete the line, then press tab again to create the function. Or just add the handler functions manually:

public void richTextBox1_DragEnter(object sender, DragEventArgs e) {
	if (e.Data.GetDataPresent(DataFormats.FileDrop)) {
		e.Effect = DragDropEffects.Copy;
	}
	else {
		e.Effect = DragDropEffects.None;
	}
}

public void richTextBox1_DragDrop(object sender, DragEventArgs e) {
	string[] filenames = (string[])e.Data.GetData(DataFormats.FileDrop);

	foreach (string filename in filenames) {
		// code to process a filename
	}
}

You can also implement DragOver and DragLeave in the same way, although those are there to “support the .NET Framework infrastructure” and are “not intended to be used directly from your code”. Intellisense doesn’t even show those events, but you can type them in and compile without problems. Also note that DragLeave is an EventHandler rather then a DragEventHandler.

After realising that there really wasn’t a built in function like:

Result[x, y] = Math.Between(0, 255, pixel);

I initially used the minimum and maximum functions:

Result[x, y] = Math.Max(0, Math.Min(255, pixel));

This works, and is a pretty neat little piece of code. However, after profiling the application it quickly became obvious that it was slowing things down. A look at the compiled code shows that even when built for release, Min and Max are left as function calls instead of being inlined.

Looking into bitwise operations, we see that using a bitwise AND with 255 will trim the value to be between 0 and 255. Unfortunately it loops around, so that isn’t what we need:

  100101100   300
& 011111111   255
= 000101100   044

The next option was to just check it manually:

if (pixel > 255) {
	Result[x, y] = 255;
}
else if (pixel < 0) {
	Result[x, y] = 0;
}
else {
	Result[x, y] = (byte)pixel;
}

Which is better, or:

Result[x, y] = (byte)(pixel > 255 ? 255 : (pixel < 0 ? 0 : pixel));

Which is silly and harder to maintain.

Either way a new problem is that most of the pixel values are between 0 and 255, therefore two checks will usually be required. Thanks to a great suggestion by biznatchio, we can instead do it in one comparison.

We saw earlier that “value &= 255″ will trim the value to be between 0 and 255. So, if we just compare the value to the trimmed value we will know if it is in range:

if ((pixel & 255) == pixel) {
	Result[x, y] = (byte)pixel;
}
else if (pixel > 255) {
	Result[x, y] = 255;
}
else {
	Result[x, y] = 0;
}

This will be slower then before if the value is <0 or >255. As our values will be in range most of the time, this method is the best.

Wordpress makes a surprisingly good CMS, but it’ll take me a while before I get everything set up just how I want it so excuse the mess.