Posted on

Sharing a Class In ASP.NET Pages

It’s easy enough to create additional classes that can be used in the code behind files of an ASP.NET page, but what if you want to share a class among the ASP pages themselves? It’s quite common and easy to develop generic methods and event handlers that can reduce repetition of code and simplify the process of creating the different parts of your UI. In a recent project, I needed to create such a class and make it available to all my ASP pages. The class contained two methods that were meant to be called by the DataBind event of a GridView or DetailView in order to assign Javascript confirmations to all the Delete Commands and looked something like this…

namespace ProjectNameSpace {

 public class AdminUI {

 public void add_delete_confirmations_to_grid_view(object sender, EventArgs e)
 // Do stuff

 public void add_delete_confirmations_to_detail_view(object sender, EventArgs e)
 // Do stuff

Now that we have the class, we need to find the way to make it available to our ASP pages. The usual way to do this is via an entry in the web.config that makes the namespace available like this….


…which works fine if you intend on calling the method using ASP tags…

<% AdminUI.add_delete_confirmations_to_grid_view(); %>

…but the methods above aren’t mean to be used in ASP tags. They are meant to be assigned directly to events of ASP Controls like so…

<ASP:GridView OnDataBoundEvent="AdminUI.add_delete_confirmations_to_grid_view">

…which sadly, does not work. This seems to be something that was overlooked in ASP.NET. The former compiles, but the latter generates a “AdminUI namespace not found” type of error.

So in order to get around that, we are going to have to make use of inheritance.

Normally, the code behind classes for an ASP page are children of the System.Web.UI.Page like this….

public partial class Users : System.Web.UI.Page { }

Therefore, I can construct my AdminUI class as a middle layer between my ASP classes and System.Web.UI.Page by changing AdminUI to…

public class AdminUI : System.Web.UI.Page {}

… and all of my ASP classes to something like this…

public partial class Users : AdminUI { }

… and the assignment of the methods to their corresponding events becomes this…

<ASP:GridView OnDataBoundEvent="add_delete_confirmations_to_grid_view">

…and it works perfectly. All the methods that normally would have to be duplicated in multiple code behind files are in a centralized location and inherited by all of the classes so they can be used directly in the ASP pages without triggering a compiler error.

Posted on

Detecting USB Insertion/Removal in C# .Net 4.0

We need your help!

Cyber Sprocket is looking to qualify for a small business grant so we can continue our development efforts. We are working on a custom application builder platform so you can build custom mobile apps for your business. If we reach our 250-person goal have a better chance of being selected.

It is free and takes less than 2 minutes!

Go to
Click on the “Login and Vote” button.
Put “Cyber Sprocket” in the search box and click search.
When our name comes up click on the vote button.


And now on to our article…

C# Programming


While coding a new Windows desktop app for a client we ran into something that we thought we be fairly simple.  It has turned out to be a rather complex task. The goal: detect when a SmartDongle USB key was being inserted or removed & update our application interface at that time.

Our assumption was that a few minutes of searching the Internet and we’d find a dozen examples of people that have done it already or we’d just use the .Net 4.0 classes for device detection. Wrong on both counts. As ubiquitous as USB devices are these days, it appears that .Net 4.0 still does not have direct support via easy-to-use classes that you can just hook into. Searches of the Internet turned up a lot more people asking questions than viable answers. The few answers we found were outdated or half-answers.

Now that we’ve got basic USB insertion/removal detection working we decided we’d share that part of the solution. Our next challenge is to determine that we’ve inserted the SmartDongle and not some other USB device such as a keyboard, mouse, flash drive, or other USB item. Unfortunately the message handler we’ve got thus far only tells us that a device has changed (windows message WM_DEVICECHANGED), but does not hand off the parameters that would let us query the message stack to find out WHICH device changed. That will be a solution for another post I guess.

Our Environment

We are coding in C# using Visual Studio 2010 (VS2010) with the .Net 4.0 framework helping us along. We are coding a WPF main window, not a form, which can make a difference.

Our Solution

Here is the simplified way to detect that a USB device was inserted or removed from the system, and our call to a ReadDongle method that we wrote to get information from the dongle header (or not, if it was removed). You can call whatever function you’d like, or put your processing loop right inside the windows process handler.

using System.Windows.Interop;
public partial class MainWindow : Window
    public MainWindow()


