其他

真是沒記性啊~第三次了以前一網友寫自己的控制項時,發現script放在.js檔案裡會莫名其妙的出錯,放在aspx裡卻沒事.研究了好久,終於發現,VS.NET裡建立的.js檔案是GB2312編碼的!中文變數在GB2312的js和UTF8的aspx之間跨越自然會成亂碼.解決辦法很簡單,在VS.NET把.js另存新檔.在對話方塊的"另存新檔編碼"按鈕選UTF8就可以了.不過因為很少用js檔案,我老是不記得...

最近學NHibernate,集合的幾種類型搞得我頭暈.我問了幾個搞java的同學,都說集合一般用set,但是NHibernate裡set得聲明成IDictionary,我就搞不懂,幹嘛要用個鍵/值對去存放集合呢?後來跟同學討論了好久,才搞清楚真相:Set在java裡頭是列表而不是字典,他和List不同的地方是不能有重複的值.問題就在.net本身沒有類似set的東西,於是NHibernate裡頭自己做了幾個set類型,他卻是實現IDictionary的,可能是利用一個內部的HashTable來阻止

CodeSmith是一個模仿asp.net運行機制的代碼產生器,  運行時分析模板(相當aspx檔案)的先行編譯指令和主體內容, 產生一個繼承自CodeSmith.Engine.CodeTemplate(相當於System.Web.UI.Page)或者一個在Inherites先行編譯指令指定的類(相當於CodeBehind類)的源碼, 且把它編譯. 然後把這個類綁定到一個PropertyGrid,

.net發展的比較晚,所以.net程式員的來源比較雜,什麼樣的人都有:純.net程式員:一開始就用.net的,或者以前有用其他語言,但沒有受其影響的,規規矩矩,緊跟ms的指導方向.這裡的人大多數是這類吧,包括我把.net當java用的:算正常. 本來就很相似的東西,思維活躍把.net當Delphi用的:對控制項高度興趣, 濫用繼承, 有些做asp.net的可能還不是很瞭解HTML和Script把.net當VB用的:喜歡用VB.net, 不懂OO, 對控制項感興趣,

