FPL Tech Talk

Computing the viewport size within a WPF Border control

2011-10-24T14:34:00.000-07:00

Copyright © 2011, Steven E. Houchin. All rights reserved.

I have a WPF application that renders a photo bitmap inside a System.Windows.Controls.Image control that is contained within a System.Windows.Controls.Border. If the photo bitmap is too large for the app window (either in the horizontal or vertical direction), I set the Image's corresponding size attribute(s) to 'Auto' (i.e. Double.NaN) within the Image's SizeChanged event handler. If the bitmap is smaller than the app window, I set the Image's size to the actual fixed size of the bitmap, so it doesn't get scaled.

But, that left a problem when I resized the app window smaller: a fixed-size Image was truncated by the border when the window shrank smaller than the photo's bitmap size. And, because the Image's width/height weren't set to Auto, its SizeChanged event wasn't firing.

However, the Border's SizeChanged event was firing. So, I added that handler for the Border control, planning to set the Image's proper width/height after resize. That left another problem in this new event handler: how to calculate whether or not the Image control's width/height should be Auto or fixed. Put another way, what was the size of the viewport inside the Border control where the Image would be rendered?

The Border's SizeChanged event handler is passed a SizeChangedEventArgs parameter that provides the new width/height of the Border control. The size available to the Image control inside that will clearly be smaller, but by how much? Here is the algorithm in C# that I came up with (keep in mind that a negative BorderThickness means the border is drawn outside the control's drawing area):


// Calculate the Border control's new viewport
// size within the drawn border where the Image control
// is rendered (add in any padding and non-negative
// border thickness).
Size viewport = new Size();
viewport.Width = e.NewSize.Width -
    (border.Padding.Left + border.Padding.Right) -
    ((border.BorderThickness.Left > 0) ?
        border.BorderThickness.Left : 0) -
    ((border.BorderThickness.Right > 0) ?
        border.BorderThickness.Right : 0);
viewport.Height = e.NewSize.Height -
    (border.Padding.Top + border.Padding.Bottom) -
    ((border.BorderThickness.Top > 0) ?
        border.BorderThickness.Top : 0) -
    ((border.BorderThickness.Bottom > 0) ?
        border.BorderThickness.Bottom : 0);

This viewport variable now holds the size available for the Image control inside the border. Now, all I have to do is determine if the Image needs to be scaled down in the viewport or set to a fixed size. One thing I discovered is that the Image's Margin value must be taken into account, since it is also rendered inside the viewport along with the photo bitmap. The code to determine the right sizing, in this case for the width is:


// Calculate the image's real width to determine if
// scaling is needed
double imageWidth = _bitmapActualSize.Width +
    image.Margin.Left + image.Margin.Right;
if (viewport.Width > imageWidth)
{
    // Restrict the Image control's width to the
    // bitmap's actual width
    image.Width = _bitmapActualSize.Width;
}
else if (viewport.Width < imageWidth)
{
    if (Double.NaN != image.Width)
    {
        // Set the Image control's width to 'Auto' so
        // it will scale down to fit
        image.Width = Double.NaN;
    }
}

The same calculation is done for the Image height immediately after. This results in the proper change to the photo bitmap size just at the right time.

Eliminating Visible Image Borders on Blogger

2011-08-31T18:31:00.000-07:00

Copyright © 2011, Steven E. Houchin

Something that has driven me crazy for quite awhile about Blogger is its propensity to place a thick white border around any image I added to my postings. Editing the HTML of the img element to include border="0" or a style="border: none;" or anything else like that was simply ignored. What the heck was happening?

Then, I found a hint on another site, where it referred to Blogger's "template style sheet." After some poking around in Blogger, I stumbled across it. When logged in, navigate to the Dashboard page, then select the Design tab (or link), then click the Edit HTML link along the top. This brings up a screen that allows editing of your blog template, which contains the HTML, CSS, and Javascript that is the basis for every posting. On this template page, it suggests you download your existing template before messing with it, which sounds like good advice. Under the Edit Template heading is the text of the template which you can alter.

Okay. Now to the nuts and bolts of what I did to eliminate the image border. In my template, there was a CSS directive like this:

.post-body img,  .post-body .tr-caption-container { 

   padding: 8px;

}

