推薦：淺析C# 2010命名和可選參數(shù)的新特性
1.命名參數(shù)允許調(diào)用者通過提供參數(shù)的名稱來為其賦值，這樣參數(shù)的位置就不在重要了�？蛇x參數(shù)允許在定義時為某些參數(shù)賦值，在調(diào)用時可以忽略這些

Lambda表達(dá)比代表定義和帶外方法定義的結(jié)合更清楚，且相關(guān)的額外工作只需要滿足語言定義即可。不過，它也有一些不足之處。如果某個方法的參數(shù)包含System.Delegate 這樣的抽象類型，用lambda表達(dá)式介紹特殊的問題：C#編譯器不能將lambda表達(dá)式轉(zhuǎn)換成還未明確定義的衍生代表類型。

如果不仔細(xì)思考一下，你的代碼看上去就會像是來自.NET1.0的東西。在本文中，我將告訴告訴你為什么lambda表達(dá)式不足以被直接轉(zhuǎn)換成抽象代表類型，并且教你怎樣使得編譯器轉(zhuǎn)換你所定義的指定代表。解決方案依賴于Windows Presentation Foundation(WPF)和System.Windows.Threading.Dispatcher組件，但是嚴(yán)格意義上說，該問題不是一個WPF問題。文中所描述的問題出現(xiàn)在若干.NET框架中，包括Windows Forms，Office 應(yīng)用程序接口和映射應(yīng)用程序接口。你可以按照下列方法來處理同類問題。

無論我什么時候使用.NET框架中帶有來自代表表格的參數(shù)的應(yīng)用程序接口，我都會傾向于使用lambda表達(dá)式而不是更詳細(xì)的表達(dá)式。例如，這行代碼創(chuàng)建了一個System.Windows.Threading.Timer，在計時器失效時，該代碼調(diào)用了一個TickHandler方法：

tick = new System.Threading.Timer((unused) =>

TickHandler());

如果方法的內(nèi)容足夠少，我就會用方法的內(nèi)容替代TickHandler()方法調(diào)用。該方法大多數(shù)情況下都有效，但是當(dāng)應(yīng)用程序接口將System.Delegate作為參數(shù)時，這一技巧不管用。例如，我們將System.Windows.Controls.Dispatcher.Invoke()方法穿過WPF中的線程實施調(diào)用：

public object Invoke(

delegate method,

params object[] args)

現(xiàn)在考慮一下當(dāng)我們嘗試用lambda表達(dá)式來執(zhí)行這樣的調(diào)用時，將會發(fā)生什么：

MyTime.Dispatcher.Invoke(() => DoSomething());

會出現(xiàn)隱秘錯誤：

error CS1660: Cannot convert lambda expression to

type 'System.Delegate' because it is not a delegate type

或許第一次看到這個錯誤的時候，你還不知道到底是怎么一回事。當(dāng)然，這的確是一個代表類型。編譯器不像人一樣的靈活。System.Delegate類型是一個抽象類型，且該類型的推理工具不能推斷出自變量或某些用于未知代表類型的返回值的數(shù)量和種類。要解決這一問題，我們必須創(chuàng)建一個具體的代表類型并為該類型指定lambda表達(dá)式。記住，代表類型要求你將方法視為數(shù)據(jù)。

我創(chuàng)建了一個WPF計時器程序來展示其工作原理，其中闡述了C#3.0 怎樣簡化與老式應(yīng)用程序接口(下圖)的運行。

當(dāng)你做演示的時候，該示例中的應(yīng)用程序運行了一個計時器，隨著設(shè)定時間流逝，它的顏色會從綠色轉(zhuǎn)為黃色再轉(zhuǎn)為紅色。這是一個很好的演示跨線程調(diào)用的方法，因為該計時器在背景線程中運行。

按照時間的改變來更新演示要求對出自計時器的事件作出響應(yīng)。計時器在背景線程中運行，所以你會很輕易地犯我們在前面提到過的錯誤。

更新應(yīng)用程序

用戶界面處理的是簡單代碼。當(dāng)計時器失效時它會生效，而且代碼會更新計時器的顯示。這一更新必須改變文本，或控制背景。如下所示：

MyTime.Background = newBrush;

MyTime.Content = label

計時器在背景線程上運行，所以你需要通過使用Dispatcher.Invoke()邊界線執(zhí)行調(diào)用。這兩行代碼是你想列入lambda表達(dá)式的代碼，不是證明方法定義的邏輯理由。但是我之前就講過lambda不會與Didpatcher.Invoke一起運行，除非是你使用了具體的代表定義才行。這之中的一部分已經(jīng)在.NET框架3.5中定義了。

