其他

我曾介紹過以Email地址登入基於Membership管理的網站的方法，並指出這是一種更為安全的做法，使用者的Email通常不會暴露在網站中，而不知道Email也就無從破解實現登入。但是在密碼找回時，Asp.net提供的PasswordRecovery控制項還是要求使用者輸入使用者名稱以重設密碼的，這無疑會使使用了Email地址登入方案的網站的安全係數降低。並且無論網站是否使用Email地址登入，只要是禁用了安全提問，那麼直接在找回密碼的地方輸入使用者名稱，系統就會自動將使用者密碼重設為一個新的

關聯式資料庫中，一對多關聯性使用的非常普遍，多對多關係也時有用到，而一對一關聯性用的非常之少，本篇將展示一個一對一關聯性的使用樣本。首先我們有這樣一個資料庫：這是一個簡單的商務資料庫，現在有一個需求：要求使用者可以上傳多個圖片以展示商品、商鋪、市場、品牌，那麼怎麼設計呢？首先想到的是為每個表追加一個附屬表用於專門儲存圖片，那麼先建立市場照片表：接著是商鋪照片表：馬上你就會發現這樣冗餘很多，並且假如新增了一個網店表，那麼還得為其增加網店照片表，假如對照片記錄的資訊不滿意，想添加一個等寬縮圖欄位，那

這兩天做網站，某頁中使用了EntityDataSource結合FormView插入資料，先是自動產生了這麼個基本的表單： 然後運行，插入測試資料：（咋變這色了？？ ）  結果回回報錯!  始終找不出錯誤位置，弄得我直想撓牆。後來想到可能是Entity Framework中定義的所屬省、所屬市縣兩個屬性屬於對象引用，而FormView貌似是Asp.net

自從在VeryCD下了個Google SketchUp 7後，這兩天就一直在研究這個。話說我在3D領域是一個骨灰級菜鳥，3Ds

引言這幾天受委託開發一個網路電視項目，要求初步先使用內嵌網頁形式實現視頻播放和選單，以後再考慮將網頁中的所有功能整合進傳統型程式。播放器普遍都要有個看起來比較酷的外觀，於是我就給設計了個不規則形狀的帶透明邊框的外觀，如：但這個設計整合到WPF中時，卻遇到了一個頭疼的BUG：只要設定表單為AllowsTransparency="True"

 讀了一下Google黑板報的這篇文章：《動態網址與靜態網址》其中闡明動態網址不僅不會使索引和排名產生困難，反而機器人可通過參數更好的分析資訊，例如這樣的常規Url：www.example.com/article/bin/answer.foo?language=en&answer=3&sid=98971298178906&query=URL但不建議諸如以下形式的重寫：www.example.com/article/bin/answer.foo/en/3/989712981

JavaEye，雖然一直沒註冊，但感覺是個很不錯的技術網站，沒想到有這麼噁心的使用者體驗……：起先，從Google閱讀器上看到JavaEye上有人發Google Wave邀請函：於是興沖沖地點進去了，回複留Email索取唄，都填好了文字，點提交後，被告知要登入：得，那就註冊個號唄，三兩下填完註冊資訊，說要在郵箱裡收確認信才能完成註冊，沒問題，收了之後訪問了連結就啟用了。完了一登入，再跑去文章底下一看，變這樣了：嘿！他姥姥的，什麼狗屁小測驗，一路胡填好了，結果還不行，你答不對人家不讓你通過，我暈！

 現今，很多Web2.0網站都使用Email地址作為登入使用者名稱，其有如下優點：1.       不易重複。使用者名稱經常會重複，導致使用者不得不在多個網站之間使用多種不同的使用者名稱，不易記憶和管理；而Email地址具有唯一性。2.       易於記憶。使用者常用的Email地址一般不會超過三個，所以即使忘記了是哪一個，也能很快試出來。3.      

VisualBrush是一種比較特殊的筆刷，它的功能仍然是用來給元素填充圖案，但它的內容卻可以是各種控制項。你可以將其理解為一個普通的容器，但在其內部的所有控制項都會失去互動能力，而只保留顯示能力。你可以通過本例學習到關於VisualBrush的使用方法，以及複雜樣式的定製技巧。首先來看一下我們將要實現的效果的4倍放大圖：這個效果的特點如下：文字部分有白色泛光效果，使之看起來就像是發光體。按鈕下半部分有橢圓形的放射漸層，但注意其上下並不對稱。接下來就開工製作，首先建立一個WPF應用程式，胡亂放上

