The Visual Studio IDE, among its myriad options and combinations and features and so forth, has a trio of rather odd key combinations:
CTRL-T - Interchanges the current letter and the one after it.
CTRL-SHIFT-T - Same thing, only for the current word.
ALT-SHIFT-T - Same thing, only for the current line.
These keybindings have been there at the very least since Visual Studio 4, where I first came across them.
And I wonder - what are they good for? Is there anyone that uses them regularly, or at all? What are they good for?
I'm really surprised at how hard it is to find a good DateTimePicker control that meets all our requirements:
1) Must suppost null dates, like the Due Date datepicker in Outlook tasks.
2) Must be an ActiveX, and supported inside both .NET winforms and Outlook forms.
3) Be generally bug-free and supported.
Doesn't look that hard, does it? But still I've wasted my time on many options, among them:
1) Janus Windows Forms Controls for Microsoft .NET. They have an excellent WinForms package with Outlook-style, controls, but their ActiveX package is old and contains only a grid. Also, their prices are a bit high for this project.
2) DevExpress have a .NET and an ActiveX version of their DatePicker, which is also more than adequate. Again, prices are a problem - buying the suite is expensive, and getting only the XPressEditors component is even worse - over $1200 when all we need is a datepicker?
Addendum: The control does NOT work properly on Outlook forms - the dropdown doesn't.
3) CodeJock have a nice ActiveX Calendar Suite with a datepicker that has good features, but for some reason is implemented as a MonthCalendar display only - no pop-up calendar.
4) NeoComponents have an ActiveX Calendar suite, with a datepicker that crashes and burns when added to an Outlook form.
5) XE Software have a nice little date control too, which unfortunately doesn't allow None as a valid date choice.
6) *New* TeamScope have an Outlook Developers Library, including lots of libraries for working with Outlook solutions, and a good ActiveX DatePicker too. The problem? The font for the month name is fixed and unchangeable, and isn't set to a Hebrew codepage. How silly is that?
After fiddling with those for a while, I decided to try a different approach - extending the basic DateTimePicker control with the None option, or simply wrapping a good .NET control as an ActiveX.
1) Messing with the .NET DateTimePicker is nasty - it calls the API to use the Windows Common Controls for the picker and the calendar, and adding a button there is really annoying - Many calls to SetParent and SetWindowPos and interfering with the WndProc before I could get my button sync'ed in with the calendar, and it still doesn't look as good as a calendar built for it.
2) Wrapping a .NET control as an ActiveX to be used by Outlook Forms is also problematic, messy and unsupported. Current status, with the help of some good people, can be found on OutlookCode. However, if the Janus suite is chosen for the project (Regardless of the DatePicker) I might have to use this.
Does anyone have a simple, miraculous cure for my problems?
ADDENDUM:
John R. Durant, over at the MSDN Office Developer Center, blogs about the .NET Controls on Outlook Forms problem.
A little tip when we're generating HTML content on-the-fly using client-side code, whether HTC behaviours or javascript:
As we all know, when we try to View Source on such a page, the HTML we see is the base HTML that was received from the server, not the final layout after all the client-side code has run and changed things. This often makes it hard to debug, since we can't see the final layout that the user sees. This technique will help us get the final, rendered page for debugging.
We'll add this script block to the end of our HTML:
<script defer language="javascript">
var oFS = new ActiveXObject("Scripting.FileSystemObject");
var oDump = oFS.CreateTextFile("RenderedPage.html", true);
oDump.Write(document.body.innerHTML);
</script>
This can be written with our choice of scripting languages, of course. I don't know if other platforms have objects equivalent to the FileSystemObject for easily creating a text-file. We'll have to allow the browser to run ActiveX's for this to work, of course.
The RenderedPage.html file we save here is the final version of the page as it is rendered, running after all other code has run (at least code that runs on load). This can often point the way to the source of the bug - especially layout bugs.