C++

在windows環境下上網時，你有沒有注意到在螢幕的右下腳的工作列上有一個動畫表徵圖呢？它一閃一閃的，形象的表示出網路此時正在傳輸資料。關於工作列表徵圖編程的文章有不少，可是如何才能編製出動態表徵圖呢？在C++Builder中可以比較方便的實現。其基本編程思路是：通過設定Timer時鐘控制項使應用程式在規定的時間間隔內發送特定的訊息，使工作列表徵圖不斷更改，從而形成動畫效果。實現方法為在應用程式的表單中載入幾個Image控制項，使他們裝載相應的圖畫，幾幅圖畫按順序連續的被顯示，就形成了動畫。在這

Windows中的拖放功能大家一定很熟悉了，如檔案的轉移，拷貝等操作用滑鼠輕輕一拖即可，在編寫程式中有時也用到拖放，那麼如何?呢？現以C++ Builder5（簡稱CB5）為例，分析拖放功能的具體實現。一．工具條的拖放---- 要實現拖放功能，首先必須瞭解幾個與拖放有關的屬性和方法， 對於TControl控制項，CB5提供了三個屬性，DockSite，DragKind和DragMode。靈活運用這三個屬性會得到意想不到的效果。這三個屬性的意義是：----

熟悉Windows作業系統的軟體設計人員知道，在Win95/98/NT/2000中有一工作列（Task Bar）程式，路徑為：C:\WINDOWS\SYSTEM\SYSTRAY.EXE（假設你的Windows安裝在系統預設路徑C:\WINDOWS）。從系統功能角度分析，工作列由幾個不同的子領域組成，從左至右依次是：開始（Start）按鈕、應用程式切換區（Application Switch Bar）、工作列通知區（Notification

雖然Win95下可視化開發工具如VC、Delphi、C++ Builder等都有專用的定時器控制項Timer，而且使用很方便，可以實現一定的定時功能，但最小計時精度僅為55ms，且定時器訊息在多任務作業系統中的優先順序很低，不能得到及時響應，往往不能滿足即時控制環境下的應用。不過Microsoft公司在Win32 API函數庫中已經為使用者提供了一組用於高精度計時的底層函數，如果使用者使用得當，計時精度可到1ms。這個計時精度、對於一般的即時系統控制完全可以滿足要求。現將由C＋＋

Tray(托盤)是Windows9x任務條上的一個特殊地區，它的技術名稱為“工作列布告區”，一些軟體(如金山詞霸Ⅲ)運行時會在托盤上放置一個表徵圖，使使用者一眼就能知道這個程式正在後台運行，要想啟用它也很容易，通常只需單擊一下這個表徵圖即可，非常方便。Tray的編程比較特殊，但並不難，主要包括表徵圖、工具提示和訊息等三個方面，它是Shell編程的一部分。ShellAPI提供了Shell—NotifyIcon函數，用它可以增加、刪除或者修改托盤中的表徵圖，在托盤

摘要：本文通過一個具體的程式示範了Windows下的螢幕保護裝置程式的實現過程。一． 引言視窗系統下的螢幕保護裝置程式是一個基於命令列（Command

首先建立一個工程檔案(File->New Application)。然後在Form1上面建立一個PopupMenu1,一個Button1,一個RichEdit1。在頭文Unit1.H的內容，其中黑體是自已加的。#ifndef Unit1H#define Unit1H#include#include#include#include#include#include#includeclass TForm1 : public TForm{__published: // IDE-managed

MDI（多重文件介面）應用程式是指使用者可以同時開啟多個文檔，每一個文檔顯示在應用程式主視窗客戶區的獨立視窗中。如文書處理程式Word就是一個典型的MDI應用程式，你可以在Word中同時開啟和使用多個文檔，PowerPoint中你也可以同時建立和開啟多個投影片應用程式，試算表中也允許使用者同時對多個圖表進行編輯。MDI應用程式一般包括三類視窗：*

一、ISAPI概述 Microsoft的WEB伺服器提供了不同的ISAPI，應用ISAPI能夠開發出高效能的應用程式。ISAPI具有兩類組件：ISAPI擴充和ISAPI過濾器，本文著重介紹ISAPI擴充的應用和開發。ISAPI應用程式通過DLL實現，DLL的特性使它能夠作為WEB伺服器自身的擴充來裝載。在WEB伺服器的地址空間運行， 而且只在第一次請求時裝載一次，以後每一個後續請求通過建立一個線程(僅用一個簡單的函數調用) 來完成，這比CGI建立一個進程要節約大量

---- 由於Window 95增加了對視窗地區概念的支援，使得視窗地區就是所定義的視窗看上去的形狀，視窗地區作為視窗的實際邊界地區，這樣視窗地區不僅定義了視窗的可畫地區，而且定義了視窗下隱含地區和響應滑鼠擊鍵事件的響應視窗地區。---- 按鈕的各種形狀是在運行時設定的而不是在設計時設定。設計時按鈕的形狀仍然是長方形或正方形。---- 按鈕形狀的設計分成兩個步驟。----

