Just imagine that your Daddy is the smartest man who ever lived on Earth, and he knows everything there is to find out, and he is exactly right about everything, and he can prove he is right about everything. Now imagine another little child on some nice world a million light-years away, and that little child’s Daddy is the smartest man who ever lived on that nice world so far away. And he is just as smart and just as right as your Daddy. Both Daddies are smart, and both Daddies are right.
Only if they ever met each other they would get into a terrible argument, because they wouldn’t agree on anything. Now, you can say that your Daddy is right and the other little child’s Daddy is wrong, but the Universe is an awfully big place. There is room enough for an awful lot of people to be right about things and still not agree.
The reason both Daddies can be right and still get into terrible fights is because there are so many different ways of being right. There are places in the Universe, though, where each Daddy could finally catch on to what the other Daddy was talking about. These places are where all the different kinds of truths fit together as nicely as the parts in your Daddy’s solar watch. We call these places chrono-synclastic infundibula.
Chrono (KROH-no) means time. Synclastic (sin-CLASS-tick) means curved toward the same side in all directions, like the skin of an orange.
Infundibulum (in-fun-DIB-u-lum) is what the ancient Romans like Julius Caesar and Nero called a funnel. If you don’t know what a funnel is, get Mommy to show you one.
- Kurt Vonnegut Jr.From The Sirens of Titan, ©1988
My mother-in-law was fiercely opposed to her daughter moving into my apartment. That’s an understatement. We sort of cared but really wanted to live together… in the same apartment.
Ok, enough with the segue! I have a WCF/WPF application that is MTA and I needed to access the print functionality down inside WPF. Well, those controls are really picky and will yell at you and simply refuse to work if you don’t instantiate and call them from an STA thread.
No problem right?! Well, that’s what I thought. I mean, all I really need to do is to create a new thread and specify the apartment before it starts and then make the necessary calls. Sounds simple enough. Let’s take a stab at that…
[STAThread]
public string PrintSpecificLabelStock_STA
(
LabelRequestPrintMetadata labelRequestPrintMetadata_
)
{
Exception error = null;
var thread = new Thread(
delegate()
{
try
{
var labelRequestList =
session.Execute<SpecificLabelStockQuery, List<LabelRequest>>
(labelRequestPrintMetadata_, session);
PrintLabelRequests(labelRequestList.ToArray());
}
catch (Exception ex_)
{
error = ex_;
}
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
thread.Join();
return error == null ? string.Empty : error.Message;
}
Well, that doesn’t work. The application locks up when the thread starts… or more specifically, when the call to Join is made. Evidently, the unholy joining of two separate apartments is also disavowed by more than just mother-in-laws-to-be! The workaround/fix is below:
[STAThread]
public string PrintSpecificLabelStock_STA
(
LabelRequestPrintMetadata labelRequestPrintMetadata_
)
{
Exception error = null;
var resetEvent = new ManualResetEvent(false);
var thread = new Thread(
delegate()
{
try
{
var labelRequestList =
session.Execute<SpecificLabelStockQuery, List<LabelRequest>>
(labelRequestPrintMetadata_, session);
PrintLabelRequests(labelRequestList.ToArray());
}
catch (Exception ex_)
{
error = ex_;
}
finally
{
resetEvent.Set();
}
});
thread.SetApartmentState(ApartmentState.STA);
thread.Start();
resetEvent.WaitOne();
return error == null ? string.Empty : error.Message;
}
Enjoy!
Tags: MTA, STA
So the interview question goes, “Does C# support multiple inheritance?” Before C# 3.0, the answer was to not answer that with a yes/no. The best answer would have been, “C# supports the ability to implement multiple interfaces but can only inherit from one concrete class.”
Take this code snippet:
public interface IContractOne
{
}
public class ContractImplementer : IContractOne
{
}
ContractImplementer “implements” the IContractOne interface… even though it does not define much of a “contract” signature.
Now, using the new C# 3.0 “Extension Method” feature, we can extend the IContractOne interface. That’s right… we can actually add “implementation” to an interface… sort of.
static public ExtendsIContractOne
{
static public void Foo (this IContractOne)
{
Console.WriteLine("Welcome to pseudo multiple inheritance! (sort of)");
}
}
Now if you had a console application main method coded like this:
static public void main ()
{
ContractImplementer contractImplementer = new ContractImplementer();
// Now call through the IContractOne interface to the Foo method…
contractImplementer.Foo();
}
Practical purposes? You’ll know when you get there.
For now, this is a cool/neat language feature.
Tags: Extension Methods
The best way, in my opinion, to understand the true meaning of the effects of using the “new” modifier in a virtual hierarchy is to think of it like this… The runtime wants to start at the top of the virtual hierarchy and work towards the bottom (towards the most derived class in the chain)… it says, “Is there an override in the derived class directly below me?” If so, it goes down one level… and then repeats the same question.
If the class directly below the current one has applied the “new” modifier to that virtual chain, that method is “hidden”… so the chain stops at the last method that did not have the “new” modifier applied to it. This happens because the “new” modifier (when applied to a virtual chain) actually creates a brand new v-table entry… thus physically breaking the chain in the hierarchy.
Take this example:
class A
{
public virtual void CallMethod() { Method(); }
protected virtual void Method() { Console.WriteLine("A"); }
}
class B : A
{
protected override void Method() { Console.WriteLine("B"); }
}
class C : B
{
protected new virtual void Method() { Console.WriteLine("C"); }
}
class D : C
{
protected override void Method() { Console.WriteLine("D"); }
}
class Program
{
static void Main(string[] args)
{
C objeckt = new D();
objeckt.CallMethod();
}
}
What is printed? The answer is “B”. Why?
It prints “B” because we start out by creating an actual instance of D that is “pointed to” or referenced using a C. The CallMethod method is actually on class A so we just go up to A and then it tries to call “Method” from the top… down. A is virtual… but is overridden by B. It jumps down to B and since C’s Method has the “new” modifier applied to it… it cannot “see” the Method instance on class C… thus it stops at B and calls that method.
Cool huh!
Enjoy!
Tags: inheritance, virtual