我們可以使用嵌入式代表定義并對它們進(jìn)行分配，這些都是的該解決方案比起先前提到過的案例都要省事一些。這兩行代碼也要求一對參數(shù)：一個用于文本的字符串和用于背景顏色的顏色刷。這意味著你需要使用的代表定義要考慮到這兩個參數(shù)并返回?zé)o效值：

Action updateTimer;

在聲明變量后，你可以為代碼指定需要執(zhí)行的代表變量。這里你可以使用lambda表達(dá)式，因為Action是一個具體的代表定義：

updateTimer = (label, newBrush) =>

{

MyTime.Background = newBrush;

MyTime.Content = label;

};

現(xiàn)在，當(dāng)計時器提出事件時，你已經(jīng)擁有了一些需要執(zhí)行的指向該代碼的變量。接下來要做的就只是通過Dispatcher.Invoke()使用代表定義：

if (!MyTime.Dispatcher.CheckAccess())

{

MyTime.Dispatcher.Invoke(updateTimer,

newLabel, next);

}

else

updateTimer(newLabel, next);

這一過程十分簡單，但是卻要求你反復(fù)進(jìn)行，因此，我們可以讓步驟變得容易一點。

這里其實由一個簡單的模式。事件處理器可以從背景線程中調(diào)用出來。當(dāng)我們使用計時器，或者異步調(diào)用Web服務(wù)以及其他類似任務(wù)的時候，你就會看到這一行為。無論是在什么時候，我們都不清楚自己位于哪個線程之上，我們可以調(diào)用Dispatcher.CheckAccess()來決定是否可以訪問任意用戶界面控件。如果需要從線程邊界執(zhí)行調(diào)用，就必須使用Dispatcher.Invoke()。Dispatcher.Invoke()方法避免了由于使用了方法參數(shù)的參數(shù)數(shù)組而造成的若干超載問題。它使用的是一個我們想要執(zhí)行的抽象代表類型。

你想要一個能檢查是否需要整理編排的單一方法。如果需要，則方法會編排好調(diào)用，否則，會調(diào)用由代表指定的方法。你虛偽方法作為System.Windows.Controls.Control 類型的成員出現(xiàn)。這樣使得你可以將代碼作為控件的一部分來使用。C#3.0就為你提供了這樣做的方法：擴(kuò)展方法。你需要編寫一些方法的不同超載，這些使得你可以通過不同的參數(shù)來使用它們：

public static class WPFExtensions:

{

public static voidInvokeIfNeeded(

this Control widget,

Action whatToDo)

{

if (!widget.Dispatcher.

CheckAccess())

widget.Dispatcher.Invoke(whatToDo);

else

whatToDo();

}

public static void

InvokeIfNeeded(

this Controlwidget, Action

whatToDo, T parm)

{

if (!widget.Dispatcher.CheckAccess())

widget.Dispatcher.Invoke(whatToDo, parm);

else

whatToDo(parm);

}

public static void

InvokeIfNeeded(this

Controlwidget, Action

whatToDo,

T1 parm1, T2 parm2)

{

if (!widget.Dispatcher.

CheckAccess())

widget.Dispatcher.

Invoke(whatToDo,

parm1, parm2);

else

whatToDo(parm1, parm2);

}

}

當(dāng)然，我們也可以通過添加更多參數(shù)的方式來添加更多超載以擴(kuò)展這個類。這其實是一個簡單的擴(kuò)展。

有一種方法讓W(xué)PF設(shè)計師們瘋狂：他們希望用最小化應(yīng)用程序接口的面積部分來簡化Dispatcher對象的使用。通過使用抽象代表和參數(shù)列表中的參數(shù)，這一對象的使用范圍被擴(kuò)大了。

任何帶有參數(shù)的方法都可以被拿來使用。但是，這樣做有一個不足之處。該應(yīng)用程序接口更為抽象，它會破壞所有類型的安全性，而且這樣做會損壞編譯器使用類型推理的能力，從而降低工作效率。需要做的應(yīng)該是添加自己的安全擴(kuò)展方法的層類型，這一層類型可以在類型安全調(diào)用和更為抽象的.NET庫應(yīng)用程序接口之間提供一個層。

分享：淺析WinForm程序中使用控制臺作為輸出窗口
最初打算寫一個log窗口類，使用textbox控件以及 progressbar，后來發(fā)現(xiàn)挺麻煩，遠(yuǎn)不及console窗口下的console.write和console.writeline方便。于是嘗試直接將信息輸出到控制臺窗口。 1、 在winform程序中調(diào)用console窗口。這個使用Win32 API來完成。關(guān)于Allo