Nan Program Blog: 2013

2013年10月24日星期四

[C#] DataSourceID與DataSource的使用差異

1.若使用DataSourceID搭配 SqlDataSource（設定精靈）來作的話，可以完全不用寫程式，就能做到 GridView的「編輯」、「更新」、「刪除」，可以省去許多撰寫程式碼的時間。但缺點是 SqlDataSource這種精靈，能作的東西有限！

2.若GridView使用DataSource來繫結資料，那很抱歉，「編輯」、「更新」、「刪除」這些程式碼得自行Coding!!!但優點是不會被 SqlDataSource給綁住，發展空間大。

3.使用GridView透過DataSourceID，千萬別再下GridView.DataBind()指令，避免重覆繫結資料造成錯誤。原因是使用 DataSourceID，系統會自動產生.DataBind()的效果。

4.不可同時使用DataSourceID與DataSource，會出現Exception!!!

資料來源：閒談 DataSource 與 DataSourceID

2013年10月13日星期日

[VB] On Error GoTo ...、On Error Resume Next、On Error GoTo 0的比較

在VB程式撰寫裡，為了避免程式被不可預期的錯誤所中斷，可以使用下列三種指令來解決：

陳述式	描述
On Error GoTo line	啟動錯誤處理常式。且此常式的開始位置由 line 引數指定。此line引數是必要的而且是任何行標籤或是行號。如果發生一個執行階段錯誤，程式控制會跳到 line 的位置，使錯誤處理程式開始動作。指定的 line 必須是和 On Error 陳述式在同一個程序裏。否則，會發生編譯階段錯誤。
On Error Resume Next	表示當一個執行階段錯誤產生時，程式控制立刻到發生錯誤陳述式接下去的陳述式，而繼續執行下去。當使用一個物件的時候，請使用這個陳述式，而不要使用 On Error GoTo。
On Error GoTo 0	停止現在程序裡任何已啟動的錯誤處理程式。

如果不使用 On Error 陳述式，任何執行階段之錯誤都是嚴重的，結果會導致顯示錯誤訊息，並且中止執行。

On error goto line 與 On error resume next 這兩述敘使用的有效範圍為Sub或Function，例如在Sub或Function的開頭加上，在Sub或Function結束功能就失效，或者使用on error goto 0來取消功能。

若發生的錯誤都是可忽略的，建議使用On error resume next，如此程式就不會因為不可預期的錯誤所中斷了。

如果能知道錯誤的原因，每個錯誤都有個代號，在Err物件中，可由Err.Number來取得。如果錯誤原因有很多種，可以用On error goto line攔截錯誤，搭配Select Case分別提示使用者該如何處理，甚至可以轉回主畫面。架構如下：

On error goto line
...
...
line:
select case err.Number
case 錯誤編號
...
case 錯誤編號
...
case else
...
end select

這樣程式就不會中斷了。

參考資料：
1.On Error 陳述式
2.On Error的用法

2013年10月10日星期四

[SQL] case和decode的用法(行轉列)

假設現有一張Table叫Score如下：

姓名	科目	成績
阿毛	數學	100
阿毛	國文	89
阿花	數學	90
阿花	國文	70

現在目標要將Score這張Table轉換如下圖：

姓名	數學	國文
阿毛	100	89
阿花	90	70

這時SQL指令有兩種下法：

(SQL與Oracle都可用)Case 版：

Select 姓名,
sum((case when 科目='數學' then 成績 else 0 end)) 數學,
sum((case when 科目='國文' then 成績 else 0 end)) 國文
from Score
group by 姓名

Decode 版：(只有Oracle可用)

Select 姓名,
sum(decode(科目,'數學',成績,0)) 數學,
sum(decode(科目,'國文',成績,0)) 國文
from Score
group by 姓名

參考資料：sql與oracle中有關case和decode的用法(行轉列)及比較

2013年9月28日星期六

[HTML] 項目符號<ul>與項目編號<ol>使用(格式)

※在利用<ul>及<ol>時，要搭配<li>來使用

※<ul>：

<ul>可做出項目符號，舉例如下：

<ul>
<li>項目一</li>
<li>項目二</li>
</ul>

其執行結果如下：

項目一
項目二

※<ol>：

<ol>可做出項目編號，舉例如下：

<ol>
<li>編號一</li>
<li>編號二</li>
</ol>

其執行結果如下：

編號一
編號二

參考資料：通達人筆記-在HTML內使用編號<ol>或符號<ul>

[C# VB] page_load 與 page_init差別

簡單的區分，如果是要"動態建立控制項"，那就要在Init事件中；如果是要"讀取正確的控制項屬性值"，那就要在Load事件中。需要這樣做的原因是 LoadViewState 的動作介於Init事件之後及Load事件之前。(參考網頁生命週期：ASP.NET 網頁生命週期概觀)

LoadViewState (以下簡稱LVS)的作用是載入ViewState的資料來更新控制項屬性值，所以必須在LVS之前就把控制項建立完成，才有辨法由ViewState中載入最新屬性值，所以一定要在Init事件中把控制項建立完成，在此事件中讀取控制項的屬性值都是初始值，也就是設計階段時屬性視窗中的值。而 Load 事件是在 LVS動作之後觸發，所以在Load事件中讀到的控制項屬性值才是最新值，而不會是初始值。

控制項的初始化(Initialize)的動作一定要放在 Page_Init 事件中！控制項的初始化也包括設定控制項的預設值(Default Value)。千萬不能將設定控制項初始值的程式碼寫在 Page_Load 事件裡，否則當 PostBack 回來的值會被 Page_Load 事件中的程式碼蓋掉。動態將控制項加入到 ASP.NET 頁面中「最好」在 Page_Load 事件中執行，以確保在後續事件中可以取得頁面中所有的控制項。

參考資料：
1.[Asp.Net] Web Form 的事件簡介
2.ASP.NET 動態載入的控制項一定要注意的事

2013年9月25日星期三

[C# VB] console.writeline 與 response.write差別

Console.WriteLine()是輸出到屏幕的，一般用在控制台程序中。

Response.Write()是輸出到網頁，一般用在WebSite或者WebApplaction中。

所以如果在撰寫ASP.NET程式時利用Console.WriteLine()會出現例外(如下圖)：

不過，既然在ASP.NET網頁程式撰寫中不能用Console.WriteLine()，為什麼提示字元還是可以找到Console.WriteLine()，應該是因為撰寫的語言是C#關係吧?!

[HTML] Table的建立(格式)

HTML表格建立的標準格式如下：

<table>
<tr> //新增列
<td> //新增欄
</td>
</tr>
</table>

說明：
每一個tr表示一個"列"，在每個tr裡可以新增欄(即td)。

舉例1：(一列兩欄)
<tr> //新增一列
<td> //新增第一欄
</td>
<td> //新增第二欄
</td>
</tr>

輸出結果：

第一欄

第二欄