The 8 pixels of padding is the border I saw, because it seems to inherit a white background color from elsewhere. My images are controlled by the ".post-body img" class. So, I deleted that class specification from the above and created a new one that had the padding and background specifications I wanted:

.post-body .tr-caption-container {

  padding: 8px;

}



.post-body img {

  padding: 8px;

  background: $(post.background.color);

}

This keeps the padding (which I like since it provides some separation between the image and the text) and makes the background color for the image's box the same as the post's color. The $(post.background.color) value is, I think, a variable handled by Blogger's XSL processing that is replaced in the final output with the actual color (or "transparent" in my case).

Once I saved these CSS changes to my template ... voila! The image borders in all my posts (new and old) vanished. In reality, all I really did was change the background color of the padding for just the images.

Finding IWin32Window in WPF

2011-08-11T16:44:00.000-07:00

Copyright © 2011, Steven E. Houchin

I'm developing a WPF desktop application (C# and .NET 3.5), and I need to pop up a dialog window that allows the user to browse for a folder. .NET provides a convenient (and bland) dialog that does this: System.Windows.Forms.FolderBrowserDialog. To pop up the dialog in a modal mode, I need to call the ShowDialog method. I want this dialog to be a child window of my main window, so I have to pass the parent window to ShowDialog, which should be straightforward given the "owner" paremater to the method:

ShowDialog(System.Windows.Forms.IWin32Window owner);

The problem is, the parent of the dialog is of type System.Window, so "this.Owner" can't be passed as ShowDialog's "owner" parameter. So, given that I have a WPF System.Window-derived class, where do I obtain an IWin32Window?

Well, it turns out I have to write a little code for it. Specifically, I have to implement the IWin32Window interface on the parent window class:

public partial class Main : Window,

    System.Windows.Forms.IWin32Window

{

...

   #region IWin32Window implementation

   IntPtr System.Windows.Forms.IWin32Window.Handle

   {

      get

      {

         return ((HwndSource)

             PresentationSource.FromVisual(this)).Handle;

      }

   }

   #endregion

...

}

With the IWin32Window.Handle property now implemented in the parent class, I can simply call ShowDialog(this). Note that you must also include a "using System.Windows.Interop" for this to work.

Kernel Driver Signing - Part III

2010-09-22T12:13:00.000-07:00

Copyright © 2010, Steven E. Houchin

In Parts I and II of this article, I discussed the requirement for driver signing, digital signatures, and how to go about testing signed drivers.

The last step is the actual signing of the binaries that you integrate into the customer product. In order to do this, you must first purchase a digital certificate from a reputable certificate authority (CA). In fact, for kernel mode drivers, you must purchase your digital certificate from Verisign. Certificates from other vendors can be used to sign the binaries, and Windows installs them, but it refuses to execute those binaries (as of Windows 7).

As I've mentioned in the earlier parts of this article, the step-by-step procedures for driver signing are contained in a document at the Windows WHDC site, and need not be repeated here. It contains a section titled "The Kernel-Mode Code-Signing Process." The important decision to make is whether to set up the digital signature via a catalog file (specified in the INF file), or to sign the binaries directly. A cartalog is preferable, especially if you are signing multiple files; but that won't work if your binaries start at boot time (see StartType in your INF fle). In that case, signing the binarys themselves is required. Microsoft has another site, titled "Signing Drivers for Public Release", that gives more details about the files you may receive from your CA.

When you distribute your product for the customer to install, the installer package must include, in addition to the binaries, the INF file, signed catalog files (if any), and the public key portion of your digital certificate. The public key digital certificate (.spc or .cer file) must be installed on your customer's system. Your original private key digital certificate (.pvk file) should be locked away, because it is used in the signing process.

Kernel Driver Signing - Part II

2010-08-09T13:53:00.000-07:00

Copyright © 2010, Steven E. Houchin

In Part I of this article, I explained that all kernel drivers on 64-bit Windows systems must be digitally signed.

There are two ways of signing kernel drivers: embed the signature in the driver binaries themselves, or use a signed catalog file. To peform driver signing, you really must have the latest Microsoft WDK installed on your signing system.

