According to this page there is no way how to easily catch all exceptions which occur during callback processing (note that Page_Error and even global.asax Application_Error methods are not fired during callback processing). Of course, you can surround all of your codebehind callback methods with try ... catch blocks, but this is not elegent way how to catch all exceptions. We need one piece of code, where we can catch and process all unhandled exceptions.
The only solution I have found so far, is to create your own class which will derive from devexpress control, which you use to process callbacks (in our case ASPxCallbackPanel):

public class ASPxCallbackPanelExtended : ASPxCallbackPanel
{
    protected override string OnCallbackException(Exception e)
    {
        Logger.Log(e);

        return base.OnCallbackException(e);
    }
}

Than you will need to replace all existing ASPxCallbackPanelfrom your pages with ASPxCallbackPanelExtended:

<dev:ASPxCallbackPanelExtended ID="panPersonalData" ClientInstanceName="panPersonalData"
    runat="server" OnCallback="panelPersonalData_OnCallback" HideContentOnCallback="False"
    EnableCallbackCompression="true">
...
</dev:ASPxCallbackPanelExtended>

Yes, this solution is not perfect too, because you need to derive from all classes which can cause callbacks and override OnCallbackException method in your application (for example ASPxCallback), but this is the only solution I have found.

As a part of a client portal project we had a requirement to load documents displayed in the portal from a SharePoint document library. This seems like quite an interesting idea, because you don't need to build any fancy Content Management System (CMS) into your site for people to upload content and documents; they will just use standard SharePoint user interface to save documents into document library and your portal will take the content from there.

That's why I decided to create a generic component which will take documents from a document library on SharePoint and publish them as a part of any website.

The component loads data from a SharePoint Document Library:

And displays them inside a standard ASP.NET web application:

This article describes how you can build such solution.

Recently I've been struggling with setting up any Linux distribution under VirtualPC 2007. I needed to test a Firefox plug-in under Linux and didn't have a physical Linux machine.

I've tried several distribution and the problem was always with graphics - I didn't get the system working in graphical mode. As I found out the problem was in a colour depth - it should be 16bit.

I finally succeeded with PCLinuxOS 2007.

You can download the vhd file here:
http://rapidshare.com/files/204785798/linux_vhd.part01.rar.html
http://rapidshare.com/files/204794369/linux_vhd.part02.rar.html
http://rapidshare.com/files/204802696/linux_vhd.part03.rar.html

Or go to this page, where you can download other pre installed virtual machines.

"A complete guide to avoid memory leaks and unwanted caching in Office"

You may wonder why one should worry about memory management in C# (or any .NET application); the mighty Garbage Collector (GC) built into Common Language Runtime (CLR) should spare us from messing around memory management till the end of time (this is one of the reasons why we chose .NET and why we make fun of C/C++ developers, right ?). Well Garbage Collector may serve us well as long as we are inside our "managed world", but as soon as your code make calls to COM (which is exactly what you have to do if you want to work with Outlook or any other Office application) Garbage Collector won't always save you. I'm not saying GC will not do its job (it eventually will), but the problem is that you cannot tell when it will happen, i.e. when the GC will free unused objects and their COM references. In this article I'd like to illustrate using an example of Outlook automation that this may sometimes be a problem.

Lately I came across a requirement for an ability to remotely turn on computers in our company. Couple of team members (including me...) tend to work from home sometimes so they leave their PCs running when they leave the office so the next day they could access it over Remote Desktop. Do you spot a problem already? To be honest I did not realise this was a problem either ... until an electricity bill came in. The workstation PCs are running nonstop (no one really bothers to switch them off, what if they did not go to the office tomorrow ...), which obviously has very negative impact on the electricity consumption in our office.

So it was clear we need to do something about it. One can switch off a PC using Remote Desktop very easily (you can do it directly from Start menu), but having ability to switch off a computer remotely is useless unless you can then remotely switch on the computer again. And that is where Wake on LAN finds its place.

"Magic Packet"

Wake On LAN (sometimes referred as WOL or WoL) is a marketing term used for ability to bring computer out of Stand-By mode by sending it a special packet, called "Magic Packet".

When you shutdown Windows, all modern ATX-power based PCs do not switch off completely. Instead they enter a Stand-By mode, which means RAM, CPU and hard drives are switched off, but motherboard itself and a network card are still powered. To determine if your network card supports WOL, shut down your PC and check the Link LED on the network card - if it is still active, your network card is still powered and should support Wake on LAN.

Even though a PC is shut down, the network card is listening on the data layer (usually Ethernet) level and scans incoming packets for special character sequence. If it detects the sequence, it will turn on the PC. This sequence, called Magic Packet, has following structure:

If you develop client applications, very often you come across an operation which is taking long to complete. Basically, you have 2 options; You can either do nothing about it, let the application "freeze" and let user wait for end of the operation. The problem is that the user doesn't know what is happening so he will become frustrated ("Damn, this app is really slow...") and may even eventually kill the application from the task manager, thanks to the "feature" of Windows which will mark the window as "Not Responding" and will offer the user an option to end the process.

That is why asynchronous processing (aka. processing in background) comes in place. The idea is that you display a dialogue to the user that informs him/her that there is something going on and that it may take some time to complete; or you can even let the user work with the application and literally do all the processing in the background.

As the number of people in our team increases, it becomes harder and harder to share the knowledge amongst the team members, which is why I decided to create this site. The blog should be mainly focused on interesting features or problems with current and future technologies, such as Microsoft .NET or Microsoft Office Suite.

Hopefully this site will become valuable source of information not just for the Memos team, but also for other developers, and will help to reduce the development time, either by offering solutions or guidelines to solve particular problems.

LukeN 080608