您的位置:首頁>科技>正文

Windows平臺下介面程式設計技術

1.控制台介面

可滿足大多數循序執行、文本交互的程式的要求。 缺點是對國際字元的支援不是很好。

2.Win32對話方塊

可滿足一般的簡單圖形交互的工具程式的要求, 運行效率也比較高。 缺點是控制項太少。 且嵌入ActiveX控制項困難。 如果需要嵌入ActiveX控制項(如WebBrowser)可以考慮使用MFC或ATL對話方塊。 對於微型工具程式建議使用。

3.Win32框架視窗

可滿足簡單的單文檔、MDI多文檔, 功能表和固定式工具列程式設計, 需要更多功能的話需要自己手動實現, 並且嵌入ActiveX控制項困難。 僅學習使用。

4.Windows表單應用程式(Windows Forms)

既可滿足簡單的對話方塊式應用程式, 又可滿足複雜的單文檔、MDI多文檔、分割式視窗等功能。 如果需要停靠支援可以使用AvalonDock等外掛程式實現。 集成於.NET框架。

5.WPF

和Windows Forms類似, 但使用XAML設計, 使用DirectX作為渲染引擎, 原生解析度無關渲染, 無縫支持高分屏, 並且按視覺化元素而不是子視窗渲染, 設計比Windows Forms靈活,

適合於編寫介面華麗的應用程式。 缺點是記憶體佔用比Windows Forms大得多, 並且不跨平臺。 集成於.NET 3.0+框架。

6.UWP

和WPF類似, 不過由於來自Windows 8應用框架視窗化而來, 所以它以Page而不是Window為單位(也可以新建視窗, 但比較麻煩), 並且風格更加觸摸化。 目前只有Windows 10才能支持UWP。

7.Qt[協力廠商]

和WPF類似,

但使用OpenGL渲染, 使用C++或QML設計。 它使用C++編寫, 效率比WPF高一些。 如果不調用平臺相關的WinAPI的話, 還可以跨平臺。 適合任何類型的程式。 目前使用LGPL和商業雙重協定。

8.GTK+[協力廠商]

和Qt類似, 但是支援使用C語言編寫。 不過內部使用UTF-8而不是UTF-16編碼, 在Windows平臺下使用起來有點麻煩。 適合任何類型的程式。 目前使用LGPL協定。

9.wxWidgets[協力廠商]

差不多是MFC的改進版, 但是跨平臺, 可編譯為Win32、GTK+、Qt等底層實現。 適合任何類型的程式。 目前使用wxWindows協定。

10.MFC框架窗口

可滿足複雜的單文檔、MDI多文檔、懸浮式工具列、分割式視窗、選項卡式文檔、多頂級文檔、多側邊欄等介面, 但是必須使用它的文檔-視圖框架, 不使用此框架則不能享受某些功能。 缺點是限制太多, 並且不是視覺化設計, 而且不跨平臺。

不建議使用。 目前使用MS-PL協定。

11.WTL

基於ATL對WinAPI羽量級包裝的類庫, 很多東西還得調用WinAPI。 沒有文檔和技術支援。 強烈不建議使用。 目前使用MS-PL協定。

12.DUILIB[協力廠商]

使用GDI+自繪控制項的介面庫, 適合編寫華麗的介面。 但由於授權協議的關係, 後來被各大流氓軟體廠商fork然後私有化了, 現在基本已停止更新。 缺點是目前為止官方版本不支援高分屏, 且沒有文檔和技術支援。 強烈不建議使用。 目前使用MIT協定。

一般來說, 程式沒必要使用WinAPI編寫, 太麻煩了。

如果可以接受.NET框架的話(一般是應用軟體和一般的工具軟體)——

如果可以接受.NET框架, 要完全原生的體驗, 用Windows Forms。

如果可以接受.NET框架, 記憶體足夠大, 想把介面做得華麗一些, 用WPF。

如果不能接受.NET框架的話(一般是運行環境特殊的工具軟體或跨平臺軟體)——

如果不能接受.NET框架, 介面要求原生的體驗, 用wxWidgets。

如果不能接受.NET框架, 想把介面做得華麗一些, 用Qt。

如果不能接受.NET框架, 也不能接受C++的話, 用GTK+。

如果不能接受.NET或其它的框架, 只需要非常簡單的GUI介面的話, 用Win32對話方塊。

如果不能接受.NET或其它的框架,而且不需要GUI介面的話,用控制台程式。

如果不能接受.NET或其它的框架,而且不需要GUI介面的話,用控制台程式。

Next Article
喜欢就按个赞吧!!!
点击关闭提示