Borland C＋＋ Builder是基於C＋＋語言的可視化編程環境，它提供了可重用組件庫和一系列RAD設計工具，使得編程者只需用少量的手工代碼就可以建立出高效的Windows應用程式，尤其是複雜的資料庫訪問應用程式，因此深受軟體開發人員的喜愛。在開發資料庫訪問應用程式時，會經常涉及到報表的列印問題。C＋＋ Builder中提供了Quick Report(快速報表)組件供編程人員設計報表。Quick Report是挪威的QuSoft AS公司專門為C＋＋

引言台屏的操作是控制實現的常規操作，但是由於台屏本身固有的原因，存在一些問題，如：成本高，易損壞，維修難等。所以電腦虛擬台屏已經成為合適的替代品。在模擬領域，台屏的電腦虛擬更成為較好的一種方法。在電腦虛擬台屏的軟體編製中，由於台屏的特殊性，使軟體的編製存在一些相應的痛點，如台屏映像的縮放、漫遊、旋轉等。C++ Builder是基於Windows進行可視化C語言開發的最好的技術平台之一。利用C++ Builder提供的基本組件，結合Windows SDK（Software Development

用過C++進行過物件導向程式設計的使用者都知道，程式中的對象很少單獨存在。不考慮對象間的相互作用幾乎是不可能的。所以，標識對象間的關係或建立對象間的訊息串連是物件導向程式設計的一項重要任務。本文著重從C++程式設計的角度，提出一種建立對象間訊息串連的實用方法。如果你想詳細瞭解物件導向程式設計技術，請參閱有關專著。大家都知道對象是資料和方法的封裝體。在C++中，它們分別表現為資料成員和成員函數。程式設計者通過執行對象的各種方法，來改變對象的狀態（即改變對象的屬性資料）。從而使該對象發生某些&ldq

從internet下載較大的軟體時，由於目前網路頻寬的原因，許多人喜歡在晚間進行，而到深夜時就存在人需要休息的問題。目前絕大多數下載軟體可以估算出下載所需的時間，如果到時讓電腦自動關機，就可以免受守候之苦。本文介紹筆者用c＋＋ builder

動態庫連結到應用程式中主要有兩種方式：隱式連結和顯式連結。隱式連結是常用方式。如果應用程式和動態庫是分別在不同開發平台上編製的，動態庫的匯入庫（lib檔案）可能會與應用程式的開發平台所要求的匯入庫格式不相容，從而在應用程式與動態庫隱式連結時，出現程式連結錯誤：contains invalid OMF record。例如在C++Builder開發平台上連結Visual

通常在應用程式的主表單中，利用滑鼠左鍵點擊左上方的表徵圖，會彈出一個菜單，稱之為“系統功能表”。在表單中並沒有系統功能表對應的組件，所以有時我們需要定製系統功能表時就比較麻煩。具體可以能過下面的步驟實現：.在系統功能表上添加所需的功能表項目。.為新添加的功能表項目定義OnClick事件的處理過程。下面的常式中，在系統功能表中添加了一個“最上層顯示（A）”功能表項目，通過該功能表項目，可以使表單始終顯示在最前端或為普通表單模式。具體實現過程如下：1）

Windows 95/98的啟動模式可以分為正常模式和安全模式，在安全模式下，有很多功能被限制使用，比如多媒體功能、網路功能等。有時，我們編寫的程式正好需要這些被限制的功能，因此我們希望當程式運行時能自動檢測當前Windows所處的啟動模式是不是安全模式，以確定是否繼續運行程式。那麼如何在C++

一,HINSTANCE g_hinstDll = NULL;HHOOK g_hhook　　　= NULL;HWND　g_hwndPost　= NULL;UINT　g_uMsgNotify = WM_USER;HOOKPROC KeyboardHook_HookProc ( int nCode, WPARAM wParam, LPARAM lParam){　 LRESULT lResult = CallNextHookEx(g_hhook, nCode, wParam, lParam);　 if

我們在《設計模式之觀察者(Observer)模式與其C++通用實現（中）》一文中給出了一個以C++語言實現的通用觀察者模式方案骨架。然而，實際的工程項目需求往往要比理想狀態複雜得多，此篇便是與讀者一起探討在現實世界中可能遇到的各種棘手問題及解決方案。我把目前為止我所遇到的問題羅列如下：複合主題多線程更新方法修改觀察者鏈表接下來我們一一給予討論。（一）複合主題考慮GUI的組件設計，我習慣用Widget類代表之，它需要處理許多使用者互動以及系統事件，其中最常見的使用者互動事件有滑鼠及鍵盤事件。倘若架

通過上篇的介紹我們知道了觀察者模式的基本特點、使用場合以及如何以C++語言實現。有過多次編寫觀察者模式代碼經驗的你也許會發現，幾乎所有的案例存在為數相當可觀的重複性代碼：定義一個觀察者介面；定義一個主題並實現其諸如註冊一/多個觀察者，移除一/多個觀察者，廣播至所註冊的觀察者等基本行為。既然如此，我們有沒有可能為所有觀察者模式抽象出共有的介面與行為，以便日後複用呢？此篇文章便是探討如何?一個通用或稱為萬能的觀察者模式庫。我們為所有的觀察者/訂閱者抽象出一個共有的介面IObserver:struct