Canon Pixma MX700 printer dead and resurrected (Not!)

My Canon Pixma MX700 printer died the other day as it was printing. It just went completely dead, as if the power cord was unplugged. Today I decided to troubleshoot it. First, I tried a different power outlet. That was not it. Then, I checked the power cord. No problem there. Then, I took out the power supply box and disconnected it from the printer, then I reconnected it and put it back in. No improvement. Then I opened up the power supply box and examined the circuit board in it.

Canon Pixma MX700

I am not terribly familiar with hardware, so I could not tell if the smell was of burned electronic components or if it was just the regular smell of electronics that have been sitting inside a closed box for a few years. Nothing looked burned though, and all the electrolytic capacitors seemed intact. I located 3 fuses on the board, and I checked each one of them for continuity. They were all fine.

So, I decided to give up, and I started putting things back together. I placed the circuit board back in the power supply box, I closed the box, and then for some reason I did something backwards: first I connected the power chord to the power supply box, and then I connected the power supply box to the printer.  As I was attaching the connector, I noticed that one of the pins was momentarily making a little spark. And then lo and behold, the printer came back to life! The printer had fixed itself!

And that, ladies and gentlemen, is why I hate hardware.

UPDATE 2012/07/13: nope, the resurrection was only temporary. The printer is dead. Dead as a doornail. And that, ladies and gentlemen, is why I hate hardware even more.

Solved: Local resources unavailable on remote desktop

I experienced this problem today, drive C: of my local computer "Pegasus" was not appearing on the remote computer as "C on PEGASUS" when I connected to the remote computer via Remote Desktop (Terminal Services.)  All other drives of Pegasus were showing fine on the remote computer, but the one I actually needed (C:) was not.  The drive did not even appear under "\\tsclient" in "Network Places".

Judging by the problems reported by people from all over the world who have this problem and are searching for solutions on the interwebz, it may happen with any local resource, like printers, the clipboard, etc.

Luckily, I found a solution to the problem:

Terminate the RDP session not by closing the RDP window, but by actually logging off. Then, start a new RDP session, and the problem will have most likely gone away.

It is unclear why local resources sometimes fail to show on the remote computer during an RDP session; it is one of those things that "just happen", and that tend to go away if you just "close and reopen it". (Or get out of the car and get back in again, as the joke goes.) The reason for the frustration with this particular problem is that more often than not we do not really "close and reopen it", because we tend to just close the RDP window, which does not terminate our logon session with the server. By logging off and connecting again, the logon session gets restarted, and that's the "close and reopen" needed to fix the problem.

.Net code running faster under the profiler?

So, today it occurred to me that the C# application that I am developing is a bit too slow on startup, and I decided to throw the visual studio profiler at it to see if I have goofed up somewhere. To my astonishment, under the profiler my app ran 10 times faster. The slowness I wanted to troubleshoot was nowhere to be found.

I also tried running the release version, and as I expected it performed better than the debug version under the profiler, so the universe was still in its place, but still, I would very much like to know what the profiler did that made the debug version of my app run so much faster. For one thing, it would be a great convenience to be able to enjoy this speedup while developing; waiting for 2 instead of 20 seconds for my app to start every time I want to check something would be very good for productivity.

I tried my luck with various google searches, and I found a couple of articles on StackOverflow, but none pointed at the exact cause of the problem.

Luckily, after quite a bit of hard thinking, troubleshooting, and browsing through the myriad of potentially relevant settings in Visual Studio, I found the answer: 

It is the "Enable unmanaged code debugging" feature.

In Visual Studio this feature is not under "Tools / Options / Debugging", (because that would make too much sense,) it is under "Project / Properties / Debug".  Enabling that feature makes everything slow as molasses. The profiler disables the debugger, and that feature with it, so the application appears to run lightning fast.

Here is a StackOverflow question to which I added my newly acquired wisdom:

stackoverflow.com: Launching VS Profiler boosts Application Performance x20?

The "Handoff" Pattern

I had been thinking about posting this for quite some time now, and all by coincidence I happened to get a chance to mention it just the other day in an answer that I wrote to a question on Programmers-StackExchange. So, here it is in a more formal way:

If class M stores or manipulates or in any other way works with instances of destructible (disposable) class D, it may not assume the responsibility to destruct these instances, unless it is explicitly told that ownership of these instances is transferred to it. Therefore, class M must accept a boolean called 'handoff' as a construction-time parameter, stating whether instances of D are being handed off to it, and it can therefore destruct them when it is done with them.

Example:

    //Note: the IReader interface extends IDisposable
    IReader reader = new BinaryStreamReader( ... );
    reader = new BufferedStreamReader( reader, handoff:true );
    try
    {
        /* use the reader interface */
    }
    finally
    {
        reader.Dispose(); //this destructs the buffered stream reader, and 
                          //destruction cascades to the binary stream
                          //reader because handoff was specified.
    }

