事隔幾篇，我們又回到事件區，繼續其它兩個按鈕事件，來張圖吧：
在這篇之前，基本上雙方已可以對戰了,看似主體功能已完成。隻是，大夥都知道，細節的東西，才是花時間的，漫長的路還在後面.......
如标題所示，這節實作“求和+認輸”兩個事件。
每次開始，我們都習慣的先寫wcf服務端代碼，再回到用戶端寫代碼：
對應着“開始的”startgame,這節我們也要開始我們的endgame了。
回到iservice.cs,添加接口：
/// <summary>
///遊戲結束
/// </summary>
[operationcontract(isoneway = true)]
void endgame(player player);
接着是icallback.cs，回調接口：
[operationcontract(isoneway = true)]
void notifyendgame(player player);
緊跟着是實作endgame接口，和startgame一樣，隻需一行代碼：
public void endgame(player player)
{
notify.game(player, gametype.end);
}
接着我們實作notify.game裡預留的switch語句：
notify.game
就一個循環，正常是人手一份通知,不過請求平手，對手一份就夠了[多了一個21,20，是對方回應辨別,下面有說到]。
到此服務端輕松已完成了!!
ok，接着我們回到用戶端，對應相應的按鈕事件：
喂喂，編繹，更新服務引用哦[我又忘了-_-...]。
一：求和[我查了下e文（平手）叫：deuce]
我們輕按兩下求和按鈕，這是我們最本能的反應了，前背景産生了click事件代碼：
我們往背景輕松敲兩行代碼,為什麼app.player後面還有一個"22"的參數？？？有什麼用呢？等會就知!：
//平手事件,我們定義22
private void btngamedeuce_click(object sender, routedeventargs e)
app.player.attachinfo = "22";
app.client.endgameasync(app.player, "22");
ok,發送完指令就等對方回應了：
這裡有一點，我們點選完發送後，要不要提示使用者“你的請求已發送，請等待回應”這樣的提示語呢？
如果不用，就不用加那個完成事件了，如果要，我們就加一下了，如下
為了不産生多個事件，我們都把事件移到構造函數裡：
代碼
看到事件結束後我們的判斷了，那個上面傳的參數"22"這裡我們就用到了。由于可以多次調用同一個請求，每個請求都會産生一個回調，這樣，通過多傳一個參數辨別是哪個請求的，這樣接收的時候，就可以分支處理了。
好了，消息是發送了，可是，對方在哪接收呢？既然是在這裡開始，就在這裡結束好了！
還是構造函數裡添加事件：
public eventbutton()
{
//省略n行
app.client.notifyendgamereceived += new eventhandler<gameservice.notifyendgamereceivedeventargs>(client_notifyendgamereceived);
}
void client_notifyendgamereceived(object sender, gameservice.notifyendgamereceivedeventargs e)
//接收遊戲結束消息
接下來就是分支處理遊戲結束消息了：
void client_notifyendgamereceived(object sender, gameservice.notifyendgamereceivedeventargs e)
switch (e.player.attachinfo)
{
case "22"://平手請求
messageboxresult result = messagebox.show("對方請求平手，是否同意!", "遊戲請求", messageboxbutton.okcancel);
if (result == messageboxresult.ok)//同意
{
app.player.attachinfo = "21";//同意請求辨別位設為21
}
else//拒絕
app.player.attachinfo = "20";//拒絕請求辨別位設為20
app.client.endgameasync(app.player);
break;
}
看代碼，簡單的很，如果同意，回複21，拒絕，回複20，
接着，我們要對21,20的回複進行處理了。
void client_notifyendgamereceived(object sender, gameservice.notifyendgamereceivedeventargs e)
//...省略...
case "21":
//顯示同意平手，結束遊戲，向大夥廣播遊戲結束了
messagebox.show("對方同意平局", "遊戲通知", messageboxbutton.ok);
app.player.attachinfo = "2";//發出遊戲平局廣播。
app.client.startgameasync(app.player);
case "20":
//顯示拒絕，然後當什麼事也沒發生
messagebox.show("對方拒絕平局", "遊戲通知", messageboxbutton.ok);
唉，又多了一個遊戲平局廣播辨別"2"又要處理，好吧，處理吧，等會不會又出來其它數字吧，唉，這個還真有，認命吧。
case "2":
messagebox.show("雙方平局", "遊戲結果通知", messageboxbutton.ok);
粗略的算處理了。遊戲結束了，要幹點什麼呢？當然就是棋盤複位了，按鈕重置了，如果還有棋譜之類的，全都得重置。這些，我們留下到另一節優化處理吧。
吃飯時間快到了，要寫快一點，接下來處理認輸事件了：
二：認輸
同樣的，輕按兩下認輸按鈕，産生事件，這裡代碼也同樣很簡單，起個标志位，發送過去，認輸就直接廣播說輸了就行了：
private void btngamelose_click(object sender, routedeventargs e)
app.player.attachinfo = "0";
app.client.endgameasync(app.player);
大夥在遊戲結束通知消息裡處理一下：
ok,到此，兩個事件就處理完成了，隻是遊戲結束後的複位功能沒用實作，我們留到下節處理了，時間不等人，趕緊f5看下效果：
沒啥效果，預設那個兩個按鈕是不可用的，在遊戲開始後，要開啟那兩個按鈕，趕緊趕緊，加兩行代碼：
void client_notifystartgamereceived(object sender, gameservice.notifystartgamereceivedeventargs e)
//收到消息了應該咋辦
case "0"://通知可以開始遊戲
//...能省則省...
case "1"://請求開始遊戲
//...能省則省...
if (result == messageboxresult.ok)//同意開始遊戲
{
btngamedeuce.isenabled = true;
btngamelose.isenabled = true;
}
case "10":
case "11":
//...能省則省...
btngamedeuce.isenabled = true;
btngamelose.isenabled = true;
好了，抓緊f5看效果[上面那段1的if語句(綠色的)，是截圖後補上去的，不然就隻有一方的求各認輸按鈕顯示了]：
上圖看效果,“馬還走一步”，部落格園上圖檔出錯了，吃完飯回來再看看補上了。
文章先發了，圖後補。
現在補圖了：
1：遊戲開始了，“求和-認輸”啟用了：
2：求和發送，對方收到消息：
3：對方拒絕的後果：
4：對方同意的結果：
5：對方認輸了：
版權聲明：本文原創發表于部落格園，作者為路過秋天，原文連結：
http://www.cnblogs.com/cyq1162/archive/2010/08/03/1791063.html