CRN reports Microsoft will release Preview 2 of VS.NET 2005 a.k.a. Whidbey at VSLive next week. Furthermore, the first beta can be expected in May at Tech Ed 2004.
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"
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:
HDN_BEGINTRACKwhen the user starts dragging a divider,
HDN_TRACKwhile dragging, and
HDN_ENDTRACKwhen the user has finished dragging the divider.
I've had no problem getting
HDN_ENDTRACK. Unfortunately, I didn't receive the
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
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.
Microsoft has delayed the release of SQL Server 2005 (formerly known as Yukon) and Whidbey (VS.NET 2005?) to H1/2005. I hope we get same betas till then.
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:
- I have a folder which contains the current sources synchronized with Vaultpub.
- 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.
- 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.
- 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