如果你在網頁設計上面已經著墨很久的話，或許你會發現 HTML 實在是一種非常不嚴格的語言 (它確實是一種語言；它的名稱也是這樣來的)。我這裡要很簡單的介紹一個在 HTML5 標準中新加入的元素－article，以及非常類似的 section，並且會探討它們的差異...
在這個全世界有數百萬起跳的人口都在從事軟體開發工作的今天，程式設計絕對不是一個適合單打獨鬥的行業。雖然我個人也是個偏好親手下去寫所有程式的開發人員，但是若想應付改來改去的需求、節省時間、準時交件的話，有時候不借助他人之力是不行的。很幸運的，確實有很多已經寫好、包好、測試好 (而且好用 － 這是重點) 的套用就在網路上，為什麼還需要凡事都自已動手？問題是，通常這些套件的安裝非常繁複、要面對的情況也很多樣。有時候光是安裝這些套件就會難倒一堆人，甚至興起不如自已寫還比較快的想法...
最近在維護一個 C++ 專案，在迫不得已的情況下重新溫習了已經十幾年沒踫的指標 (Pointer)。而且，很不幸的，跟十幾年前一樣被搞得暈頭轉向 (在 C# 跟 VB 中根本不會有這種問題)，所以只好花點時間把 C++ 指標相關重點摘錄起來供自已及有興趣的朋友們參考...
對傳統程式設計師而言, XNA 可以算是一個面臨多種適用狀況的開發環境。為什麼呢? 因為你所開發的程式, 只要經過小小的修改, 就可以移轉到 PC、XBOX 與 WP7 裝置上面。而它的輸入裝置也很多樣, 包括鍵盤、滑鼠、XBOX 搖桿、觸控輸入, 甚至其它。到目前為止, 我手頭上可以運用的輸入裝置除了鍵盤、滑鼠, 還有 XBOX 搖桿 (這東西花了我一千多塊錢), 但是事實上 XNA 可以接受更多的輸入裝置, 例如 WP7 的(多點)觸控輸入、加速感應裝置, 甚至未來的語音輸入裝置, 還有 Kinect 等等。如果我們希望在程式裡同時支援這些裝置, 無可避免的, 我們都必須為每一項撰寫對應的程式...
Interoperation是工程界普遍使用的字眼, 專指在不同系統中搭起的簡易或臨時的元件, 藉由製訂某些共通的協定, 以便這些系統可以共同作業。由於這個溝通界面可能並非非常嚴謹, 所以當其運作時, 必須特別有人從旁監督、隨時調整和修改。在.Net 中, Interoperation 專指從.Net 應用程式中存取unmanaged 程式元件的行為。我們知道, 當我們撰寫.Net 應用程式或元件時, 這些元件都是managed (受.Net 執行環境所管理的)。但是如果是使用VB6/C/C++ 所撰寫的非.Net 程式或元件, 對.Net 而言, 都算是unmanaged。如果我們企圖在.Net 程式中存取那些unmanaged 程式或資源, 就必須透過Interoperation 技巧與COM 介接。此外, 許多Windows API 並沒有.Net 的對應函式。換句話說, 如果我們要撰寫Windows 應用程式, 而且我們必須使用到Windows API 的話, 我們沒辦法從.Net Framework 執行環境中找到對應的方法, 而必須透過Interoperation 去呼叫W
很多事情都是必須遇到了才會重視。使用 Master Page 是每個 ASP.NET 程式設計師都必須了解、甚至精通的; 我也一直覺得我對這部份的技術非常精通, 直到我在最近設計的網站遇到某個比較少用到的功能, 才發現有很多事情並沒有原先想像的那麼直覺。什麼事情呢? 就是我原本放置在 Master Page 部份的控制項, 如果我必須在 Content Page 處理它的事件, 應該怎麼做?
差不多每隔一段時間, 就會看到有人又重覆的詢問這個問題, 或者雖然沒有問到這個問題, 卻不停的懷疑為什麼在某些網站可以做的事情, 在另一個網站上面卻不行。其實這些問題通通必須回歸到一個最基本的問題, 那就是請你恢復一下記憶, 你是用什麼方式建立你的網站的...
當我們在網頁上設計了表單, 讓使用者填寫資料, 使用者通常有很大的機率會因為各式各樣的原因而意外地跳出頁面。如果表單很簡單, 或者使用者根本還沒有填寫什麼資料, 那麼使用者就算不小心離開頁面, 也不會有什麼損失。但是如果使用者已經填寫了很多資料 (例如姓名、地址、電話等等), 但是在他按下確認按鈕之前, 卻不小心按到上一頁、下一頁、關閉分頁、關閉視窗等按鈕, 那麼不管他使用何種方式回到這一頁, 他曾經填寫的資料可能都無法救回來。除非你只寫網頁給別人用, 自己從不上網, 否則我相信你一定也遇過這種切身之痛 -- 花了幾十分鐘, 甚至幾個小時打進去的文章, 卻由於一個不小心的動作, 讓自己辛苦的成果在瞬間徹底消失了! 不瞞你說, 我自己遇過太多次此種痛苦的經驗, 導致我曾有一段很長的時間, 即使只是填入自己家裡的住址而已, 我也一定要開啟 Notepad 來打字(而且還要隨時存檔), 打完之後再把文字複製貼回網頁...
經過不眠不休地多方嘗試及網路爬文的結果, 我發現在 Windows Phone 開發環境之下, 對於 Silverlight 多語系的支援方法其實和在 Web Form 或 Windows Form 真的是差不多的。但是其中仍然有一些小小的差異, 如果排列組合略有差池, 就得不到想要的結果...
我不曉得諸位同好都是怎麼進行 WP7 多語系支援的開發工作的, 但對於沒有實體 WP7 手機的我來講, Emulator 就是我唯一可以用的手機。當我企圖測試我的多語系顯示時, 卻發生了一個窘境 - 不知道怎麼變更語系! 目前在 Emulator 上面唯一可以變更 locale 的地方就是在 Settings > Region and Language 畫面中把 System Locale 更改為 Chinese (Taiwan), 但是這對測試一點幫助都沒有, 使用 System.Globalization.CultureInfo.CurrentCulture 取出來的 CultureInfo 仍然是 en-US...
如果你看到這篇文章時, 或許你會對於這個標題感覺到十分的詭異。是的, 如果我不是遇到這個詭異的問題, 也不會下這種詭異的標題...
目前 WP7 開發者能夠用來存取 local 端資訊的唯一方法還是只能透過 IsolatedStorage。在 WP7 手機上, 此種 IsolatedStorage 的存放位置並不允許使用者以目錄瀏覽的... 當然, 有人會將資訊儲存在「雲端」, 如此就無需把資料存放在手持裝置裡面。但是我們可能要考慮到一種情況, 就是一旦這個手機並未連上網際網路時 (可能是因為無系統服務或為了省電因素而將連線關閉等等), 所有必須透過網路存取的資料將會完全消失。這時候, 我們又必須重新回頭思考將資訊存放在 local 端的必要性。既然如此, 我們還是非得熟悉 IsolatedStorage 不可...
當我們在設計 Windows Phone 7 程式時, 對於一個習慣於 Windows Form 和 Web Form 的程式設計師而言, 可能會覺得有點納悶: 為什麼找不到 ComboBox? 其實 ComoBox 仍然是可以用的, 只是它並未列在工具箱裡面而已...
我要在這裡說明的所謂「集合型別」指的並不是泛指 System.Collections 命名空間下的各種型別, 而是特別指自從 .Net 3.5 之後才出現的 Sets (集合) 型別, 特別是 System.Collections.Generic.HashSet 與 System.Collections.Generic.SortedSet 這兩個實作 ISet 介面的類別。ISet 介面是專門針對集合作業而設計的, 它提供了幾個特別的方法...
這個小工具是我使用 C#, Winform 在 Visual Studio 2010 上面開發的, 其主要目的原本是寫來專供自己使用, 但是一不小心把它做得似乎完整了一點, 覺得應該也可以拿來貢獻給其他人來用用, 所以就繼續稍為給它加了一點工, 順手連多國語言也做好了 (雖然目前只有繁體中文和英文而已, 但是框架是 OK 的, 可以擴充)...
不管你學的是何種程式語言, 非同步及平行處理總是最令人費解的部份之一。如果你沒有過人的邏輯觀念, 那麼要把非同步程式寫好, 恐怕有一定的困難度。不過最難的部份不在技術上, 而是到底在何種場合下可以採用非同步或平行處理。在日常生活中, 我們採用的邏輯大多是循序進行的, 也就是說, 等到前一件事情完成之後, 才去進行下一件。但是在某些情況下, 非同步處理是比較合乎情理的做法...
大部份剛入門的網頁設計師, 對於 HTML 表格的認識可能僅止於 <table>、<tr > 和 <td> 而已。稍為進階一點的, 可能知道像 colspan 和 rowspan 等等屬性。但是最近我很驚訝的發現有幾位已經從事網頁設計師蠻長一段時間的人, 其實並不知道(或不記得)有其它表格元素或屬性的存在...
在網頁設計的領域中, 我覺得 HTML 表格大概是最受人誤用/誤解的網頁技術了。一方面, 我們時常可以看到在某些網頁上有數都數不盡的、層層套疊的
在品管圈裡有一個很著名的水泥救生衣的笑話, 大意是說, 一個公司即使通過 ISO 或 CMMI 等認證, 也不能保證它不會做出水泥救生衣這種產品出來。非品管圈的人可能無法在一開始就看懂這個笑話; 但是請你再仔細想想看, 救生衣可以是水泥做的嗎? 如果真有這種東西的話, 也是黑幫拿來謀財害命用的, 不是拿來救人的。ISO 或 CMMI 的主要目的, 在於檢驗設計或生產的流程是否完善而且嚴格的被遵循, 它們卻沒有辦法保證設計或生產的東西是不是合理或賣不賣得出去...
Design Pattern 通常都是由許多人推薦的軟體架構模式, 而且有其固定的規則可循。我們可以把一些素有口碑的設計樣式拿來套用在某種情境之下, 但是我十分反對為套用 Design Pattern 而套用 Design Pattern。應該是反過來, 我們最好事先評估自己的情境適合應用何種 Design Pattern, 再來決定是否套用某種 Design Pattern, 不然就會流於削足適履...