January 2009 - Posts
Working with Office product's API's can be a daunting task for several reasons. First, the API isn't always fully documented, and there can be a lot of gotchas for developers to find as they build an add-in for this popular software product. The author of Professional Outlook 2007 by Wrox has a lot of experience working with the Outlook API, as it's clearly visible with his writing style. He has a lot of knowledge that any Outlook developer needs to finish the job, plus includes several examples on each topic and includes his own helper code to work with the API.
Professional Outlook 2007 covers the several options for deploying add-ins. It starts out by walking through the creation of a macro using VBA. Macro's can be setup by using the inline macro designer by selecting the Tools > Forms > Design a Form. The designer support allows a developer to drag/drop fields onto the form and create a customized interface. Ken also discusses the options related to using Outlook Form Regions, a new feature only available in Outlook 2007. A form region embeds an icon in the Office ribbon so the user can activate the region (for certain region settings). While this is a nice option and separates the add-in from the actual form, the challenges are backward compatibility (as this feature isn't in Outlook 2003). Throughout the book, the book covers as many possible development options as there are with Office 2007, which are macros, COM add-ins, and VSTO, and across the various syntaxes and query mechanisms (like DASL) that are available.
Ken's book is filled with the gotchas (some times I debated as to whether the Outlook integration was even worth the hassle because of some of the many problems like random crashing, security issues, etc.) of Outlook development that every developer has to be aware of. He includes an entire chapter focused on the idea of real-world programming with Outlook 2007.
I think Ken does a good job of getting his point across, but in some areas the subject can come off dry; he includes his own personal source code that he reuses across projects. While helpful, I felt it was a distraction from the book a little bit. But overall, the book was great and I'd recommend it personally. Like all good books, this book wrapped up with a sample program that's always beneficial.
A free .NET charting control for .NET 3.5. This blog post by Scott Guthrie gives you links to where to download it. Check it out: http://weblogs.asp.net/scottgu/archive/2008/11/24/new-asp-net-charting-control-lt-asp-chart-runat-quot-server-quot-gt.aspx
To show an empty message in the RadGrid control requires setting the EnableNoRecordsTemplate to true. When this value is set to true, when no records are bound to the RadGrid, the NoRecordsTemplate appears. The template appears only when a non-null, empty data source is supplied to the DataSource property (or via a data source control). So a non-null result set must be supplied to display the template.
If you want the header to appear when the no records template appears, set the ShowHeadersWhenNoRecords to true. Otherwise, if false, a label appears.
If you happen to use the <% %> notation in your ASP.NET applications while using Telerik for scripts, I'd recommend using the <tel:RadCodeBlock> or <tel:RadScriptBlock> elements. For instance, if you have ASP.NET AJAX script that does the following:
<script language="javascript" type="text/javascript">
function dosomething() {
var ajaxControl = $find("<%= MyControl.ClientID %>");
.
.
}
</script>
You may get an error stating that "System.Web.HttpException: The Controls collection cannot be
modified because the control contains code blocks (i.e. <% ...
%>).", and a very unhelpful stack trace. The issue may be solvable by adding the following to your script:
<tel:RadCodeBlock id="rcb" runat="server">
<script language="javascript" type="text/javascript">
function dosomething() {
var ajaxControl = $find("<%= MyControl.ClientID %>");
.
.
}
</script>
</tel:RadCodeBlock>
This should solve the issue, because the RadAjaxManager intercepts the rendering process and the RadCodeBlock isolates this script outside of that process. The RadScriptManager is useful when the code is involved in an AJAX postback scenario. Telerik has a unique AJAX mechanism for posting back asynchronously, similar to the UpdatePanel but a lot more convenient. Sometimes these scripts need the RadScriptBlock because they may be a direct result of an AJAX postback that modifies the markup, or they may be involved in some other way.
Be aware of the <%= %> use; I tried doing something like:
<div id="<%= PanelID %>">
content
</div>
Where PanelID was a public property of a user control (the div was in the user control markup too), but this also caused the controls collection error, so I had to change to hard-code the ID instead, and maintain the value in two places.
I recently got the error Telerik is undefined in the $create definition of the RadAjaxManager. I couldn't figure out why I was getting this; I had everything setup correctly (all web.config settings and all). I read this: http://www.telerik.com/community/forums/aspnet-ajax/general-discussions/92631-telerik-is-undefined.aspx and realized that I didnt' have:
<location path="Telerik.Web.UI.WebResource.axd">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
Once I had this, whether I logged out or was originally unauthenticated, I did not get the Telerik is undefined error.
I wanted to announce that the Jan. 2009 edition of the ASP.NET Pro magazine features an article I wrote about developing a custom AJAX extender using the AJAX control toolkit was featured on the cover of the magazine. I am excited and very thankful that the first two articles appeared on the cover. If you get a copy of the magazine, or have online access, check it out.
SlickEdit is a popular development tool, with a lot of great features. One of these features is the ability to restore from a local backup. While SlickEdit taps into your source control to provide some excellent comparison operations, the tool I'm talking about uses the local file system to remember smaller, more frequent intervals of changes that you make to your software. From this, if you ever make a change you regret, the Backup History remembers.
I was saved on this the other day because I deleted something that SlickEdit backups retained and was able to restore the code; the backup tool compares the current file against the target version so you can do the comparison yourself. The Backup History is a tool window in VIsual Studio; in its toolbar, click the third button from the left, the diff tool for the current file. This opens up an editor that compares the two files, plus allows you to merge a single line change, or all of the changes specified, a handy feature.