1. 先看這篇來建立基本的 wxWidgets 開發環境。
2. 到 wxSQLite3 下載頁下載套件。截至這篇文章為止，使用的版本是 1.9.3（支援 SQLite 3.6.7）。
2. 到 wxSQLite3 下載頁下載套件。截至這篇文章為止，使用的版本是 1.9.3（支援 SQLite 3.6.7）。
- 1月 05 週一 200917:56
wxSQLite3 的編譯與使用
- 1月 04 週日 200917:22
Visual C++ 2008 Express Edition + wxWidgets + DialogBlocks
1. 到 Visual Studio Express Edition 下載頁，點選最下面 Offline ，下載映像檔。截至此篇文章，使用版本是 Visual Studio 2008 Express Edition SP1。
2. 到 wxWidgets 下載頁，選則頁面中間 wxMSW 下載安裝檔，截至此篇文章，版本是 2.8.9。
2. 到 wxWidgets 下載頁，選則頁面中間 wxMSW 下載安裝檔，截至此篇文章，版本是 2.8.9。
- 1月 04 週日 200914:48
Visual Studio 2008 Express Edition
微軟推出 Visual Studio 2008 Express Edition 之後（正確來說，含 SP1），在去年底抓下來試試看。比較起 Visual Studio 2005 Express Edition，它把 Platform SDK 也包進來了，而且離線安裝的版本就是一個映像檔，抓下來就可以裝 Visual C++，Visual Basic 跟 Visual C#，算是很方便了。也因此，很久沒在 Windows 上寫 wxWidgets 的程式了，最近想些東西，因此就拿 wxWidgets-2.8.9 + Visual Studio 2008 Express Edition + DialogBlocks 4.28 這樣子的組合來玩。
DialogBlocks 4.28 已經支援 Visual Studio 2008 Express C++ ，因此在偵測環境上都不是問題，也可以順利的編出函式庫。根據wxWidgets的完美伴侶以及wxWidgets的完美伴侶（2），Visual Studio Express Edition 跟 wxWidgets 的組合使用是不錯的。其實只有兩個問題要解決：
DialogBlocks 4.28 已經支援 Visual Studio 2008 Express C++ ，因此在偵測環境上都不是問題，也可以順利的編出函式庫。根據wxWidgets的完美伴侶以及wxWidgets的完美伴侶（2），Visual Studio Express Edition 跟 wxWidgets 的組合使用是不錯的。其實只有兩個問題要解決：
- 10月 06 週一 200814:03
wxGTK-2.8.8 中 wxString ToLongLong 的 bug
wxGTK-2.8.8 中，預設是 --enable-unicode，但是很奇怪的，configure --enable-unicode 之後，在 setup.h 裡面並不會
#define HAVE_WCSTOULL，結果導致使用 wxString 中的 ToLongLong 一直沒辦法法轉成 64 bits 的長整數。但是如
果是以 configure --disable-unicode，則 #define HAVE_STRTOULL。
結果呢，不管是 ansi build 或是 unicode build，底層都呼叫了 strtoll 及 strtoull 來做 64 bits 的長整數轉換。但是 unicode
實際上要用的是寬字元的 wcstoll 及 wcstoull，因此，在 unicode build 的情形下，使用了 strtoll 及 strtoull 是沒有辦法正確
的轉換成長長整數。
#define HAVE_WCSTOULL，結果導致使用 wxString 中的 ToLongLong 一直沒辦法法轉成 64 bits 的長整數。但是如
果是以 configure --disable-unicode，則 #define HAVE_STRTOULL。
結果呢，不管是 ansi build 或是 unicode build，底層都呼叫了 strtoll 及 strtoull 來做 64 bits 的長整數轉換。但是 unicode
實際上要用的是寬字元的 wcstoll 及 wcstoull，因此，在 unicode build 的情形下，使用了 strtoll 及 strtoull 是沒有辦法正確
的轉換成長長整數。
- 9月 12 週五 200817:13
wxWizard Sizer bug ?
最近在用 wxWizard 寫那種下一步下一步的精靈，結果…
如果在 wxWizard 的頁面中，加入一個 wxStaticText，裡面填入一串很長很長的文字，
一般而言，它是會自己斷行的，但是 wxWizard 並不會，而且這時候去拖拉調整視窗大小的話，
就出現 exception 了。
在 wxWidgets 的討論區上已有人提出這樣子的問題了，似乎是 wxSizer 或是 wxBoxSizer 的問題，
但似乎尚未有解？
如果在 wxWizard 的頁面中，加入一個 wxStaticText，裡面填入一串很長很長的文字，
一般而言，它是會自己斷行的，但是 wxWizard 並不會，而且這時候去拖拉調整視窗大小的話，
就出現 exception 了。
在 wxWidgets 的討論區上已有人提出這樣子的問題了，似乎是 wxSizer 或是 wxBoxSizer 的問題，
但似乎尚未有解？
- 1月 23 週三 200816:55
在 Ubuntu 底下安裝 Code::Blocks
今天新出爐的 SOP，參考看看。
1. 加入 wxWidgets Libraries 及 Code::Blocks 套件庫：
$ sudo vi /etc/apt/sources.list
加入底下兩行：
1. 加入 wxWidgets Libraries 及 Code::Blocks 套件庫：
加入底下兩行：
- 1月 12 週五 200711:13
wxWidgets 的完美伴侶（2）
之前才提到，使用 Microsoft Visual C++ 2005 Express Edition 會有缺少函式庫的不明原因。昨天試了一下，其實只要在編譯 wxWidgets 時，加入 RUNTIME_LIBS=static 的選項，讓 runtime linking 的模式改為 static 就可以解決這個問題了。
不過要注意的是，當編譯 wxWidgets 使用 RUNTIME_LIBS=static 這個選項時，後續編譯應用程式時的編譯器選項要加入 /MT；當編譯 wxWidgets 使用 RUNTIME_LIBS=dynamic 這個選項時，後續編譯應用程式時的編譯器選項要加入 /MD。
Runtime linking 使用 static 與 dynamic 的差異性就不在此討論。不過使用 static 的方式對我目前倒是比較方便，省去了缺少函式庫的風險。另一個比較顯著的影響就是執行檔的檔案大小。用同樣的程式碼編譯，當 Runtime linking 為 dynamic，得到的執行檔為 1,466,368 位元組，用 upx --best 壓縮過之後則是 504,320 位元組；當 Runtime linking 為 static，得到的執行檔為 1,646,592 位元組，用 upx --best 壓縮過之後則是 592,896 位元組。
雖然兩種方式得到的執行檔大小有差，但是比較使用 mingw-3.4.5 得到的執行檔大小來講，算是小蠻多的了。目前使用 Microsoft Visual C++ 2005 Express Edition 還算正常，它會成為 wxWidgets 的好伙伴嗎？期待中！
不過要注意的是，當編譯 wxWidgets 使用 RUNTIME_LIBS=static 這個選項時，後續編譯應用程式時的編譯器選項要加入 /MT；當編譯 wxWidgets 使用 RUNTIME_LIBS=dynamic 這個選項時，後續編譯應用程式時的編譯器選項要加入 /MD。
Runtime linking 使用 static 與 dynamic 的差異性就不在此討論。不過使用 static 的方式對我目前倒是比較方便，省去了缺少函式庫的風險。另一個比較顯著的影響就是執行檔的檔案大小。用同樣的程式碼編譯，當 Runtime linking 為 dynamic，得到的執行檔為 1,466,368 位元組，用 upx --best 壓縮過之後則是 504,320 位元組；當 Runtime linking 為 static，得到的執行檔為 1,646,592 位元組，用 upx --best 壓縮過之後則是 592,896 位元組。
雖然兩種方式得到的執行檔大小有差，但是比較使用 mingw-3.4.5 得到的執行檔大小來講，算是小蠻多的了。目前使用 Microsoft Visual C++ 2005 Express Edition 還算正常，它會成為 wxWidgets 的好伙伴嗎？期待中！
- 1月 11 週四 200717:33
wxWidgets 的完美伴侶
這些天又開始正事不做，專做五四三的東西。說真的，這些五四三的進度都比老闆要的進度來的超前。既然五四三做的有心得，那還是不要白費了這些進度，就寫下來好了。
wxWidgets 真的是令人驚豔的一套函式庫。說它是跨平台的 MFC 也不為過，雖然是類似 MFC，不管在整體架構或是一些特性（諸如 event table、event macro 等一些機制）上來看，它還是有比 MFC 獨到的地方。所以儘管常拿來比較，兩者還是各有所長吧！
但是呢，畢竟它是 Open Source 的函式庫，並沒有商業公司在維護發展，而且它本身只是一套函式庫，導致，要找一套好用的整合發展環境，甚至是加上可以拖拉開發的快速發展工具還真的不好找。並不是沒有，而是全功能，又是自由軟體的，用上手的，還真的找不太到。
這些資源就不再多做敘述，在 wxWidgets Wiki 都有相關的資訊。我個人習慣用 DialogBlocks 這套商業的快速發展工具。它有 Demo 版本可以使用，當然有些限制，比如說，不定時的提醒要註冊，每一個 Dialog/Frame 最多只能有 30 個控制項。如果程式沒寫很大的話，用它來做 layout 及 coding 倒是還好。但是它的編輯器真的不太好用，我又習慣用 Code::Blocks。但是 Code::Blocks 不好做 UI 的 layout，因此我就用兩個搭配。
找到了 Code::Blocks 及 DialogBlocks 之後，因為這兩套都不含編譯器，因此要自己另外安裝編譯器。而這也是令人驚豔的地方～兩者可以搭配各種的編譯器。最早我使用 mingw，畢竟是完完全全的自由軟體，而且也發展有段時日了，穩定性有一定程度，可以放心的使用了。但是它的編譯速度慢，所產生的執行檔案較大，是讓人覺得可惜的地方。因此一直想找另一個編譯器來試。
wxWidgets 真的是令人驚豔的一套函式庫。說它是跨平台的 MFC 也不為過，雖然是類似 MFC，不管在整體架構或是一些特性（諸如 event table、event macro 等一些機制）上來看，它還是有比 MFC 獨到的地方。所以儘管常拿來比較，兩者還是各有所長吧！
但是呢，畢竟它是 Open Source 的函式庫，並沒有商業公司在維護發展，而且它本身只是一套函式庫，導致，要找一套好用的整合發展環境，甚至是加上可以拖拉開發的快速發展工具還真的不好找。並不是沒有，而是全功能，又是自由軟體的，用上手的，還真的找不太到。
這些資源就不再多做敘述，在 wxWidgets Wiki 都有相關的資訊。我個人習慣用 DialogBlocks 這套商業的快速發展工具。它有 Demo 版本可以使用，當然有些限制，比如說，不定時的提醒要註冊，每一個 Dialog/Frame 最多只能有 30 個控制項。如果程式沒寫很大的話，用它來做 layout 及 coding 倒是還好。但是它的編輯器真的不太好用，我又習慣用 Code::Blocks。但是 Code::Blocks 不好做 UI 的 layout，因此我就用兩個搭配。
找到了 Code::Blocks 及 DialogBlocks 之後，因為這兩套都不含編譯器，因此要自己另外安裝編譯器。而這也是令人驚豔的地方～兩者可以搭配各種的編譯器。最早我使用 mingw，畢竟是完完全全的自由軟體，而且也發展有段時日了，穩定性有一定程度，可以放心的使用了。但是它的編譯速度慢，所產生的執行檔案較大，是讓人覺得可惜的地方。因此一直想找另一個編譯器來試。
- 11月 01 週三 200622:25
令人驚豔的 Code::Blocks
印象中應該是來花蓮之後，才接觸到 Code::Blocks 這個好用的 IDE。不過那時的 Code::Blocks 才剛開始發展，有許多功能不足及 bug ，因為它是一個功能強大的 C/C++ 整合開發環境，在後來 C/C++ 愈寫愈少的情形下，逐漸淡忘了它。
最近又開始寫著程式，有經理的 winsock 程式要寫，小許的密碼學也要實作，自己的 WSN 也要寫模擬程式，在用來用去各 IDE 之後，都不太順手。其實並非不順手，只是 Code::Blocks 的一些功能讓我無法忘懷～比如說，它有個「Source code formatter」的外掛，讓我不管拿到什麼樣縮排（甚至是沒有縮排的程式），都能馬上排成我習慣的縮排方式。又它支援多種編譯器，也是為人津津樂道的事。以前用習慣了 Visual C++ 6.0，後來覺得不能對它產生依賴（講白了，名不正言不順啊！），因此改用了 Mingw，但是因為開始寫 wxWidget 的程式，發現 Mingw 在編譯速度有點慢，產生的執行檔稍為大了點的情形下，便嚐試使用 Visual C++ 2005 Express Edition + Microsoft Platform SDK for Windows Server 2003
最近又開始寫著程式，有經理的 winsock 程式要寫，小許的密碼學也要實作，自己的 WSN 也要寫模擬程式，在用來用去各 IDE 之後，都不太順手。其實並非不順手，只是 Code::Blocks 的一些功能讓我無法忘懷～比如說，它有個「Source code formatter」的外掛，讓我不管拿到什麼樣縮排（甚至是沒有縮排的程式），都能馬上排成我習慣的縮排方式。又它支援多種編譯器，也是為人津津樂道的事。以前用習慣了 Visual C++ 6.0，後來覺得不能對它產生依賴（講白了，名不正言不順啊！），因此改用了 Mingw，但是因為開始寫 wxWidget 的程式，發現 Mingw 在編譯速度有點慢，產生的執行檔稍為大了點的情形下，便嚐試使用 Visual C++ 2005 Express Edition + Microsoft Platform SDK for Windows Server 2003
- 4月 16 週日 200600:02
Window Programming
在明道最後一個學期，跑去修了小石的視窗程式，原本是以為使用 MFC 來架構，後來才發現絕大部份是使用 Win32 API 在撰寫。不過這沒有什麼好壞對錯，了解底層的內容或多或少對於使用上層的架構有所幫助。
來到花蓮之後，研究論文時在實作上，總有些時候會寫些小程式來應用，雖然說界面不是程式的重點（張小新以往重是告誡，別被華麗的外表給騙了──好好把程式最核心的部份寫好──才是最重要的），但有些時候如果有 GUI，總是順手一點。
找過不少關於跨平台的函式庫，在此不提 JAVA，以常見的這三種，我選擇摸索 wxWidgets。剛好看到 PCMAN 大大這篇文章，借來用一下！ :p
######################################
之前因為把 MFC 痛罵了一頓，有網友在詢問其他 GUI toolkit
來到花蓮之後，研究論文時在實作上，總有些時候會寫些小程式來應用，雖然說界面不是程式的重點（張小新以往重是告誡，別被華麗的外表給騙了──好好把程式最核心的部份寫好──才是最重要的），但有些時候如果有 GUI，總是順手一點。
找過不少關於跨平台的函式庫，在此不提 JAVA，以常見的這三種，我選擇摸索 wxWidgets。剛好看到 PCMAN 大大這篇文章，借來用一下！ :p
######################################
之前因為把 MFC 痛罵了一頓，有網友在詢問其他 GUI toolkit
1
資訊技術 (4)