For drivers that start at boot time (see StartType in your INF fle), the binary itself must be signed. Use of a catalog file is not enough, though is also required if installing the driver package via INF file. For other types of drivers - especially those that contain multiple files - a signed catalog file can be used to identify all the files in a driver package.

Use of a catalog file requires that the driver package be installed via an INF file, because that is where the catalog file is specified. For example, ADriver.inf will have the following line included in its [Version] section:

CatalogFile=ADriver.cat

After your driver binaries are all built and copied to a "package" directory (which includes the INF file), a catalog file is created using the WDK's Inf2Cat utility. For example, if your package files are in C:\MyDriverPackage, the catalog file (in this case for Win2K and Win64 systems) is created via:

Inf2Cat /driver:C:\MyDriverPackage\ /os:2000,Server2003_X64

This utility will scan all INF files in the given directory and create catalog files for each one using the "CatalogFile" line.

Once the catalog files are created, they must be signed using WDK's SignTool utility and your digital certificate information. The details for catalog file creation and signing, and driver binary signing, are at the Windows WHDC site, which contains white paper that has decent step-by-step procedures.

The catalog file and INF file go together as a pair wherever the signed driver package is to be installed. If your INF file is also used for 32-bit drivers, then your 32-bit installer should comment out the "CatalogFile" line in the [Version] section so that a signing certificate isn't needed on those systems.

Kernel Driver Signing - Part I

2010-07-27T16:46:00.000-07:00

Copyright © 2010, Steven E. Houchin

Back in January of 2006, Microsoft announced - much to developers' dismay - that all kernel drivers on 64-bit Windows systems must be signed. Signing is defined as:

the process of assigning an encrypted digital signature to executables in order to confirm the software's author and to guarantee that the code has not been altered or corrupted

Once I ported my client's driver code to 64-bit, I found myself in an "uh-oh" situation: how do I test the changes on my development systems without having my client's digital signing certificate? A digital certificate is:

a digital signature from a certificate authority (CA) that contains a private key used to sign some software, which must match the public key in the CA's certificate installed on a user's system

The private key (PK) is necessary for me to sign the driver executables, and is something that the software vendor (my client) must not pass around to anyone else - including me - lest it fall into the wrong hands and be used for malicious signing. That gets us back to my dilemma: how do I test without the PK?

The answer provided by MSFT is Test Signing. The Windows WHDC site contains a good white paper on this subject that has decent step-by-step procedures. The basic idea is this: a developer can create a Test Certificate, which is used on the development systems to sign and validate executables. The catch is, the executables will only work if the target test system is configured to boot into a special Test Signing mode. This is done on the target system with the BCDEDIT command. Note that, in the past, it was also possible to boot Windows into a "Disable Driver Signature Enforcement" mode, where signatures were ignored. That option, while still visible via F8 boot options, does not actually work anymore.

Next time: Test Signing using catalog files.

The Mysterious Missing Attribute

2009-09-03T16:07:00.000-07:00

Copyright © 2009, Steven E. Houchin

Something about my XP system has been driving me crazy for a long time. I use Visual Source Safe for source control of my development projects on. VSS makes use of Windows’ Read Only file attribute to prevent modification of source-controlled files in a project’s working directory. When a file is checked out of VSS, that attribute is cleared, and the user can then change the file. When checked back in, Read Only is set again.

So, what was my problem? It’s this: the Read Only attribute on those source-controlled files (and others) would simply disappear periodically. I’d have to go through all my files and reassert Read Only by hand. I looked into a number of causes: that VSS was doing it, or Visual Studio; maybe it was compiling the files over a network share; maybe it was my anti-virus software.

Then I stumbled across the cause: backing up the files to a CD via Windows Explorer. It seems that somebody in Redmond Land decided it would be a clever idea to clear the Read Only attribute for all files burned to a CD. When I searched the web for others with this problem, I actually saw the opposite complaint: that files retained their R/O attributes on a CD. Okay, so what? The CD is … wait for it … wait for it … READ ONLY!

Maybe there is some obscure Windows setting that will stop this behavior on my system. Let me know if you find one. In the meantime, I now have to first copy my files into a zip file, then back up the zip – a real pain.

So, call me crazy. This problem has certainly driven me mad.

Setting a Win32 Control's Font and Sizing It to Fit the Text

