IWiaTransferCallback::GetNextStream-Methode

Ruft einen neuen Stream für das angegebene Element ab.

Syntax

HRESULT GetNextStream(
  [in]  LONG    lFlags,
  [in]  BSTR    bstrItemName,
  [in]  BSTR    bstrFullItemName,
  [out] IStream **ppDestination
);

Parameter

lFlags [in]

Typ: LONG

Derzeit nicht verwendet. Sollte auf Null festgelegt werden.

bstrItemName [in]

Typ: BSTR

Gibt den Namen des Elements an, für das der Stream erstellt werden soll.

bstrFullItemName [in]

Typ: BSTR

Gibt den vollständigen Namen des Elements an, für das der Stream erstellt werden soll.

ppDestination [out]

Typ: IStream**

Empfängt die Adresse eines Zeigers auf das neue IStream-Objekt .

Rückgabewert

Typ: HRESULT

Wenn diese Methode erfolgreich ist, gibt sie S_OK zurück. Andernfalls wird ein HRESULT-Fehlercode zurückgegeben.

Bemerkungen

Wenn diese Methode durch einen Bildverarbeitungsfilter implementiert wird, ruft der Windows Image Acquisition 2.0-Minidriver sie während der Bilderfassung auf, um den Zieldatenstrom vom Client abzurufen.

Die IWiaTransferCallback::GetNextStream eines Filters muss an die Rückrufmethode der Anwendung delegieren. Der Filter verwendet den Stream, der von der IWiaTransferCallback::GetNextStream-Implementierung des Anwendungsrückrufs zurückgegeben wird, um einen eigenen Stream zu erstellen, den er an den WIA 2.0-Dienst zurückgibt. Die Filterung erfolgt, wenn der Stream des Filters die IStream::Write-Methode aufruft.

Der Stream des Filters kann keine Annahmen über die Anzahl der Bytes treffen, die bei jedem Schreibvorgang in ihn geschrieben werden, da die ungefilterten Bilddaten möglicherweise von der WIA 2.0-Vorschaukomponente und nicht vom Treiber stammen. Die WIA 2.0 Preview-Komponente schreibt die gesamten ungefilterten Bilddaten immer nur einmal in den Datenstrom des Filters, was bedeutet, dass im Stream des Filters eine Quelle geschrieben wird. Wenn sowohl der Treiber als auch die Vorschaukomponente in den Stream des Filters schreiben, kann der Stream des Filters beispielsweise nicht davon ausgehen, dass er den vollständigen Header beim ersten Aufruf von IStream::Write erhält, obwohl der entsprechende Treiber immer zuerst die Headerdaten in einem Schreibvorgang schreibt. Es kann auch nicht davon ausgegangen werden, dass ein nachfolgendes Schreiben genau eine Scanzeile enthält. Daher muss der Filterdatenstrom möglicherweise die Anzahl der in ihn geschriebenen Bytes zählen, um z. B. zu bestimmen, wo die Bilddaten beginnen.

Die IWiaTransferCallback::GetNextStream-Implementierung des Bildverarbeitungsfilters sollte die für die Bildverarbeitung erforderlichen Eigenschaften aus dem Element lesen, für das das Image abgerufen wird. Der Filter liest die Eigenschaften nicht direkt aus dem an InitializeFilter übergebenen pWiaItem2. Stattdessen muss der Filter FindItemByName für dieses WIA 2.0-Element aufrufen, um das tatsächliche WIA 2.0-Element abzurufen. Der Grund dafür ist, dass es sich bei dem abgerufenen Bild möglicherweise um ein untergeordnetes Element von pWiaItem2 handelt. Beispielsweise verwendet der Filter während eines Ordnererwerbs pWiaItem2 , um die untergeordneten Elemente von pWiaItem2 in IWiaTransferCallback::GetNextStream abzurufen (während eines Ordnererwerbs gibt der Treiber die Bilder zurück, die von den untergeordneten Elementen von pWiaItem2 dargestellt werden). Das gleiche gilt, wenn die WIA 2.0-Vorschaukomponente in den Bildverarbeitungsfilter aufruft und ein untergeordnetes WIA 2.0-Element übergibt.

Anforderungen