想必大家應該都有聽過 Windows 內有一個訊息迴圈 (Message Loop) 吧,這個 Loop 是每個 Windows 應用程式都有的東西,藉由 GetMessage(), DispatchMessage() 與 TranslateMessage() 三個 API,將訊息分派給各自的處理常式去處理。
[.NET] 實作訊息迴圈 (Message Loops): Part 1
- 9843
- 0
- .NET Framework
想必大家應該都有聽過 Windows 內有一個訊息迴圈 (Message Loop) 吧,這個 Loop 是每個 Windows 應用程式都有的東西,藉由 GetMessage(), DispatchMessage() 與 TranslateMessage() 三個 API,將訊息分派給各自的處理常式去處理。
Strong Name 是 .NET Framework 中很特殊的一個特性,大多數的 .NET 開發人員不會使用到這樣東西,不過如果是從事 Framework 或是可轉散布型的軟體的開發人員,就需要知道這東西,因為它是一種組件識別 (asembly Identify) 機制,透過 Storng Name,它可以讓使用該組件的開發人員能確定這個組件是來自於建置的廠商或開發人員,而不是從中被竄改過。
今天在使用 MailMessage 和 SmtpClient 寫寄信程式,按照平常的寫法去做,Compile 沒有問題,但發信時卻出現了 "必須指定來源位址" 的訊息,但原程式和以前沒什麼變啊 (當下看的),後來我去查了一下 MSDN Library,發現了兩個很模棱兩可的屬性...
在 Intel AppUp SDK Developer's Guide 中,有不少的篇幅都是在講應用程式和 SDK 一些函式的整合,以將 AppUp Center 的機能和應用程式整合在一起,像是 Application Registration, Instrumentation (Events), Upgrade 與 Crash Report 等,除了之前我所發表的使用 Exception 決定 Crash Report 的功能外,我們還可以進一步的將 SDK 的函式包裝起來,讓在整合 SDK 和應用程式的過程能更簡單,簡單到什麼程度呢 ... 只要使用一個類別即可,而且相關的 Exception 都會轉換成自訂的 Crash Report。
這是今天碰到的有趣問題。一般我們在使用對稱 (或非對稱) 加密演算法加密資料時,很習慣的就用 CryptoStream,然後用 Write 來加密,用 Read 來解密,而且平常也是用的好好的,一些字串加密的工作其實很容易就做完了。但是如果遇到了檔案型的資料時,很容易會因為檔案大小在加密時發生變化,而導致解密時檔案無法被打開 (ex: Office 2007 的檔案)。如果觀察一下,可以發現原始資料和加密過的資料大小會有不同。
Crash Report 的原理部份 Alex Lee 大已經有寫一篇文章說明,這裡我就不贅述,不過如果要為每個錯誤都覆寫一次 DefaultCrashReport,那如果應用程式中有上百種錯誤,那豈不是要寫上百個 Crash Report?累死人也 … 那如果可以把 Crash Report 的資料交由 Exception 來決定,開發人員只要簡單的產生自訂的 Exception 的話,那不就變得很簡單?
Intel AppUp Developer Program 是一個由 Intel 建置的軟體市集,就像 Apple AppStore 或微軟的 AppHub 一樣,可以讓開發人員自由上傳應用程式,並且由使用者於 AppUp Center 中付費或免費下載使用,而且 AppUp Center 不限於 Mobility 應用程式,它也可以支援 Windows 以及 Web (Flash AIR) 應用程式,而且 Windows 程式還可以支援到 .NET 以及 C++ 環境,更好的是現在 Intel 為了推廣 IADP 計畫,免收 $99 美金的註冊費用,對開發人員來說也算是一種好康吧。
今天修練開始,首發 Intel AppUp Developer Program 平台開發的第一篇文章,就先來談談掛在 Visual Studio 上的這個 AppUp Software Debugger 好了。
自昨天首發 EasyOAuth Library for Desktop Application 後,今天再進一步發表 EasyOAuth Library for Web Application,這個函式庫可以支援 ASP.NET 與 ASP.NET MVC 應用程式開發支援 OAuth 功能的 Web 應用程式,它一樣可以在少量程式開發的情況下讓 Web 應用程式支援 OAuth 的功能,並且與 EasyOAuth Library for Desktop Application 一樣,可支援 Google, Facebook, Yahoo 與 Twitter 四種內建的 OAuth Service Provider。
這是筆者的第三個 Codeplex 開放原始碼專案,承繼前面四篇 OAuth Series 文章的說明,EasyOAuth Library 建構於 .NET Framework 之上,並且可以很容易的將 OAuth 的功能套用到自己的 .NET 應用程式中,並且開發人員可以依照 EasyOAuth Library 開放的介面,為非內建的 OAuth Service Provider 開發介面,以在 EasyOAuth Library 中直接使用。
在前一回完成了整個 OAuth 驗證與授權的流程後,程式應該可以成功取得 Access Token 以及 Access Token Secret,只要有這兩個資料,應用程式就可以以 Access Token 所代表的使用者來與 OAuth 服務的 Private API 來互動,大多數 OAuth 服務上的 API 都會需要先取得 Access Token 後才可以使用 (雖然還是有少數可以不用啦),所以這篇文章就來說明怎麼使用 Access Token 來存取 Private APIs。
OAuth 使用上最難懂以及測試的,莫過於這些 OAuth 的參數,尤其是在 OWASP 的 Web Security Report 之下,又有 Improper Error Handling 的安全漏洞問題,因此在測試 OAuth 時,最容易吃的苦頭就是只知道 HTTP 400 (Bad Request) 或 HTTP 401 (Unauthorized),有些服務還會提供一些錯誤訊息,但也有一點都不提供的,而且就算有提供,也不一定馬上就可以意識到問題在哪 (ex: Signature Invalid) … 往往都要做很多的實驗才能真正找到問題在哪,我在測試 Twitter 的 OAuth 時就吃了很多的苦頭… Orz。
資料結構 (data structure) 是資料的組成方式,資料可以是字串或是二進位資料 (binary data),組成方式則要看不同資料整理的需求,可以是分布在記憶體不同位置,然後用特定方法管理,或是以特別的格式排列組合,以達成有效率管理資料的方式,而一般程式設計人員接觸到最多的是資料結構,因為這會決定你在程式中處理資料的方式,簡單的資料當然可以用很簡單的結構來組織,但是如果在寫程式時不在乎資料結構的話,很容易發生寫出的程式效率低落的問題。
前面三篇文章,筆者說明了如何使用 C# 並配合 .NET Framework 來開發 ActiveX Control,相信只要有動手做的讀者現在應該都很快樂的在使用它吧,不過最近有一個新的需求出來:如何由 ActiveX Control 開放事件,並且由 JavaScript 依事件作反應。
本文會介紹如何使用 Reflection 來呼叫與存取類別中的泛型方法。
這個功能是在設計 Facebook Graph API Client Library 時碰到的問題,在 Graph API 中的 Publish_Stream 中有一項上傳相片的功能,這個功能內有一個 message 和 access_token 參數,而原本我們學習的 HTTP 技術本身大多都是沒有混合二進位和字串值的參數,所以當時碰到這個問題時,一時想不到什麼解決方法,後來搜尋到 RFC 2188: Returning Values from Forms: multipart/form-data,這份文件說明了在 HTTP POST 訊息中使用多種格式訊息的作法,它可以用在許多 REST-based API 的系統,它可以混合多種資料格式並一次傳送,當然非文字的資料必須要編碼為二進位字串。
這是筆者在 Plurk.net 開放原始碼專案後的第二個 Codeplex 開放原始碼專案,它會直接利用 Facebook 的 Graph API 介面與 Facebook 溝通,並在使用者給予的適當授權下,在使用者的塗鴉牆上張貼訊息,張貼文章,建立活動,上傳相片等等。
筆者在 ActiveX 控制項開發的封裝部署一文的最後,曾經提到 Windows XP 和 Windows Vista/7 的部署差異,這會讓開發人員需要依照作業系統的不同來撰寫 INF 檔案來自動化安裝,而且還要在網頁中偵測不同的作業系統給予不同的 CAB 檔案,但我們有一些方法來簡化這個部份的處理,讓開發人員可以在不動一行 <object> 宣告下,支援 Windows XP 和 Windows Vista/7 的作業系統環境。其實方法很簡單,只要使用 HTTP Handler 就能做到了。
本文將會把最後的程序給完成,當完成這個程序後,你就可以把你的控制項部署出去了。
本文將會開始以 C# 實作控制項,讓你可以有開發控制項的經驗。
本文會介紹 ActiveX Control 的背景知識,以及在 .NET 上開發 ActiveX Control 的基礎。
[VS2010] WCF 4.0 新功能 (4): 服務說明頁與錯誤處理
[VS2010] WCF 4.0 新功能 (3): 由 REST 服務中傳回自訂的格式
[VS2010] WCF 4.0 新功能:REST 服務開發
[VS2010] WCF 4.0 新功能 (1): 簡易組態 (Simple Configuration)
[VS2010] Visual Studio 2010 與 Windows Azure: 在 AppFabric Service Bus 上開發 REST 服務
[VS2010] .NET Framework 4.0 Client Profile
[VS2010] WPF 4.0 新功能:文字堆疊 (Text Stack) 的強化
[VS2010] Visual Studio 2010 與 Windows Azure: 將診斷與追踪資訊傳遞給 Windows Azure Storage 儲存體
[VS2010] 型別等價實例:在免部署 Office PIAs (Primary Interop Assemblies) 的情況下存取 Office 物件模型