2009-04-27T17:55:00.000-07:00

Copyright © 2009, Steven E. Houchin
In my latest application, I have a Static control that I use as a label at the top of a rectangular box. I wanted to change the font, then resize the control to fit the text exactly. First, I needed to set the font. This is done by initializing a LOGFONT structure for the desired font family and size. The code below speicifies the minimum LOGFONT fields necessary:

LOGFONT lf;

ZeroMemory(&lf, sizeof(LOGFONT));

lf.lfHeight = 12;

_tcscpy(lf.lfFaceName, _T("MS Sans Serif"));

Now that we have a LOGFONT, a Win32 font object needs to be created and associated with the control:

// the LOGFONT must have some valid data in it

HFONT hFont = CreateFontIndirect(&lf);

if ((HFONT)0 != hFont)

{

     SetWindowFont(hCtrl, hFont, TRUE);

}

The SetWindowFont call is really a macro that expands into a call to SendMessage that specifies the WM_SETFONT message. At this point, when the control is redrawn, it will use the new font.
Now, we need to resize the control so it fits exactly the text it contains. Let's assume the variable lpszText points to our null-terminated text string that the Static control already displays. We must call the Win32 GetTextExtentPoint32 function to get the dimensions of the text. This function requires the device context (DC) of the control. And, to make sure we're getting the proper dimensions, our new font must be selected into the device context.

HDC hdc = GetDC(hCtrl); // get the static control's DC

HFONT hfOld = reinterpret_cast<hfont>(SelectObject(hdc, hFont));

DeleteObject(hfOld);    // free the old font handle



// measure the text height and width

size_t iLen = _tcslen(lpszText);

SIZE s;

if (GetTextExtentPoint32(hdc, m_pszLabelText, static_cast<int>(iLen), &s))

{

     // control's x,y position set by CreateWindow

     POINT p = this->ptControlOrigin;

     MoveWindow(hCtrl, p.x, p.y, s.cx, s.cy,

     FALSE /* no repaint now */);

}

ReleaseDC(hCtrl, hdc); // free the DC

That completes the task. We've changed the control's font to 12 point "MS Sans Serif" and have resized the control to fit the control's text string exactly. If the control's text string is changed, then the calls to GetTextExtentPoint32 and MoveWindow must be repeated for the new string's length.

Machinations to Set Text Color in Win32

2008-08-04T17:50:00.000-07:00

Copyright © 2008, Steven E. Houchin
Recently, I wanted to set the text color for a Win32 Static control within a dialog window. I'm a relative novice when it comes to old fashioned Win32 message pump applications, so I had to scrounge around for the right API calls to do this. I assumed there must be a simple one-time call to set the text attributes for a given control. Silly me.
It took some digging to discover that the answer was to handle the WM_CTLCOLORSTATIC message. The M*soft documentation states that this message is sent when "a static control, or an edit control that is read-only or disabled, ... is about to be drawn." In other words, the color is modified right before the text gets drawn. It seems you have to do this each and every time you wish to draw the text, not just as a one-time setup. So I wrote this:



case WM_CTLCOLORSTATIC:

{

     HDC hDC = (HDC)wParam;

     ::SetTextColor(hDC, RGB(255,0,0)); // red text

     return TRUE;

}

Seems simple enough. The result? Plain old black text. It turns out that WM_CTLCOLORSTATIC requires an HBRUSH as its return value. Since TRUE isn't a valid brush, it ignored the whole thing. So, where do I get a brush? The documentation says the brush will be used to paint the control's background. I tried this:



return (LRESULT)::GetStockObject(HOLLOW_BRUSH);

The result was red text with each character on a white background. Plus, the old text wasn't erased when new text was written to the control. I realized that HOLLOW_BRUSH is essentially no brush, so the old text wasn't getting wiped. I needed the brush for the control's plain old gray background. So, I tried this:



...

COLORREF bg = ::GetBkColor(hDC);

HBRUSH hb = ::CreateSolidBrush(bg);

return (LRESULT)hb;

Surely this would work. Nice try, but no cigar. This fixes the problem of ghost text hanging around. But it has the side effect of turning the control's background entirely white. In other words, GetBkColor() is returning white, even though the background of the dialog is the usual gray. So, two problems still remain: the character background is white, and now the control's background is white. For the first problem, I discovered this:



...

::SetBkMode(hDC, TRANSPARENT);

::SetTextColor(hDC, RGB(255,0,0)); // red text

...

By temporarily forcing the returned brush to a stock light gray (using GetStockObject()), I could see that the text backgound was now what I wanted: red text on the control's background color (stock light gray).
So, where could I get the dialog's usual gray background to return as a brush? After lots of searching around, I discovered the answer: send a WM_CTLCOLORDLG message. This message returns the background brush for the dialog box, as long as I'm not handling that message myself in DlgProc() - which could cause a chicken-and-egg problem.



...

HBRUSH hBrush = (HBRUSH)SendMessage(

     hDlg,

     WM_CTLCOLORDLG,

     (WPARAM)hDC,

     lParam /* the control's HWND */);

     return (LRESULT)hBrush;

I executed this and ... ugh! This set me all the way to black text on the gray background. My previous attempts told me that the problem was an invalid brush. Later, I was moving around the code into separate functions, and it accentally started to work. I had done this:



...

HBRUSH hBrush = (HBRUSH)SendMessage(

     hDlg,

     WM_CTLCOLORDLG,

     GetWindowDC((HWND)lParam),

     lParam /* the control's HWND */);

Voila! A miracle occured. I finally see the result I wanted from the start: red text on the standard gray background. All of that work just to draw RED TEXT!
I'm guessing that the HDC provided via 'wParam' is for the text
glyphs, which is different than the HDC associated with the control's HWND via 'lParam'. Here's the final magic code:



DlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)

...

case WM_CTLCOLORSTATIC:

{   

     // handle just for my MSG control

     if ((HWND)lParam == GetDlgItem(m_hDlg, IDC_STATIC_MSG))

     {

          HDC hDC = (HDC)wParam;  // use for the text

          ::SetBkMode(hDC, TRANSPARENT);

          ::SetTextColor(hDC, RGB(255,0,0)); // red text

          HBRUSH hb = (HBRUSH)SendMessage(

               hDlg,

               WM_CTLCOLORDLG,

               (WPARAM)GetWindowDC((HWND)lParam),

               lParam /* the control's HWND */);

          return (LRESULT)hb;

     }

}

The WM_CTLCOLORDLG also works by using 'hDlg' instead of 'lParam', even though it results in different hDC's. It would also be possible to send a WM_CTLCOLORSTATIC message itself to get an HBRUSH, but that seems like it could result in an infinite loop - sending a message from the same message's handler. I suppose a different target HWND might avoid that. So, it now works, but I don't know all the details under the hood.

Accessing Attributes in AssemblyInfo.cs

2008-05-14T16:56:00.000-07:00

Copyright © 2008, Steven E. Houchin
For a new C# .NET application, an AssemblyInfo.cs file is automatically created. It contains empty attributes that can be used to describe the assembly. These attributes are queried by Windows when the Properties of an executable are examined from Windows Explorer. They are also useful within the application itself to set the string in the title bar and for populating an About dialog. For example, I set the following values for one of my applications (with names changed to protect confidentiality):



[assembly: AssemblyTitle("My Application")]

[assembly: AssemblyCompany("Forest Park Lab")]

[assembly: AssemblyProduct("My Product")]

[assembly: AssemblyCopyright("Copyright © 2004-2008, Forest Park Lab.")]

[assembly: AssemblyTrademark("My Product ™ is a trademark of Forest Park Lab.")]

Setting these values doesn't make them automatically available to your application code. In order to access them, I have a piece of boilerplate code I include in the AssemblyInfo.cs file to make these attributes readily accessible. I define an "AssemblyInfo class" as follows:



using System.Reflection;

using System.Runtime.CompilerServices;



public class AssemblyInfo

{

   private AssemblyTitleAttribute  _title = null;

   private AssemblyCopyrightAttribute _copyright = null;

   private AssemblyProductAttribute _product = null;

   private string    _version;



   public AssemblyInfo()