Example:

    var collection = new CollectionOfDestructibles( handoff:true );
    collection.Add( new Destructible( 1 ) );
    collection.Add( new Destructible( 2 ) );
    collection.Add( new Destructible( 3 ) );
    collection.Dispose(); //this destructs the collection and every single
                          //one of its contents, since handoff was specified.

In languages which support optional parameters, the 'handoff' parameter should default to false.

C# Blooper №3: No warnings about fields having already been initialized.

Before reading any further, please read the disclaimer.

When you declare a member variable and you pre-initialize it at the same time, and then you try to re-initialize it within the constructor without ever making use of its original pre-initialized value, you receive no warning about the field having already been initialized.

namespace Test3 
{  
    public class Test 
    {  
        public readonly string m = "m"; 
        public string n = "n"; 
        private string o = "o"; 
        protected readonly string p = "p"; 
        protected string q = "p"; 
        private string r = "r"; 

        Test() 
        {  
            m = "m2"; //Blooper: no warning about field having already been initialized. 
            n = "n2"; //Blooper: no warning about field having already been initialized. 
            o = "o2"; //Blooper: no warning about field having already been initialized. 
            p = "p2"; //Blooper: no warning about field having already been initialized. 
            q = "q2"; //Blooper: no warning about field having already been initialized. 
            r = "r2"; //Blooper: no warning about field having already been initialized. 
            o.ToLower(); //to prevent Warning CS0414: The field is assigned but its value is never used. 
            r.ToLower(); //to prevent Warning CS0414: The field is assigned but its value is never used. 
        }  
    } 
}  

This means that you may accidentally invoke complex initialization logic twice, unnecessarily wasting memory and clock cycles, and it may also lead to logic errors, if by any chance that initialization logic has side effects which are only meant to occur once. It may also confuse someone reading your code, (or even yourself looking at your code months later,) trying to figure out what's the purpose behind the seemingly repeated initialization, before the realization sinks in that it is simply redundant. Furthermore, if the re-initialization happens to differ from the pre-initialization, a good question arises, asking which one of the two was meant to be the correct one.

It is a pity, because the compiler could warn the programmer against this pitfall.

Also see related post: C# Blooper №2: No warnings about accessing uninitialized members.

-

C# Blooper №2: No warnings about accessing uninitialized members.

Before reading any further, please read the disclaimer.

When you declare a member variable, and then you try to read it from within the constructor without having first initialized it, you receive no warning about accessing an uninitialized member. This happens even if the member is declared as readonly.

namespace Test2  
{  
    public class Test 
    {  
        public readonly string m; 
        public string n; 
        protected readonly string o; 
        protected string p; 
        private readonly string q; 
        private string r; 

        Test() 
        {  
            m.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            n.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            o.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            p.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            q.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            r.ToUpper(); //Blooper: no warning about accessing uninitialized member. 
            q = "q"; //to prevent Warning CS0649: Field is never assigned to, and will always have its default value null 
            r = "r"; //to prevent Warning CS0649: Field is never assigned to, and will always have its default value null 
        }  
    } 
}  