引言WebBrowser控制項的DocumentCompleted事件一般就被認定為是在頁面完全載入完畢後產生，而注釋中也是這麼寫的：但事實卻並非如此。首先它不一定會在完全載入完畢時才觸發，有時就會在載入過程中就會觸發。其次按照“完全載入完畢後”來理解，會認為通常一次頁面跳轉只會引發一次該事件，事實也並非如此，某些頁面載入時會引發十多次乃至更多。實驗做一個簡單實驗，首先設計這樣的介面：然後為那個轉到按鈕添加單擊事件處理：private void button1_Click(object

  我們現在已經習慣把互連網作為資料庫了，通過各種線上收藏服務組織我們的技術資料。然而互連網存在著諸多不確定性，我們收藏的資料有時會不翼而飛，比如目標伺服器癱瘓、遷移，或是原作者刪除了該文章，更為常見的情況就是文章配圖、附件連結失效，這些情況經常困擾我們。將資料儲存在本地無疑是最為安全的辦法，但將網頁一一“另存新檔”絕對是個麻煩事，也不便於管理；我以前是使用網文快捕來收集和管理技術資料，但近來感覺它有些臃腫、繁瑣，所以就沒有再使用了。而近來發現了這個優秀的Firefox擴充——ScrapBook

時至今日，混淆依然是.Net程式的一道重要保護手段，而混淆器對WPF應用程式的支援是怎樣的呢？我們今天就通過執行個體講解一下。首先建立如所示的簡單的使用者介面：在介面代碼中設定一些綁定屬性：在後台代碼中首先定義一個種族枚舉，以便於在列表中使用：下面在表單Window1類中定義以下屬性：紅圈處的代碼功能是將種族枚舉的全部值載入到種族列表屬性中，這樣就可以在前後台一直以統一、優雅的方式使用枚舉，這是個不錯的小技巧。接下來在建構函式中直接寫入程式碼一些屬性的值，然後將自己作為自己的DataContex

雲端是一款優秀的國產軟體，它通過虛擬環境的方式使軟體與系統隔離，使軟體做到免安裝、易於刪除、不留殘餘垃圾。（這裡捎帶提醒一下，雲端與Visual Studio有衝突，必須在禁用雲端服務的情況下安裝，詳見《Visual Studio 2010 旗艦版

接續上次的點擊測試，這次來做幾何地區測試樣本。 樣本首先建立一個WPF項目，在主介面中拖入一個按鈕控制項，並修改代碼中的以下高亮位置：當前設計檢視介面如下：接下來，轉到表單的“Window_Loaded”事件處理函數，編寫函數代碼：private void Window_Loaded(object sender, RoutedEventArgs e){Random r = new Random();for (int i = 0; i < 800; i++){var o = new

引言你是否曾遇到過這樣糟糕的體驗：你在一個網頁表單中，用心填寫好所有項目後，點提交按鈕時被告知“您提交的內容中有敏感資訊，請檢查！”，而你急得抓破頭皮也找不到所謂的“敏感資訊”在哪，幾經修改也還是一樣，致使根本無法提交內容；更糟糕的網站甚至提交後轉到其他頁面才告知你有“敏感資訊”，而此時你想重試的話只能重新填寫整個表單！顯然，這些網站有些過敏了，但或許有網站主確實就是抱著“寧可錯殺一千，絕不姑息一個”的想法來做的，這點在我國可以理解；不過就使用者體驗方面來說，我覺得用髒話回敬他們一點都不過分，因

我們在建立自訂的伺服器端控制項或是使用者控制項時，經常需要用到一些用戶端js指令碼，通常將其作為資源嵌入，並在頁面後台代碼中添加引用，但是如若用到一些通用的js庫（比如JQuery）時，就免不了產生一個疑問：如果使用此控制項的頁面也需要用到該庫時怎麼辦？在控制項中引入，在頁面中也引入，不就會造成頁面中引入兩次同一個或是兩個版本的js庫嗎？這不僅邏輯不通，而且可能浪費資源。如是不在控制項中引入，但要求頁面中必須引入，那麼拿給別人使用時免不了讓他一頭霧水，甚至某一天你自己都忘了這回事，對著一堆js錯

上次的彈力類比動畫實現後，我覺得可以把這個弄得更好玩一些，我們可以讓小球即時跟隨著滑鼠，並且還可以讓視窗完全消失，讓小球在案頭上飛來飛去。這隻需要一些簡單的修改就可以完成了：首先要去掉原有的滑鼠點擊事件處理，它們現在沒用了。在引用中添加對System.Drawing及System.Windows.Forms的引用：在處理X、Y座標變化的代碼前加入如下代碼：接下來要修改表單的屬性，以使其覆蓋全屏、總在最前、不顯示在工作列且完全透明，這需要進行以下的屬性設定：Background="Transpar

今天在使用EntityDataSource顯示資料時，返回的資料總是空的，確認過資料庫內資料後，嘗試去掉Where及參數，移除各種事件均告無效。後來建立了一個EntityDataSource，簡單配置一下資料來源，測試通過。撓牆半晌後看到Include屬性中包含了一個已經在資料庫及EDM中刪除的導覽屬性，去掉該屬性後測試即通過。雖然是個人的小失誤，但可恨的是對於這個簡單的錯誤EntityDataSource居然不給出任何提示，而是悶頭給吃了！不知道設計者是怎麼想的。

幾個月內先後購置了3部Android手機了，不是發燒買來玩，一個自己用的HTC Desire (G7)，一個老婆用的MOTO Milestone，一個給我爸新買的MOTO

我們現在使用的驗證手段都是以驗證碼為主，讓使用者根據圖片輸入驗證字元，這種方法的安全度尚可，但會給使用者帶來一些不便和困擾，比如這個雅虎的驗證碼：這個安全度很高，機器和人都無法正確識別了。 其實要讓人看得懂、機器看得暈，只要拿出我們人類的強項就可以了啊——影像識別，試想用圖片來做驗證是不是會很好呢：上面的樣本示範了圖片驗證的介面。使用者進行驗證時的操作很簡單，只需點選映像所屬的類別就可以了，還可以順道欣賞一片，很是愜意；而機器急大了頭也很難理解圖片的內容吧？ 有人說可以用複雜的瞳孔識別、臉部辨識