   {

      System.Reflection.Assembly assembly =

      System.Reflection.Assembly.GetExecutingAssembly();

      // get the version string

      _version = assembly.GetName().Version.ToString();



      // get other desired attributes

      object[] attributes = assembly.GetCustomAttributes(false);

      for (int i = 0; i < attributes.Length; i ++)

      {

         if (_title == null)

         {

            _title = attributes[i]

               as AssemblyTitleAttribute;

            if (_title != null)

               continue;

         }

         if (_copyright == null)

         {

            _copyright = attributes[i]

               as AssemblyCopyrightAttribute;

            if (_copyright != null)

               continue;

         }

         if (_product == null)

         {

            _product = attributes[i]

               as AssemblyProductAttribute;

            if (_product != null)

               continue;

         }

      }

   }

   public string Title  { get { return _title.Title; } }

   public string Product  { get { return _product.Product; } }

   public string Copyright  { get { return _copyright.Copyright; } }

   public string Version  { get { return _version; } }

}

The way this code works is that it fetches all of the customizable attributes from the assembly (GetCustomAttributes()) into an array of objects. It then loops through each object and attempts to cast it (using the C# "as" operator) to one of the desired attribute types. If the cast fails, the result is null. Otherwise, the object is remembered as a property within the AssemblyInfo class for later access by the application.
To make use of these attributes in the application, simply create an instance of the AssemblyInfo class and access the properties, as follows:



AssemblyInfo appInfo = new AssemblyInfo();

// set the title in title bar

this.Text = appInfo.Title;

// set the product name

this.lblProduct.Text = appInfo.Product;

Shared .NET Configuration Files

2008-04-15T18:03:00.000-07:00

Copyright © 2008, Steven E. Houchin

One C# .NET application I’ve been working on for a while consists of two executables: a main application and a taskbar tray applet. The two apps needed to share common configuration settings, which I planned to implement via the app.config file. The way .NET is set up (I’m using .NET 1.1), each .EXE loads its config file based upon the executable’s file name. For example, xyz.exe loads xyz.exe.config. This is a problem when abc.exe needs to access the same config settings. Now, .NET may have some clever API to solve this problem, but I didn’t find one.

My answer to the situation was to create a file named common.config, which I placed within the project for a shared library. Inside this config file are the <appSettings> and </appSettings> tags, with the application’s key, value pairs coded inside:

<appSettings>

<add key="database_type" value="MSACCESS"/>

<add key="datasource" value="mydatabase.mdb"/>

<add key="default_browser" value="C:\Program Files\Internet Explorer\iexplore.exe"/>

</appSettings>

Once the common.config file was created, I needed to reference it from each executable’s app.config file. I accomplished this using the “file=” parameter of the <appSettings> tag. Below is my entire app.config file, which I duplicate in the projects for the main application and a taskbar tray applet:

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

<appSettings file="common.config">

</appSettings>

</configuration>

Note that the above does not include path information for common.config. The reason for this is that common.config is installed on a user’s system in a single directory, along with the application executables. Thus, simply using the current directory is appropriate. However, this doesn’t work when using the Visual Studio development environment, where each part of the application is built in a different directory. So, for each executable to find this file during Debug execution, I added a Pre-Build Event to each executable’s project, which first copies common.config to that project’s directory:

copy $(SolutionDir)MyCommonDll\common.config $(TargetDir)

With this done, I now have a configuration file that is shared by each executable in my application.

MSMQ Startup Failure on XP Pro

2008-03-31T16:40:00.000-07:00

Copyright © 2008, Steven E. Houchin

Yesterday, I installed an application I'd written onto a new machine. It uses Message Queuing for two processes to communicate with each other, so I needed MSMQ installed and running on the new machine (which is XP Pro). Much to my surprise, the MSMQ service refused to start. In Event Viewer, I saw the following cryptic error:

Event Type: Error
Event Source: MSMQ
Event Category: Kernel
Event ID: 2047
Date: 3/30/2008
Time: 1:31:10 PM
User: N/A
Computer: ********
Description:A connection to the Distributed Transaction Coordinator cannot be established. Consequently, transactions cannot be supported.

Uninstalling and reinstalling the MSMQ Windows components (via Add/Remove Programs) still resulted in failure. After hours of fruitless research on the web, trying a half-dozen search keyword combinations, I finally found the answer. The problem -- just as the error message says -- was with the Distributed Transaction Cordinator service (MS DTC). This is apparently a facility that MSMQ uses for routing its messages.

The problem was apparently that MS DTC service needs to execute under the NETWORK SERVICE user in order to work properly with MSMQ. I didn't have to do this on my other XP system, so something I installed (such as .NET 3.5?) on this newer system seems to have messed up either MSMQ or MS DTC.

The actual process for the fix is:

a) Uninstall MSMQ
b) Stop the MS DTC service
c) Change MS DTC's execution user to NETWORK SERVICE
d) Open a Command Prompt and execute "msdtc -resetlog"
e) Restart MS DTC
f) Install MSMQ

