目前分類:wxWidgets (10)

瀏覽方式: 標題列表 簡短摘要

1. 先看這篇來建立基本的 wxWidgets 開發環境。

2. 到 wxSQLite3 下載頁下載套件。截至這篇文章為止,使用的版本是 1.9.3(支援 SQLite 3.6.7)。

3. 到系統去新增環境變數 WXWIN,值就是安裝 wxWidgets 的地方。以這裡為例,是 C:\wxWidgets-2.8.9。

zxlin 發表在 痞客邦 PIXNET 留言(0) 人氣()

1. 到 Visual Studio Express Edition 下載頁,點選最下面 Offline ,下載映像檔。截至此篇文章,使用版本是 Visual Studio 2008 Express Edition SP1。

2. 到 wxWidgets 下載頁,選則頁面中間 wxMSW 下載安裝檔,截至此篇文章,版本是 2.8.9。

3. 到 DialogBlocks 下載頁,下載 for Windows (Unicode) 版本,截至此篇文章,版本是 4.28。

zxlin 發表在 痞客邦 PIXNET 留言(0) 人氣()

微軟推出 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 的組合使用是不錯的。其實只有兩個問題要解決:

1. 編譯出來的程式拿到其他電腦執行時,可能會遇到缺少 DLL 的問題

zxlin 發表在 痞客邦 PIXNET 留言(0) 人氣()

wxGTK-2.8.8 中,預設是 --enable-unicode,但是很奇怪的,configure --enable-unicode 之後,在 setup.h 裡面並不會
#define HAVE_WCSTOULL,結果導致使用 wxString 中的 ToLongLong 一直沒辦法法轉成 64 bits 的長整數。但是如
果是以 configure --disable-unicode,則 #define HAVE_STRTOULL。

zxlin 發表在 痞客邦 PIXNET 留言(0) 人氣()

最近在用 wxWizard 寫那種下一步下一步的精靈,結果…

如果在 wxWizard 的頁面中,加入一個 wxStaticText,裡面填入一串很長很長的文字,

zxlin 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天新出爐的 SOP,參考看看。

1. 加入 wxWidgets Libraries 及 Code::Blocks 套件庫:

zxlin 發表在 痞客邦 PIXNET 留言(5) 人氣()

之前才提到,使用 Microsoft Visual C++ 2005 Express Edition 會有缺少函式庫的不明原因。昨天試了一下,其實只要在編譯 wxWidgets 時,加入 RUNTIME_LIBS=static 的選項,讓 runtime linking 的模式改為 static 就可以解決這個問題了。

不過要注意的是,當編譯 wxWidgets 使用 RUNTIME_LIBS=static 這個選項時,後續編譯應用程式時的編譯器選項要加入 /MT;當編譯 wxWidgets 使用 RUNTIME_LIBS=dynamic 這個選項時,後續編譯應用程式時的編譯器選項要加入 /MD。

zxlin 發表在 痞客邦 PIXNET 留言(0) 人氣()

這些天又開始正事不做,專做五四三的東西。說真的,這些五四三的進度都比老闆要的進度來的超前。既然五四三做的有心得,那還是不要白費了這些進度,就寫下來好了。

wxWidgets 真的是令人驚豔的一套函式庫。說它是跨平台的 MFC 也不為過,雖然是類似 MFC,不管在整體架構或是一些特性(諸如 event table、event macro 等一些機制)上來看,它還是有比 MFC 獨到的地方。所以儘管常拿來比較,兩者還是各有所長吧!

zxlin 發表在 痞客邦 PIXNET 留言(2) 人氣()

印象中應該是來花蓮之後,才接觸到 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 的組合,這時的 Code::Blocks 就成功的扮演了最關鍵的角色!

zxlin 發表在 痞客邦 PIXNET 留言(0) 人氣()

在明道最後一個學期,跑去修了小石的視窗程式,原本是以為使用 MFC 來架構,後來才發現絕大部份是使用 Win32 API 在撰寫。不過這沒有什麼好壞對錯,了解底層的內容或多或少對於使用上層的架構有所幫助。

來到花蓮之後,研究論文時在實作上,總有些時候會寫些小程式來應用,雖然說界面不是程式的重點(張小新以往重是告誡,別被華麗的外表給騙了──好好把程式最核心的部份寫好──才是最重要的),但有些時候如果有 GUI,總是順手一點。

zxlin 發表在 痞客邦 PIXNET 留言(0) 人氣()

找更多相關文章與討論