FAX_RECEIVE 結構 (faxdev.h)
FAX_RECEIVE結構包含輸入傳真檔的相關資訊。 此資訊包括將接收傳真資料流程的檔案名,以及接收裝置的名稱和電話號碼。
語法
typedef struct _FAX_RECEIVE {
DWORD SizeOfStruct;
LPWSTR FileName;
LPWSTR ReceiverName;
LPWSTR ReceiverNumber;
DWORD Reserved[4];
} FAX_RECEIVE, *PFAX_RECEIVE;
成員
SizeOfStruct
類型: DWORD
指定 FAX_RECEIVE 結構的大小,以位元組為單位。 呼叫 FaxDevReceive 函式之前,傳真服務會將此成員設定為 sizeof (FAX_RECEIVE) 。 如需詳細資訊,請參閱接下來的<備註>一節。
FileName
類型: LPWSTR
Null 終止 Unicode 字元字串的指標,指定 FSP 必須儲存輸入傳真檔資料流程之檔案的完整路徑。 資料流程是 TIFF 類別 F 檔案。 如需詳細資訊,請參閱 傳真影像格式。 傳真服務會在呼叫 FaxDevReceive 函式之前建立檔案。 FSP 必須在開啟此檔案時指定OPEN_EXISTING旗標。
ReceiverName
類型: LPWSTR
指定接收裝置名稱之 Null 終止 Unicode 字元字串的指標。 FSP 會在接收裝置收到輸入傳真之後,將名稱傳送至遠端傳送裝置。 如需詳細資訊,請參閱接下來的<備註>一節。
ReceiverNumber
類型: LPWSTR
指定接收裝置電話號碼的 Null 終止 Unicode 字元字串指標。 FSP 會在接收裝置收到輸入傳真之後,將號碼傳送至遠端傳送裝置。 如需詳細資訊,請參閱接下來的<備註>一節。
Reserved[4]
類型: DWORD
此成員保留供 Microsoft 未來使用。 它必須設定為零。
備註
FSP 必須在此結構中設定 ReceiverName 和 ReceiverNumber 成員。 傳真服務會為這些字串配置記憶體。 服務配置的記憶體大小等於 大小of (FAX_RECEIVE) + FAXDEVRECEIVE_SIZE。 FSP 必須將字串放在 FAX_RECEIVE 結構的記憶體 區塊中。 請注意,您必須允許緊接在FAX_RECEIVE結構之後的FileName字串大小。 ReceiverName和ReceiverNumber成員必須指向記憶體區塊中字串的位置。
下列程式碼範例和圖表說明如何填入傳真服務配置的記憶體。
PWSTR ReceiverName;
PWSTR ReceiverNumber;
//
// Routine to retrieve the receiver name
// and receiver number here.
//
// Set the receiver name and receiver number data
// in the FAX_RECEIVE structure; then
// copy the data to the appropriate offset.
//
FaxReceive->ReceiverNumber = (LPWSTR) ( (LPBYTE)FaxReceive->FileName + sizeof(WCHAR)*(wcslen(FaxReceive->FileName) + 1));
wcscpy_s( FaxReceive->ReceiverNumber, ReceiverNumber );
FaxReceive->ReceiverName = (LPWSTR) ( (LPBYTE)FaxReceive->ReceiverNumber+ sizeof(WCHAR)*(wcslen(FaxReceive->ReceiverNumber) + 1));
wcscpy_s( FaxReceive->ReceiverName, ReceiverName );
FSP 可以將 ReceiverName 和 ReceiverNumber 成員重新格式化,並將重新格式化的資料傳輸至遠端傳送裝置,作為名為訂閱者識別碼 (CSI) ,以符合來自研究群組 8 (SG8) 之國際電信聯盟 () 標準主體的建議。 如需詳細資訊,請參閱FAX_DEV_STATUS結構的RoutingInfo和CSI成員。
需求
最低支援的用戶端 | Windows 2000 專業版、Windows XP [僅限傳統型應用程式] |
最低支援的伺服器 | Windows Server 2003 [僅限傳統型應用程式] |
標頭 | faxdev.h |
另請參閱
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應