Lots of mystery here, but others on the net have seen this same MSMQ problem. Does anyone out there know more about what's going on?

VISITOR Design Pattern

2008-02-18T14:44:00.000-08:00

Copyright © 2008, Steven E. Houchin

I ran into an architectural problem after I developed a generic library class, SQLDbConn, that connects to a SQL database given a connection string. It implements an interface IDbConn that can also be used to implement a similar class for MS Access or other databases. An instance of SQLDbConnis created by the application via a Factory function:

static public IDbConn MakeDatabaseConnFactory

(DatabaseConnType eType)

After a databse connection is made through this "Connection" object, the nuts and bolts of accessing the database and retrieving rowsets is done using an application-specific "Model" object, defined by an IDbModel interface. For a SQL connection, that would be an instance of the SQLDbModel class.

Here's the design problem I encountered: the application shouldn't have any hard-coded knowledge of what kind of database it is using. It only has a reference to its IDbConnobject after calling the Factory function above. So, it needs to instantiate its Model object without knowing it will actually be a SQLDbModel object. I don't want to put the logic in SQLDbConnto create it, because that Connection class is generic, so shouldn't know about the application-specific Model class. I also don't want to simply create another Factory function - though that would work - because I have already created a database-type aware object - the Connection object - that knows what kind of database is in use. So, how do I get the generic Connection object (SQLDbConn) to create the specific Model object for me, and still remain application neutral?

The solution I came up with uses the VISITOR design pattern. I added the VISITOR pattern's accept method to the IDbConn interface:

bool AcceptVisitor(IDbConnVisitor visitor);

This allows my application to generically extend the connection object's functionality after its instantiation. The IDbConnVisitor interface referenced above specifies a visitmethod for each type of supported database, but does not dictate what that method does (they could order sandwiches from the deli):

public interface IDbConnVisitor

{

   bool VisitMsAccess(IDbConn dbConn);

   bool VisitSqlOle(IDbConn dbConn);

   bool VisitSqlDa(IDbConn dbConn);

}

Since each instance of a Connection object (like SQLDbConn) knows what kind of database it is, it can call its appropriate visit function, without knowing what that function actually does. For the SQLDbConnclass, its acceptfunction looks like this:

public bool AcceptVisitor(IDbConnVisitor visitor)

{

   try

   {

      return visitor.VisitSqlDa(this);

   }

   catch (System.Exception excp)

   {

      _errorText = excp.Message;

   }

   return false;

}

An MS Access Connection object's AcceptVisitor would similarly call VisitMsAccess.

My application then defines an implementation of IDbConnVisitor via a new class, such as CreateDbModelVisitor, whose job is to provide functions that will instantiate the appropriate Model object for any of the supported database types. Inside, it has a property of type IDbModel that the visitor methods instantiate:

public class CreateDbModelVisitor : IDbConnVisitor

{

   ...

   protected IDbModel _model = null;

   ...

   public bool VisitMsAccess(IDbConn dbConn) { ... }

   public bool VisitSqlOle(IDbConn dbConn) { ... }

   public bool VisitSqlDa(IDbConn dbConn) { ... }

   public IDbModel Model { get { return _model; } }



}

For the SQL database, the visitmethod implementation within CreateDbModelVisitoris as follows:

public bool VisitSqlDa(IDbConn dbConn)

{

   _errorText = "";

   try

   {

      if (dbConn.IsConnected)

      {

         _model = new SqlDbModel(dbConn);

         return true;

      }

      else

      {

         _errorText = "Database has not been connected."

      }

   }

   catch (System.Exception excp)

   {

      _errorText = excp.Message;

   }

   return false;

}

