Work

  • Accessing a Control Without Being Able to See It on a Windows Form

    Menu Key Displayed on KeyboardA coworker of mine had a problem and came to me for help. She had a windows form with a control on it that she wanted to edit or delete, but couldn’t see the control. It was listed in the properties box in the list of controls on the form, but when she selected it, she wasn’t able to click it on the form, because it was behind another control.

    I hypothesized a solution, which worked, but requires the use of a less than frequent key on your keyboard, the menu key. Usually this key is two keys to the right of the space bar on windows keyboards, between Alt and Control. A picture of it is on the right.

    Note: As pointed out by Lee, in the comments, you can press Shift + F10 if your keyboard doesn’t contain the Menu Key.

    The Form With a Hidden Label Behind the Filename TextBox) Form with hidden label control

    Properties Window Listing the Hidden Control, HiddenLabel

    Properties window list of controls

    Select the control that you can’t see. It will be highlighted on the form.

    Form with Hidden Control Highlighted

    Label highlighted after selecting from properties windowThe hidden control becomes highlighted. Click into the title bar of the form. Press the menu key on your keyboard to display the context menu.

    Context Menu Being Displayed After Pressing the Menu Key

    bringtofrontSelect “Bring to Front” to display the control. It will now be visible and can be edited or removed.

    Hidden Control Moved

    Label after being brought to front and movedAs you can see, the control that was previously hidden is now visible and has been moved.

    I know this is a basic solution to an easy problem, but I had to figure it out, and I hope that someone searching may find this useful as well. The above example was a new form I was starting; it is not the actual application in question.


  • Using Reflection to Dynamically Generate ToString() Output

    Update: Added code to show “null” when a property is null, like Visual Studio does.

    If you’ve ever used Visual Studio in any iteration in any language, you have most likely used the immediate window. It’s insanely useful and lets you just type an instance of an object and if the object doesn’t have an overridden ToString() method (I’m back in C#/.Net world here for the purposes of this post), Visual Studio will dynamically generate output for you, so that you can see the current state of the object.

    Here is what Visual Studio’s output looks like on an object I have:

    {CompanyName.CreditCard.Processor.CreditDebit.SaleResponse}
        base {CompanyName.CreditCard.Processor.Response}: {CompanyName.CreditCard.Processor.CreditDebit.SaleResponse}
        AddressVerificationSuccess: true
        AuthorizationCode: null
        AuthorizedAmount: 50
        CvvSuccess: false
        ReferenceNumber: null

    However, what if you want to be able to have ToString() generate this type of output for you, for the purposes of debugging, like using with Debug.WriteLine or Trace or any other logging framework? It is useful to be able to see later what the state of an object was during a problem situation. Sure, you can write your own ToString() code in every object to generate its state in string form, and then aggregate all the base objects using base.ToString(), but that is a lot of iterative, repetitious coding.

    My classes are simple data transfer objects and look like this:

    public class SaleResponse : Response
    {
        public virtual bool AddressVerificationSuccess { get; set; }
        public virtual bool CvvSuccess { get; set; }
        public virtual string AuthorizationCode { get; set; }
        public virtual string ReferenceNumber { get; set; }
        public virtual decimal? AuthorizedAmount { get; set; }
    }
    
    public class Response
    {
        public virtual bool Success { get; set; }
        public virtual string ResponseMessage { get; set; }
        public virtual string TransactionID { get; set; }
        public virtual string GatewayResponseCodeText { get; set; }
        public virtual string IssuerResponseCodeText { get; set; }
        public virtual GatewayResponseCode GatewayResponseCode { get; set; }
        public virtual IssuerResponseCode IssuerResponseCode { get; set; }
    }

    As you can see, Visual Studio didn’t even give me the contents of the base class, but I want this information. My ToString() method I’ve created in the SaleResponse object is the following:

    public override string ToString()
    {
        var flags = System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.FlattenHierarchy;
        System.Reflection.PropertyInfo[] infos = this.GetType().GetProperties(flags);
    
        StringBuilder sb = new StringBuilder();
    
        string typeName = this.GetType().Name;
        sb.AppendLine(typeName);
        sb.AppendLine(string.Empty.PadRight(typeName.Length + 5, '='));
    
        foreach (var info in infos)
        {
            object value = info.GetValue(this, null);
            sb.AppendFormat("{0}: {1}{2}", info.Name, value != null ? value : "null", Environment.NewLine);
        }
    
        return sb.ToString();
    }

    Which generates the following output:

    SaleResponse
    =================
    AddressVerificationSuccess: True
    CvvSuccess: False
    AuthorizationCode: null
    ReferenceNumber: null
    AuthorizedAmount: 50
    Success: True
    ResponseMessage: null
    TransactionID: AXB234234
    GatewayResponseCodeText: null
    IssuerResponseCodeText: null
    GatewayResponseCode: ExpiredDevice
    IssuerResponseCode: Error

    What I like about this approach is that it grabs all the base object’s properties recursively. Obviously, there are performance concerns with doing reflection, so I wouldn’t use this constantly, but I think it’s a good way to write out the state of an object in the event of an error. Also, I made the example simple for this blog post, but obviously, you could put that code into an extension method for System.Object or just into a static utility class, adding an object parameter and replacing “this” with the name of the object parameter.


  • Strong Name an Assembly Without Source Code

    Because I program in the 1970’s, part of what I do is programming against modems and serial ports. Specifically, we send medical claims over modem to adjudicators, in the event of unavailable internet access. As a customer, you’ll appreciate having your pharmacy delay you for 20 seconds rather than saying “Sorry; you can’t have your medicine.”

    While taking a break from disco dancing, I was trying to add a strong name to one of our projects. One of the requirements, however, for strong naming is that all of the assemblies you reference must be strong named as well. All are, except one: COMM-DRV/Lib.Net. We use this assembly to talk to the modems, because it abstracts a lot of the serial communications and allows us to program against a logical “modem”.

    I called the vendor, Willies Computer Software Company, and he said that we’d have to have the source license to strong name, but I asked why they don’t strong name their own binary distribution. He just kept saying they don’t do that, and we’d have to buy the source license. We didn’t need to make changes to their code, though; in fact, I already did that by inheriting their class and hiding some methods with new ones.

    So, I set about trying to find out how to strong name an assembly for which you do not have the source. The short answer is “you can’t.” The longer answer is “You can’t, unless you disassemble it, reassemble it, while signing at the same time, and only if it’s not obfuscated.” I finally found the answer I was looking for at geekzilla.

    Here are the steps you need (back up your old assembly):

    Create a Key Pair

    This is only necessary, of course, if you don’t already have one generated for yourself or your company.

    sn.exe -k C:\Path\To\KeyPair.snk

    Disassemble the Assembly into IL

    ildasm.exe CdrvLibNet.dll /out:CdrvLibNet.il

    Reassemble the Assembly from IL While Signing

    ilasm.exe CdrvLibNet.il /dll /output=CdrvLibNet-StrongNamed.dll /key=C:\Path\To\KeyPair.snk

    The Result

    Thankfully, everything worked great, because their assembly was not obfuscated (it’s basically a .Net wrapper around their C++ unmanaged, native DLL product, so no real intellectual property to steal here). Now, we have their product strong named with our public key, and we are able to build on top of it with a strong named product of our own.


  • How Insensitive

    Update: Added section at the bottom detailing what not to do.

    As part of the updater process that I wrote for a current project, a “boot strapper” program queries the database for available versions, and if there is a newer version available, it deletes the current program folder, replaces those files with the new files, and then executes the main program executable. If there are no newer versions, it simply executes the main program executable immediately. This gives the user they are executing the program itself, instead of the “invisible” boot strapper, but we are able to easily manage updates in this manner.

    Obviously, if you are a .Net developer, you know about the venerable app.config, which is used to set program parameters at run-time, rather than at design time. Because these can contain changes to our connection strings and custom configuration sections, we wanted to preserve this and other special files that may be used in the future. As our solution, we created a whitelist of files that we do want to replace, that looked like this:

            ///
            /// Extensions of files that may be deleted during uninstall/reinstall.
            ///
            private List _deletableExtensions = new List(
                new string[] { ".exe", ".dll", ".pdb", ".chm", ".manifest" });
    
            private bool canDeleteOrOverwrite(FileInfo file)
            {
                // Only delete files with specific extensions.
                bool canDelete = _deletableExtensions.Contains(file.Extension);
    
                return canDelete;
            }

    Before anybody murders me, we camel case private methods and underscore prefix and camel case private class-level variables here. As you can see, this will allow deletion of executables, class libraries, debug symbols, help files, and manifests. However, we had a problem in my code that didn’t surface until yesterday. We were trying to figure out why one file out of all the files in the directory was remaining an older version, “ActiveReports3.DLL”.

    What may be obvious to the reader, especially considering the title of this post, is that my List<T>.Contains() check, by default, is case sensitive, and “.DLL” != “.dll”. This required quite a bit of stepping through code to find, as I wrote this code a long time ago. A simple press of “Ctrl+Shift+Space” revealed that there was an overload of IEnumerable<T>.Contains(T item, IEqualityComparer<T> comparer).

    Because I’ve had to do this in the past, I knew that, because my T in this case was string, all I needed to do was use the StringComparer, which implements the IEqualityComparer<string> interface. Because it is filenames, and we are working with Visual Studio generated files, we care neither about culture nor case in this instance. Here is the revised, working version:

            ///
            /// Extensions of files that may be deleted during uninstall/reinstall.
            ///
            private List _deletableExtensions = new List(
                new string[] { ".exe", ".dll", ".pdb", ".chm", ".manifest" });
    
            private bool canDeleteOrOverwrite(FileInfo file)
            {
                // Only delete files with specific extensions.
                bool canDelete = _deletableExtensions.Contains(
                    file.Extension,
                    StringComparer.InvariantCultureIgnoreCase);
    
                return canDelete;
            }

    That’s it! That tiny change fixed our issue and allowed the boot strapper to overwrite that file. It’s amazing that a simple little omission like that can lead to such a strange problem manifesting itself. Everybody makes mistakes; I just thought I’d showcase one of my errors and how I fixed it.

    After talking to one of my coworkers about this post, he mentioned something that we have both seen done to “work around” this particular problem, which should not be done. This is what I have seen before in others’ code:

            ///
            /// Extensions of files that may be deleted during uninstall/reinstall.
            ///
            private List _deletableExtensions = new List(
                new string[] { ".exe", ".dll", ".pdb", ".chm", ".manifest" });
    
            private bool canDeleteOrOverwrite(FileInfo file)
            {
                bool canDelete = false;
    
                // Only delete files with specific extensions.
                foreach (string currentExtension in _deletableExtensions)
                {
                    if (currentExtesion.ToLower() == file.Extension.ToLower())
                    {
                        canDelete = true;
                        break;
                    }
                }
    
                return canDelete;
            }

    This creates a LOT of strings on the heap in the process is and is very inefficient. It’s much better to let .Net handle itself and just let it know whether you care about culture and/or case sensitivity.


  • A Day Late and a Property Declaration Short

    I know this is a bit late to the game, but this morning, as I’m refactoring a bunch of old code to be shared with a new project, I’m cleaning up the C# 2.0 property declarations we all know and love:

        public class SaleResponse : Response
        {
            protected bool _addressVerificationSuccess;
            public virtual bool AddressVerificationSuccess
            {
                [DebuggerStepThrough]
                get { return _addressVerificationSuccess; }
                [DebuggerStepThrough]
                set { _addressVerificationSuccess = value; }
            }
    
            protected bool _cvvVerificationSuccess;
            public virtual bool CvvSuccess
            {
                [DebuggerStepThrough]
                get { return _cvvVerificationSuccess; }
                [DebuggerStepThrough]
                set { _cvvVerificationSuccess = value; }
            }
    
            protected string _authorizationCode = string.Empty;
            public virtual string AuthorizationCode
            {
                [DebuggerStepThrough]
                get { return _authorizationCode; }
                [DebuggerStepThrough]
                set { _authorizationCode = value; }
            }
    
            protected string _referenceNumber = string.Empty;
            public virtual string ReferenceNumber
            {
                [DebuggerStepThrough]
                get { return _referenceNumber; }
                [DebuggerStepThrough]
                set { _referenceNumber = value; }
            }
    
            protected decimal? _authorizedAmount;
            public virtual decimal? AuthorizedAmount
            {
                [DebuggerStepThrough]
                get { return this._authorizedAmount; }
                [DebuggerStepThrough]
                set { this._authorizedAmount = value; }
            }
        }

    This code is, of course because I wrote it, wonderful and has no flaws, and I used the prop snippet to create the private variable and public property getter and setter. However, I have all those DebuggerStepThrough attributes in there, due to the lovely fun of stepping through code that references properties. That avoids stepping in and out of the property declarations.

    Thank the flying spaghetti monster that now, in C# 3.0 (and of course 3.5, 4.0 and on), Microsoft has given us auto-implemented properties. This is now the equivalent code, avoiding the stepping in/out of the get/set and not requiring the declaration of a private variable:

        public class SaleResponse : Response
        {
            public virtual bool AddressVerificationSuccess { get; set; }
            public virtual bool CvvSuccess { get; set; }
            public virtual string AuthorizationCode { get; set; }
            public virtual string ReferenceNumber { get; set; }
            public virtual decimal? AuthorizedAmount { get; set; }
        }

    When I first learned this trick, I was extremely thankful to be able to do this as an even shorter shortcut to using the prop snippet and it makes the code a lot prettier. What I didn’t immediately realize is how to control scoping. Let’s say, for instance, I want that AuthorizationCode property to only be able to be set from inside the class itself, and I only want the AuthorizedAmount property to be able to get set from inside the class and inherited classes. I can then change those declarations like this:

        public class SaleResponse : Response
        {
            public virtual bool AddressVerificationSuccess { get; set; }
            public virtual bool CvvSuccess { get; set; }
            // This can now only be set from inside the class
            public virtual string AuthorizationCode { get; private set; }
            public virtual string ReferenceNumber { get; set; }
            // This can now only be set from inside the class and those that inherit from it
            public virtual decimal? AuthorizedAmount { get; protected set; }
        }

    This allows you to control the scoping of the getter and setter independently. By default, they inherit the visibility of the property declaration, in this case, public for all. I’m always thankful for the tools Microsoft gives me to make my life easier and to give me more time to spend on the actual work, rather than installing plumbing.


  • It’s Really Hot… Inside

    Yesterday, it got up to 93 degrees (Fahrenheit) in our office and I actually started sweating. Now I know how Joan of Arc felt when she was being burned alive at the stake. The air conditioner went out Tuesday (6/30/2009) and they just got the part(s) in today (7/2/2009) to fix it. What follows is what I like to believe is at least a good a version as Boston Globe’s Big Picture of our harrowing experience.

    89 at One End of the Hall

    92 at the Other End of the Hall

    It's really hot

    All Kinds of Fans at the Other End of the Hall

    Dave's Fan

    The "King of Fans" (brand name)

    Now I’ve gotten my pictures out to the world at large. It is similar to what the Iranians are having to do since the election. Thanks Pete Hoekstra!