Saturday, October 31, 2009

Pressure Sensitivity Problem with Wacom Bamboo Pen Tablet in Windows 7

Okay, this isn’t my usual coding-related post, but I hope it helps someone.  There are a million different threads about Wacom tablets not working properly with various software on various system configurations, and there’s no shortage of suggested solutions, so I’ll describe my specific situation and its specific solution:

Problem: Wacom tablet pen pressure sensitivity does not work in Adobe Photoshop CS4.  More specifically, it draws at full brush thickness all the time, unless I double-tap the tablet quickly and then begin drawing immediately after, which surprisingly allows pressure sensitivity to work.

My Configuration: Windows 7 Ultimate, Wacom Bamboo Pen tablet (the most basic model), Adobe Photoshop CS4 (as mentioned above)

Solution: In short, disable using the “press and hold” pen action as a right-click equivalent in the Windows tablet pen control panel.  To do this:

Click the Windows button, and in the search box type “Change tablet pen settings".  Open the item that appears.

image

In that dialog, in the Pen Options tab (the default), in the Pen actions group, select the Press and hold pen action and then click the Settings… button.

image

Then, in the dialog that appears, uncheck Enable press and hold for right-clicking and click OK.

image

Windows’ Tablet PC settings are fighting with the tablet’s usefulness, doing their best to turn it into a primary input device rather than a dedicated drawing instrument.  In my specific case, you’ll notice that every time you tap the pen and start drawing (interpreted by Windows as a “tap and hold”), a circle will start drawing around the tap location, and once it finishes drawing, the equivalent of a right-click is received.  This is not a Wacom thing; it’s a Windows thing, and it’s messing with your ability to use your pen with proper pressure sensitivity.

Since my Bamboo tablet pen has a button on it which maps to a right-click by default, I don’t need the “press-and-hold” right-click functionality, and you likely don’t either.

I hope this saves someone some frustration.

Wednesday, October 28, 2009

GetHashCode is useful, who knew?

If you’re like me, you’re inclined to lazily ignore warnings to override object.GetHashCode for your custom types if you’ve already overriden object.Equals.  If I’m using a Dictionary and using one of my objects as a key, then sure, I can see the point.  But if I’m just throwing it in a generic List, object.Equals is good enough, right?

Well, yes, but apparently this isn’t a safe assumption to make for any given collection type or operation.  I learned this the hard way with LINQ’s Enumerable.Intersect method (an extension method of IEnumerable<T>).

Without going into detail about set theory, the Enumerable.Intersect method will take two collections of objects, and return a collection of objects which both source sets contain.  So, for example, if I have two sets of ints:

A = { 1, 5, 7, 9 }
B = { 4, 5, 9, 13 }

The intersected set would contain only the values that both sets share:

{ 5, 9 }

Now, if the items in my sets are of my own custom type, I thought it would be sufficient to override object.Equals for this type.  But no, if I do this, Enumerable.Intersect will return an empty collection, indicating that none of the objects are equal, even if they areWhen I implemented object.GetHashCode as the compiler repeatedly pestered me to do, everything worked fine.