    private const int WM_DEVICECHANGE = 0x0219;  // int = 537
    private const int DEVICE_NOTIFY_ALL_INTERFACE_CLASSES = 0x00000004; 

    /// <summary>
    /// </summary>
    /// <param name="e"></param>
    protected override void OnSourceInitialized(EventArgs e)
        HwndSource source = PresentationSource.FromVisual(this) as HwndSource;

    private IntPtr WndProc(IntPtr hwnd, int msg, IntPtr wParam, IntPtr lParam, ref bool handled)
        if (msg == WM_DEVICECHANGE)
        return IntPtr.Zero;



That’s it, now we know when a device is inserted or removed. We are overriding the OnSourceInitialized method for our main window, which basically is saying “hey, when the window is initialized and ready to accept external messages from the operating system, add a hook that latches onto the window’s message processing method (WndProc). We can then perform operations by sniffing out specific types of messages like “device changed” (WM_DEVICECHANGE) and doing our thing. When the WndProc override is done it drops back to the default method for further processing. We could override that by setting handled to true, but we don’t want to do that in our app… not yet anyway.

Hope our article helps provide a quick shortcut for someone that is googling stuff like “C# wpf usb insertion/removal”.

Posted on

Starburn SDK and .Net 4.0


We have been trying to get StarBurn to play well with others for a client project we have been working on lately. The problem is that StarBurn is very particular about the Windows environment, and though the support guys mean well the communication is sometimes hard to decipher. I don’t think English is their primary language, but can’t fault them there… they communicate much better in English than we speak French, or any other language for that matter.

Anyway, we deciphered some of their clues, experimented a bit, and finally came up with a step-by-step guide for getting the latest StarBurn SDK working well with our .Net 4.0 project. If you don’t get the right DLLs activated it will wreak havoc on your Visual Studio debug sessions and will not play well on most final release installs.


The first step is to make sure you have registered the StarBurn.X12.dll in your system registry via regsvr32:

1) Download & install latest StarBurn version. Make sure you have a January 2011 or later copy of StarBurn installed.

2) Run CMD as administrator. Search for “cmd” from the windows start menu, then right-click and “run as administrator”. If you do not run as admin you will get a cryptic error from Windows when using regsvr32.

3) CD to the StarBurn install directory. From the command prompt cd “…path-to-starburn-install”.

4) CD to the \Bin\Core\StarBurnX\x86 subdirectory.. Yes you could have done this all in one step, but I like to have the subdirectory spelled out so it is easier to find next itme around.

5) Register the DLL. Enter the command “regsvr32 StarBurnX12.dll”. You should get a message back with no errors saying the DLL was registered.

6) Remove any references to blah-interop-blah if you have them in your project. These references are wrong. Remove them. If you copied the setup from the sample solutions, they reference the Interop files, which is typically all you have to start with if you try registering anything StarBurn in your project prior to doing the regsvr32 trick noted above.

7) Add the corrrect StarBurnX 12.0 Type Library COM reference. Go to your project and add references. Click the COM tab. Look for the newly available “StarBurnX 12.0 Type Library” reference. This is what you want to add for .Net 4.0 Client Profile projects.

StarBurn COM Install
StarBurn COM Install



Here are some of the things you’ll see if this is not done correctly.

  • Application crashes immediately on boot.
  • Error code 8007007e simply means that a DLL that the application needs is not registered with the system.
  • A common error when you have problems with StarBurn is “Retrieving the COM class factory for component with CLSID
    failed…”. You can look for the CLSID by using regedit and searching for that string. This particular Class ID is registered to StarBurnX.StarBurnX, you can find it under HKCR/StarBurnX.StarBurnX/CLSID


Hope that helps some of you StarBurn developers out there.   It sure took us a while to figure out the best way to do this, maybe this will save you a few hours.