Putting it all together, the application would do the following:

IDbConn dbConn = MakeDatabaseConnFactory(config.DbType);

IDbConnVisitor dbVisitor = new CreateDbModelVisitor();

if (dbConn.AcceptVisitor(dbVisitor))

{

   IDbModel model = dbVisitor.Model;

   ...

   // make Model calls here to access database

}

Note that the only thing the application knows of its database type is a value that it picks up from a config file.

By using a VISITOR design pattern, the database-specific Connection object (IDbConn), which is supposed to be application neutral, can execute an application-specific function (via AcceptVisitor) for that particular type of database, without knowing the details of what that function does. It just calls the accept method, and that's that.

Fun with DataGrids

2008-02-13T15:43:00.000-08:00

Copyright © 2008, Steven E. Houchin

Recently, I was implementing a DataGrid for an ASP.NET application. ASP.NET is not usually my forte, so I was once again in learning mode.

The first obstacle I stumbled onto was that a lot more columns were displayed when the page came up than what I intended. My DataSource was an ArrayList of objects, which represented information culled from the database. In the page's Page_Load function, I had code that created each column explicitly, using ButtonColumn and BoundColumn objects. The extraneous unwanted columns that displayed were duplicates of the DataSource object's properties.

I discovered the problem was with the AutoGenerateColumns property of the DataGrid. Its default value was True, which causes a DataGrid object to automatically create columns (duh!) identical to the DataSource object's properties ... just what I was seeing. Setting this to False prior to assigning the DataSource value fixed that.

The next obstacle was that my ItemCommand handler wouldn't fire when I clicked on a ButtonColumn item in the list. Worse, my grid completely disappeared afterward. Searching around on the web revealed many others who also had this problem, but nobody seemed to have a good answer. There were some postings about EnableViewState related to this, but they didn't help.

Eventually, I discovered that when the Click event caused a PostBack to the page, the DataGrid reverted back to its initial empty state. My Page_Load code populated the DataGrid only when the call was not a PostBack. Armed with this insight, I changed Page_Load so a PostBack call only decides where to get the data: a database call for non-PostBack versus session variable on PostBack. The code now creates and binds the DataGrid columns each time through Page_Load, since my columns are created on-the-fly. The fixed code follows:





ArrayList allUsers = null;

if (IsPostBack)

{

   // restore array of all users

   allUsers = controller.GenericPageData as ArrayList;

}

else

{

      // get an array of all users as UserProfile objects

      controller.Model_GetAllUserInfo(ref allUsers);



      // save the user data in the controller

      controller.GenericPageData = allUsers as object;

}



if (null != allUsers)

{

   // set the array of users as the data source

   dgUsers.AutoGenerateColumns = false;

   dgUsers.DataSource = allUsers;



   // configure the columns

   ButtonColumn colName = new ButtonColumn();

   colName.DataTextField = "FullName";

   colName.HeaderStyle.BorderStyle = BorderStyle.Outset;

   colName.HeaderStyle.BackColor = Color.Ivory;

   colName.HeaderText = "Full Name";

   colName.CommandName = "View";



   BoundColumn colLogin = new BoundColumn();

   colLogin.DataField = "LoginName";

   colLogin.HeaderText = "Login Name";

   colLogin.HeaderStyle.BorderStyle = BorderStyle.Outset;

   colLogin.HeaderStyle.BackColor = Color.Ivory;



   BoundColumn colId = new BoundColumn();

   colId.DataField = "KeyId";

   colId.HeaderText = "Record Id";

   colId.HeaderStyle.BorderStyle = BorderStyle.Outset;

   colId.HeaderStyle.BackColor = Color.Ivory;



   // add the columns to the datagrid

   dgUsers.Columns.Add(colId);

   dgUsers.Columns.Add(colName);

   dgUsers.Columns.Add(colLogin);



   dgUsers.EnableViewState = false;

   dgUsers.DataKeyField = colId.DataField;

   dgUsers.DataBind();



   // set up the click and edit event callbacks

   dgUsers.ItemCommand +=

      new DataGridCommandEventHandler(this.UsersGrid_OnClick);

   return;

}