using System;using System.Web;using System.Web.UI;using System.Web.UI.WebControls;namespace PageGrid{    public class GridPager    {        int _pageSize;        string _header;        /**//// <summary>        /// 傳入DataGrid的引用和每頁記錄數,讓DataGrid在

最近在做的asp.net項目採用了一個aspx+多個ascx的方式, ascx包含了資料錄入的控制項, 而aspx只包含了用於和使用者操作的控制項, 主要就是在頂端放一個用datalist做成的tab, 根據設定檔顯示出可做的操作, 可能是跳轉到一個明細記錄的編輯介面,或者是儲存刪除等操作. 客戶急著要在星期一使用, 而程式還未經過測試,於是今天下午項目組的同事都一起來幫忙測, 結果發現, 除了我自己的機, 其他人的都不能正常使用. 現象是點擊tab的時候, 偶然會跳轉到不正確的頁面,

  以下是描述在一個資料訪問層的設計過程（只一個總體設計並不包含細節）運用基於介面編程的方法設計；以下純屬表達我個人的設計過程中方法，如果朋友有問題和見解發表出來多多交流。在做資料庫應用系統的過程經常要和資料處理對象，SQL語句打交道；做久了就發覺其實這些工作可以通過封裝相應的組件來簡化這方面的工作。於是就下定決心把這個組件做出來，在做之前先把以前的東西和上網看的資料總結一下，重要一點是資料在處理SQL語句有什麼細節的差別如參數名標認等；明確做這個組件目的和組件需要完成的功能。組件的功能包括： 

測試環境：    Server: P4 2.4G 1G記憶體    Client: P4 1.8G 1G 內容Client使用ASP.NET 2.0建立遠程對象；然後通過ACT對Clinet進行測試。服務端代碼：ChannelServices.RegisterChannel(new HttpChannel (8081));WellKnownServiceTypeEntry myWellKnownServiceTypeEntry =                new

剛才在做一個使用NHibernate的主從表維護的頁面.hibernate的一對多集合一般用Set,一種元素不可重複的集合.由於.Net沒有Set,作者先用HashTable或SortedList湊合用著,而集合的類型必須要聲明為IDictionary.因為某些原因我必須要對從表資料按Id排序,於是在設定檔加上一個自己寫的Comparer.結果程式莫名其妙出錯,明明加了兩個不同的記錄,確會出現"加入了重複的鍵"的錯誤.後來經過調試和實驗才知道,NHibernate會把可排序的Set執行個體化成S

雖然各種語言有很多地方是相通的, 但確實覺得用不同語言的人的思維方式會有明顯的差別. 這更多是文化上而不是技術上的差異造成的. 就算同是.net, 部落格園和csdn net板塊的風格差異就十分大, jdon還跟javaeye吵架. 和什麼樣的人一起混多了, 思想就會被同化這是個很有趣的比較, 請看國內.net, java, delphi領域中最有代表性的社區裡的.net話題, 看看區別有多大:部落格園, 這就是 javaeye,

aspx頁面裡除了先行編譯指令外,服務端控制項標記,服務端指令碼將會被提取出來,經分析後或建立相應的服務端控制項並加入控制項樹,或者成為類的一個方法或者方法裡的一段代碼.其餘的文本將會作為LiteralControl加入控制項樹.也就是說編譯器編譯aspx時並不在意<!-- -->標記,這隻對用戶端瀏覽器才有效. 伺服器標記放在<!-- -->裡確實會讓輸出的內容看不見了,但實際上這並不影響控制項在服務端的行為,忽略裡面的文本只是瀏覽器的責任.

借首頁發發牢騷 事情是由一個同事的辭職引起的. 他辭職理由之一使用是公司的一個二次開發平台會影響個人發展. 部門經理聽了很不解, 接著他一個個把使用過這平台的人找去談話, 詢問對使用此平台的感受. 結果我說, 它確實對個人發展不利, 並且順便提出, 我要辭職. 幾位新來的同事倒沒有說什麼, 我估計是因為面對著經理不敢說實話, 因為平時的談話中感覺到他們也有點牢騷的.有必要先介紹一下這個二次開發平台. 這個系統的開發模式很特別, 並不用寫程式,

  前段時間CSDN上的一個朋友問到DropDownList添加ListItem的時候在Attributes中添加了Style項，但實際瀏覽的時候確沒有這個效果。後來我反編譯了DropDownList看了一下，發覺DropDownList控制項並沒有把ListItem的Attributes進行輸出。所以我從DropDownList派生出來重寫了幾個方法實現相關功能。代碼如下：public class MyDrop :DropDownList       {             

一直在實現.NET下的O/R M組件,但在把SQL條件運算式注入組件的過程中想法生了一些轉變。雖然O/R M在某些資料操作上的確很靈活和方便，但對關係和對象的依賴性強；對於一些複雜的查詢和統計O/R M不太適合（這隻是個人看法）。  作為一個資料處理組件它應該能夠很好的解決資料處理問題，經過一段時間的思考決定把SQL語句對象化；實現SQL語句在.NET平台下快速調用，O/R

除了"市"外其他select都是DynamicDropDown控制項, DynamicDropDown指定監視某一個控制項, 當被監視控制項的某個用戶端事件發生時會用xmlhttp往服務端回傳資料, DynamicDropDown在服務端的Request事件會被觸發, 在Request的事件處理常式裡即可控制列表的選項. 一個DynamicDropDown的onchange同樣也可以引發另一個DynamicDropDown的Request事件,

  我在做一個O/R M組件，現在想測試它的效能。我開始的做法是在頁面分別用我的組件和SQL語句向資料庫插入資料；然後通過Microsoft Application Center Test來測試各自的使用者並發數。雖然組件在測試上是比SQL直接操作要高些（因為組件用到命令緩衝），但有很多人說這樣測試組件的效能不準確,的確在實際情況下業務的操作並不只是插入資料。自己在這方面的經驗少，不知道如何測試做到合理。請有經驗的朋友提供個測試方案,主要測試方面是組件增、刪、改和查等操作。

泛型有什麼好處就這裡就不介紹，因為網上有更多詳盡的資料。下面看一下相關情況的類結構圖：以上是制定業務處理的基礎規則結構圖，裡面分別描述了基於泛型的查詢基礎規則（QueryAdapterAs）和不基於泛型的查詢基礎規則（QueryAdapter）;兩者完成的功能都是對IFilter描述資訊進行資料查詢。使用代碼：QueryAdapter query = new QueryAdapter();CategoryFilter filter = new

    由於Flex內建的日期使用起來感覺不爽，所以自己動手寫了一個。    在這話就不多說了下面的控制項的效果和實現代碼：<?xml version="1.0" encoding="utf-8"?><mx:Form initialize="oninit()" xmlns:mx="http://www.adobe.com/2006/mxml" height="22" paddingBottom="0" paddingLeft="0" paddingRight="0"

    ASP.NET中提供了ViewState這樣一個特性來儲存頁面級的狀態資訊；這本來是一個很不錯的東西（我個人認為），不過即使是好東西一旦濫用都有可能帶來很嚴重的後果！在Page的生命週期裡會對ViewState進行載入和儲存，同樣會發送到客戶和客戶提交給伺服器。當ViewState處理的東西非常多和複雜時，就會引發能性和資料轉送的壓力(聽說ASP.NET