"Read This First"

Fun Comments
Congratulations! You have purchased an extremely fine
device that would give you thousands of years of trouble-free 
service, except that you undoubtably will destroy it via some 
typical bonehead consumer maneuver. Which is why we ask you
to PLEASE FOR GOD'S SAKE READ THIS OWNER'S MANUAL CAREFULLY
BEFORE YOU UNPACK THE DEVICE. YOU ALREADY UNPACKED IT, DIDN'T
YOU? YOU UNPACKED IT AND PLUGGED IT IN AND TURNED IT ON AND 
FIDDLED WITH THE KNOBS, AND NOW YOUR CHILD, THE SAME CHILD WHO
ONCE SHOVED A POLISH SAUSAGE INTO YOUR VIDEOCASSETTE RECORDER
AND SET IT ON "FAST FORWARD", THIS CHILD ALSO IS FIDDLING
WITH THE KNOBS, RIGHT? AND YOU'RE JUST NOW STARTING TO READ 
THE INSTRUCTIONS, RIGHT??? WE MIGHT AS WELL JUST BREAK THESE 
DEVICES RIGHT AT THE FACTORY BEFORE WE SHIP THEM OUT, YOU 
KNOW THAT? 

Dave Barry, "Read This First"

HDN_TRACK and HDS_FULLDRAG

Development Comments

I'm posting this, because it took me two hours to find the issue.

I wanted to customize a listview's header control, i.e. changing its behavior when the user resizes a column. According to the MSDN documentation, the header sends following notifications:

I've had no problem getting HDN_BEGINTRACK and HDN_ENDTRACK. Unfortunately, I didn't receive the HDN_TRACK notification.

I've found many examples in the internet, which, instead of HDN_TRACK, intercepted the HDN_ITEMCHANGING notification. Well, after some more research, I've found a hint to the header control's style HDS_FULLDRAG, which causes the control to render its content while being resized. If this style is set, no HDN_TRACK notifications are sent. And the System.Windows.Forms.ListView's header has this style by default. That's ok, but what's not ok is that nowhere in the MSDN the relation between HDN_TRACK and HDS_FULLDRAG is documented.

I hope that if someone stumbles over this issue, Google will refer him to here. It would save him some time.

Update: I've got a request from Martin Welker, who asked how to remove HDS_FULLDRAG. I've found the article INFO: HDN_TRACK Notifications and Full Window Drag Style in the Microsoft Knowledge Base:

SUMMARY Starting with version 4.70 of ComCtl32.dll, the header control of a list view control in report view (LVS_REPORT) automatically receives the HDS_FULLDRAG style. When this style is set, the parent of a list view control receives HDN_ITEMCHANGING notifications, rather than HDN_TRACK notifications, when the column divider of the header control is dragged. To receive HDN_TRACK notifications, the header control of the list view control must not have the HDS_FULLDRAG style set. Note that the HDS_FULLDRAG style is ignored in versions of ComCtl32.dll prior to 4.70.

This article also includes some sample code how to remove the HDS_FULLDRAG style flag.

Stupidity

Site news, .Text Comments

Remember: if you patch your blogging engine, make sure everything works properly before publishing it! And backup everything!

Ok, what I'm talking about here is this: as you may know I'm using .Text as my blog backend. Instead of using the pre-compiled binaries, I'm using the sources, which I compile directly. In fact, I do this in several stages:

  1. I have a folder which contains the current sources synchronized with Vaultpub.
  2. Another folder contains my developer version. This is the one I'm working with in VS.NET and doing my builds. Here I customize .Text to my needs. E.g. I added a calendar and the search. After synchronizing with the vault folder, I test it locally. Additionally, I update the database when required.
  3. If the previous version works properly, I copy all files necessary for publishing to a third folder called live. This includes files such as the *.aspx and *.dll files. I change the home directory in the IIS administrator to this folder and test it again.
  4. Last but not least, if the live version runs without issues, I upload the files to my web server.

Generally, this process works pretty well for me. Unfortunately, last month I haven't tested properly, therefore a buggy version got uploaded to my server: Adding new entries was not possible. The worst thing is, I already changed my local sources to the .96 development version, which is not intended to go live.

Fortunately, I do backups of the sources whenever I update my web server. Though it took several days to find the time to investigate the bug, I finally managed to get my blog working again.

Long story short:

  • Test your software before releasing it (which I didn't)
  • Backup your sources at release (which I did -- fortunately)
  • You can expect more posts coming on this blog than in the past

Thanks your patience :-)