都不記得是什麼時候看的JScript的文法教程了，裡面說在聲明變數時忽略var關鍵字是完全合法的。當時也因為覺得JavaScript是loosely-typed的語言，所以var可能真的就是個擺設。但是事實常常又證明想當然的結果是不可靠的。 看看下面這幾個例子的結果就知道問題了： No.1<script language="javascript">var var00 = 0;document.write(var00 + '<br>');var var0
上次我寫過一篇文章，討論"JavaScript類定義原型方法的兩種實現的區別"。研究後發現除了方法的初始化方式不同外，沒有發現別的原則上的卻別，也就是說用哪種方式都一樣。可是後來發現在VS.NET中給原型方法設定斷點來調試時，兩種定義方式卻出現了很大的差別。 先看如下程式碼範例： 1 ToolBar.prototype.Dispose = function() 2 { 3 var elmt = this.GetElement();
SmartNavigation這個Page屬性很有意思，他在不改動（其實是改動很小）頁面元素布局的情況下，居然可以類比出非常平滑的“無重新整理”頁面，為什麼這個“無重新整理”要闊起來呢？其實他是重新整理了的，而且用的也不是什麼xmlhttp也不是xmldom技術，它是事實在在的Submit，可能這樣是為了瀏覽器安全色性什麼的來考慮的吧。
我們都知道，IE實現的是一種叫做bubble up的事件模型。在這個模型中我們的事件可以通過Web頁元素的hierarchy，從事件觸發元素向其parentElement傳遞，除非被顯示的cancel。不過在一些複雜的事件響應處理中，還有很多細節需要仔細考慮。
似乎是挺無聊的一個功能，阻止使用者使用Shift+Click超級連結開啟新的頁面。不過既然有這樣的bt需求，我就簡單設計了一個解決方案。雖然是能解決大部分問題，不過遇到複製連結再在別的browser中去開啟就沒有好的阻止辦法了。
.NET Framework 2.0 中的 SmartNavigation和1.1中實現是一樣的，但有三個地方有變動： 第一個是增加了一個狀態參數"__smartNavPostBack"，它由一個隱藏欄位來實現的，在attachForm到IFrame __smartNav上的時候，動態插入到From中。他的狀態在 window.__smartNav.init 被置為了true(預設是false)，但是這個狀態並沒有在整個Smart
在看MyMsn的指令碼原始碼時，發現裡面有一些微軟自己遇到的bug也不能解決。列在這裡，如果我們自己也遇到時就不要再鬱悶了。 1、在設定HTML元素的capture狀態時： // we clear any current selection because it will get stuck in selected state after drop (bug 211)document.selection.clear(); // 這個缺陷我還沒有遇到，不過既然微軟說有可能發生，
無意中發現W3C和M$在DOM的屬性命名中，對於whatElement格式居然有截然完全不同的態度。下面我們比較一下W3C的DOM3和M$的IE6中的DOM在屬性命名上的區別。
上一次說了一下要支援無限級的動態載入TreeView控制項，伺服器端資料的準備情況。不過那隻是一個小小的示範執行個體，在實際的使用中，伺服器端的資料可能會完全的不同，不過不管怎麼變化，也必須要保證能形成樹形資料的request/response結構。 由於TreeView必須在載入了節點資訊有才能被Show出來，所以這裡我們先手動把root level的節點產生。程式碼範例如下： <script Language="javascript">var tree = new
關於javascript中的parseInt方法，本來沒有什麼好說的，它的功能就是把一個字串從左向右的可識別的數字部分轉換成數值，並且它還有個可選的參數radix。這不，問題就出在這個參數上了。 關於parseInt的解釋msdn說得很清楚，抄過來就行了： parseInt(numString, [radix]) Arguments numString Required. A string to convert into a number.
原來在程式中類比事件觸發的時候，我寫過一篇文章叫"在什麼時候才會用到fireEvent方法呢?"。文章中說了我們怎麼樣來使用類比事件的詳細方法和步驟，不過當時忽略了fireEvent的一個Optional的參數oEventObject，它是做什麼的呢？
在HTML的元素中，有一個比較特殊的元素form。我們用它來收集表單資料並提交給伺服器，並且理論上說來它是沒有任何的UI被呈現的。當然如果我們在body元素後緊跟一個form，這樣一來似乎看不出來有什麼UI呈現的問題，可是當form存在於別的元素之中時，就有問題了。 什麼問題呢？看下面的樣本，由於頁面配置的需要，我需要控制頁面的捲軸。我把body的捲軸隱藏掉，然後使用一個div元素來"自製"一個捲軸，html代碼如下： <html> <head>
我們知道網頁中的路徑關係一般有兩種情況，一是相對路徑，一是絕對路徑。今天在調試一個bug的時候，發現IIS對於相對路徑的解析有些不一致的問題，害我調試了半天。那麼到底是什麼不一致呢？ 簡單說一下Web頁中路徑的關係，前面說的絕對路徑麼沒啥可說的，不過有兩種情況。一是以protocol prefix開頭的絕對路徑，這是最絕對了，沒有任何含混的東東；二是以"/"開頭的絕對路徑，這個嘛就是從伺服器的根開始算，一般情況下也不會有太大的問題了。相對路徑也是兩種情況，一是向前定位的路徑，一個"
在"JavaScript中this關鍵字使用方法詳解"一文中，我曾例舉了在JavaScript和JScript中的8種this關鍵字的方式。這不又發現還有兩種this關鍵字的使用方式當時沒有說到，現補充說明一下。並且通過第一種this關鍵字使用的說明，能讓我們更好的理解JavaScript作為Object-Based語言的本質。 一種是和JavaScript類中的定義有關，我們知道當我們定義如下類的時候：
由於我的MSDN宇宙版訂閱已經到期了，這次這個Visual Studio .NET 2005的Beta2下載的才叫鬱悶呢。而且最後下回來還差點不能安裝，3.75G的DVD ISO哦~ 真是要讓人暈死啊！
記得很久以前玩聊天室的時候，新的聊天內容被顯示出來後，捲軸總是會滾動到聊天內容視窗的底部。不過那種聊天視窗一般都是使用frame/iframe製作的，我們可以使用其document對象的scrollTop屬性來滾動視窗。如果使用TextArea來記錄遞增內容，怎麼達到同樣的效果呢？
做dhtml開發，除了調試不是十分的方便外，我們還需要或多或少的考慮同一瀏覽器的版本問題。而比這些問題更讓複雜dhtml開發鬱悶的，卻是對cross-browser瀏覽的支援。正好有人問到這個問題，我就簡單的說說我的看法。
我們知道JScript中對象的prototype屬性，是用來返回物件類型原型的引用的。我們使用prototype屬性提供對象的類的一組準系統。並且對象的新執行個體會"繼承"賦予該對象原型的操作。但是這個prototype到底是怎麼實現和被管理的呢？ 對於對象的prototype屬性的說明，JScript手冊上如是說：所有 JScript 內部對象都有唯讀 prototype
昨天說了說我對於dhtml開發中cross-browser支援的問題，那麼我們怎麼來最經濟實惠的實現cross-browser呢？當然這裡就不討論是否有條件或有必要來做了問題了，昨天已經詳細說過我的觀點了，而這裡只是從dhtml開發本身上來看。 首先我們知道由於JavaScript是解釋性的語言，而我們說的支援指令碼cross-browser運行，只是我們對於不同browser中相同功能不同interface調用的一個route處理。
原來我一直以為Web頁面中的捲軸寬度是不能精確確定的，因為使用者自己可以在案頭屬性中設定系統捲軸的寬度為任意整數。再加之上次在MyMsn的代碼裡看見M$程式員的注釋，更加讓我認為捲軸的寬度是不能精確計算地。但事實是怎麼樣的呢？ 實際上對於HTML裡面的容器元素，它們的長、寬之間存在這樣的運算關係： width = border-left-width + clientWidth + border-right-width; height =
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