Someone might argue that this is behavior is fine because the member in question is guaranteed to contain its default value. First of all, a readonly member containing its default value is completely useless. (See C# Blooper №1: No warnings about uninitialized readonly members when the class is public and the member is public, protected or protected internal.) Secondly, if the compiler is to help the developer catch potential errors and write better code, this is not a valid excuse: a different strategy is necessary.

If the programmer intends the member to contain its default value, then the programmer ought to explicitly state so. Failing to do so ought to imply intention to initialize the member later on, and certainly before any attempt is made to read the member.  This way, the programmer can have it both ways: they can have members pre-initialized to their default values, and they can receive warnings when they fail to initialize members.

Also please note that the compiler is capable of detecting that the value with which a member is being explicitly initialized is the default value for the type of the member, and so it can refrain from emitting any additional code for the assignment; thus, there is no performance issue.

Also see related post: C# Blooper №3: No warnings about fields having already been initialized.

-

Pernicious Local Variable Initialization

Introduction

Pernicious Local Variable Initialization is the cargo cult programming (W) practice of pre-initializing a local variable with some default value, even though that value will be overwritten further down. Another term I have for it is Shotgun Initialization, because it is applied indiscriminately, and on a "just in case" basis, without a valid intent or purpose. Most importantly, it is usually done without knowledge of the dangers involved in doing so.

C# Blooper №1: No warnings about uninitialized readonly members when the class is public and the member is public, protected or protected internal.

Before reading any further, please read the disclaimer.

The C# compiler is kind enough to give you a "field is never assigned to" warning if you forget to initialize a readonly member which is private or internal, or if the class in which it is being declared is internal. But if the class is public, and the readonly member is public, protected or protected internal, then no warning for you! Why, oh why?

namespace Test1  
{  
    class Test1 
    {  
#if TRY_IT  
        public readonly int m; //OK: warning CS0649: Field is never assigned to, and will always have its default value 0  
        protected readonly int n; //OK: warning CS0649: Field is never assigned to, and will always have its default value 0  
        internal readonly int o; //OK: warning CS0649: Field is never assigned to, and will always have its default value 0  
        private readonly int p; //OK: warning CS0649: Field is never assigned to, and will always have its default value 0  
        protected internal readonly int q; //OK: warning CS0649: Field is never assigned to, and will always have its default value 0  
         
        Test1() 
        { 
            if( p != 0 ) //To avoid warning 'The field is never used' 
                return; 
        } 
#endif 
    }  
  
    public class Test2 
    {  
#if TRY_IT  
        private readonly int m; //OK: warning CS0649: Field is never assigned to, and will always have its default value 0  
        internal readonly int n; //OK: warning CS0649: Field is never assigned to, and will always have its default value 0  
 
        Test2() 
        { 
            if( m != 0 ) //To avoid warning 'The field is never used' 
                return; 
        } 
#endif  
        public readonly int o; //Blooper: no warning about field never assigned to.  
        protected readonly int p; //Blooper: no warning about field never assigned to.  
        protected internal readonly int q; //Blooper: no warning about field never assigned to. 
    }  
  
    public sealed class Test3 
    {  
        public readonly int m; //Blooper: no warning about field never assigned to.  
    }  
}  

For a moment you might think "well, a descendant might initialize that member", but that theory does not hold any water, for a number of reasons:

• Internal classes may also be subclassed, but the compiler does not fail to issue the warning in their case.
• Sealed classes may not be subclassed, but the compiler fails to issue the warning in their case, as Test3 in the sample code demonstrates.
• The warning makes sense for the sake of the integrity of the base class regardless of what a derived class may or may not do.
• Lastly but most importantly, the C# specification expressly prohibits a derived class from initializing a readonly member of a base class. You get Error CS0191: A readonly field cannot be assigned to (except in a constructor or a variable initializer) which, incidentally, is a little bit misleading, because you may be trying to assign the field from within a constructor, only it is the constructor of the wrong class.

According to MSDN Documentation about this warning, the exhibited behavior is to be expected:

Compiler Warning (level 4) CS0649:

Field 'field' is never assigned to, and will always have its default value 'value'

The compiler detected an uninitialized private or internal field declaration that is never assigned a value.

The question is: why?

UPDATE:

I posted this question on StackOverflow, and Eric Lippert himself answered it. The short answer is that it is an oversight of the compiler, but the long answer is also quite interesting and worth reading.
-

C# Bloopers

Please do not get me wrong; C# is awesome. It is the language of my choice, even though I am pretty well versed in C++ and Java. That having been said, it cannot be denied that C# has its share of flaws, too. In this series of posts I am documenting some of them, in no particular order.

Also please note that many of the issues described herein are Visual C# bloopers, not C# bloopers in general.

C# Blooper №1: No warnings about uninitialized readonly members when the class is public and the member is public, protected or protected internal.

C# Blooper №2: No warnings about accessing uninitialized members.

C# Blooper №3: No warnings about fields having already been initialized.

C# Blooper №4: Lame/annoying variable scoping rules, Part 1

C# Blooper №5: Lame/annoying variable scoping rules, Part 2

C# Blooper №6: No warnings about unused parameters.

C# Blooper №7: No warnings about unused private methods.

C# Blooper №8: No warnings for conditions that are always true/false

C# Blooper №9: Annoying case statement fall-through rules.

C# Blooper №10: Switch statements are not properly formatted.

C# Blooper №11: Zero to Enum conversion weirdness

C# Blooper №12: 'Where' constraints not included in method signatures

C# Blooper №13: C# Blooper №13: Stack and Queue do not implement ICollection

C# Blooper №14: Weird / annoying interface method visibility rules.

Stay tuned, there is more to come.
-

Intertwine: Normalizing Interface Invocations

This post has been superseded by a new post in 2022
See michael.gr - Intertwine

This is a C# project that I did back in 2011. It consists of a (rather informal) white paper which describes the project, and a zip file containing the source code in the form of a Microsoft Visual Studio solution.

Here is the abstract:

A mechanism is proposed for converting (entwining) method call invocations of any interface to a general purpose single-method normal form, and converting back (untwining) from the normal form to interface invocations, so that operations can be performed on the normal form in a way agnostic to the interface being invoked. The normal form is a delegate in C# or a functional interface in Java, realized as object AnyCall( int selector, object[] parameters ). A DotNet implementation is provided in C#, though the discussion also applies to Java.

And here is the table of contents:

• Abstract (page 1)
• The Problem (page 1)
•  Why messages are bad (page 2)
•  What is missing (page 2)
• The Solution (page 2)
• A hand-crafted solution (page 3)
• Automating with Intertwine (page 6)
• Appendix 1: A note about Dynamic Proxies (page 6)
• Appendix 2: An example: Interface multicasts (events) (page 7)
• Appendix 3: Things to fix (page 8)

Download the white paper: Intertwine v2.1.pdf
Download the source code: Intertwine v2.0.zip