Geräte

Artikel
05/18/2015

Entwickeln Sie eine App, die per Funk oder Kabel mit verschiedensten Geräten verbunden werden kann und Benutzern sämtliche Vorteile der Mobilität und Flexibilität eines Windows 8.1-Geräts bietet, wenn sie privat oder beruflich Inhalte ansehen oder erstellen.

Neues oder Aktualisierungen in Windows 8.1

Unterstützung von HID-Geräten
Unterstützung von Point of Service (POS)-Geräten
Unterstützung von USB-Geräten
Unterstützung von Bluetooth-Geräten
Unterstützung von 3D-Druckern
Unterstützung für das Scannen

Unterstützung von HID-Geräten

[Laden Sie das Beispiel für den Zugriff auf benutzerdefinierte HID-Geräte und das Beispiel für eine Bewegungssensor-, Firmware- und Windows-Runtime-App für HID herunter.]

Die Windows.Devices.HumanInterfaceDevice-API bietet Ihrer Windows Store-App Zugriff auf Geräte, die das Human Interface Device (HID)-Protokoll unterstützen.

Bei seiner Entwicklung wurde das Protokoll anfangs für Geräte wie Tastaturen, Mäuse und Joysticks konzipiert. Es sollte ursprünglich über den USB-Transport laufen. Heute unterstützt das Protokoll sehr viel mehr Geräte. Für Windows 8.1 stellt Microsoft außerdem Unterstützung für USB-, Bluetooth-, Bluetooth LE- und I²C-Transporte bereit.

Die neue API ist für zwei unterschiedliche Zielgruppen vorgesehen:

Für den Hardwarepartner, der ein HID-Peripheriegerät entwickelt hat und jetzt eine Windows Store-App benötigt, über die Benutzer von Windows 8.1 das Gerät bedienen oder darauf zugreifen können. (Hardwarepartner können eine App so deklarieren, dass sie automatisch abgerufen wird, wenn ein Benutzer das Peripheriegerät anschließt.)
Für den App-Entwickler, der eine App für eines dieser Peripheriegeräte erstellen möchte.

Der Hardwarepartner kennt sich bereits mit dem HID-Gerät aus, muss aber auch die Anforderungen von Windows Store-Apps verstehen. Der App-Entwickler muss sich wahrscheinlich mit dem Protokoll vertraut machen. Wenn Sie nicht mit HID vertraut sind, lesen Sie auf der MSDN-Website in der HID-Treiberdokumentation das Thema Einführung in HID-Konzepte.

Bevor Sie jedoch die neue API verwenden, überprüfen Sie im Abschnitt Einschränkungen, ob Ihr Gerät unterstützt wird.

Hinweis Das Zielgerät für die folgenden Beispiele ist SuperMUTT, ein Testgerät, das Sie bei JJG Technologies bestellen können.

Herstellen einer Verbindung mit einem HID-Gerät

Dieses Codebeispiel zeigt, wie eine Windows Store-App, die mit XAML und C# programmiert wurde, die HidDevice.GetDeviceSelector-Methode verwendet, um einen Selektor für ein bestimmtes HID-Gerät zu erstellen. Dann verwendet die App die HidDevice.FromIdAsync-Methode, um eine Verbindung zu diesem Gerät herzustellen.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

using Windows.Devices.Enumeration;
using Windows.Devices.HumanInterfaceDevice;
using Windows.Storage;
using Windows.Storage.Streams;

namespace HidSampleCS
{
    class Enumeration
    {
        // Enumerate HID devices.
        private async void EnumerateHidDevices()
        {
            UInt32 vendorId = 0x045E;
            UInt32 productId = 0x078F;
            UInt32 usagePage = 0xFF00;
            UInt32 usageId = 0x0001;

            // Create a selector that gets a HID device using VID/PID and a 
            // VendorDefined usage.
            string selector = HidDevice.GetDeviceSelector(usagePage, usageId, 
                              vendorId, productId);

            // Enumerate devices using the selector.
            var devices = await DeviceInformation.FindAllAsync(selector);

            if (devices.Count > 0)
            {
                // Open the target HID device at index 0.
                HidDevice device = await HidDevice.FromIdAsync(devices.ElementAt(0).Id, 
                                   FileAccessMode.ReadWrite);

                // At this point the device is available to communicate with,
                // so we can send/receive HID reports from it or 
                // query it for control descriptions.
            }
            else
            {
                // There were no HID devices that met the selector criteria.
                this.NotifyUser("MUTT HID device not found");
            }
        }
    }
}

Abrufen von Daten von einem HID-Gerät

Apps verwenden Eingabeberichte, um Daten von einem HID-Gerät abzurufen. Dieses Beispiel veranschaulicht, wie eine App die HidInputReport.GetNumericControl-Methode verwendet, um einen numerischen Wert von einem SuperMUTT-Gerät abzurufen.

Im Beispiel ist das verbundene HID-Gerät durch das DeviceList.Current.CurrentDevice-Objekt dargestellt.

        private async Task GetNumericInputReportAsync()
        {
            var inputReport = await DeviceList.Current.CurrentDevice.GetInputReportAsync(SuperMutt.ReadWriteBuffer.ReportId);

            var inputReportControl = inputReport.GetNumericControl(SuperMutt.ReadWriteBuffer.NumericUsagePage, SuperMutt.ReadWriteBuffer.NumericUsageId);

            var data = inputReportControl.Value;

            rootPage.NotifyUser("Value read: " + data.ToString("X2", NumberFormatInfo.InvariantInfo), NotifyType.StatusMessage);
        }

Einschränkungen der HID-API

Beachten Sie die folgenden Einschränkungen, wenn Sie über die Implementierung dieses API-Sets nachdenken.

Die Windows.Devices.HumanInterfacDevice-API unterstützt die meisten HID-Geräte. Sie blockiert jedoch die von den folgenden Verwendungsseiten dargestellte App-Auflistung auf oberster Ebene:

HID_USAGE_PAGE_UNDEFINED
HID_USAGE_PAGE_GENERIC
HID_USAGE_GENERIC_KEYBOARD
HID_USAGE_GENERIC_KEYPAD
HID_USAGE_GENERIC_SYSTEM_CTL
HID_USAGE_PAGE_KEYBOARD
HID_USAGE_PAGE_CONSUMER
HID_USAGE_PAGE_DIGITIZER
HID_USAGE_PAGE_SENSOR
HID_USAGE_PAGE_BARCODE_SCANNER
HID_USAGE_PAGE_WEIGHING_DEVICE
HID_USAGE_PAGE_MAGNETIC_STRIPE_READER
HID_USAGE_PAGE_TELEPHONY

Nur mitgelieferte Gerätetreiber

Neben der Blockierung der obigen Liste von Verwendungsseiten erfordert die neue API außerdem, dass Ihre App über die mit Windows 8.1 mitgelieferten Treiber ausgeführt wird. Die API unterstützt keine vom Hersteller bereitgestellten Treiber.

Nur Unterstützung von Peripheriegeräten

Die HID-API ist in erster Linie für Apps vorgesehen, die auf Peripheriegeräte zugreifen. Das oben beschriebene App-Entwicklerszenario gilt nur für diese Geräte.

Die API kann zwar für den Zugriff auf interne Geräte (also keine Peripheriegeräte) verwendet werden, der Zugriff ist dann aber auf einige vom Gerätehersteller erstellte privilegierte Apps beschränkt. App-Entwickler können nicht auf interne Geräte zugreifen.

Keine Unterstützung für Systemsteuerungs-Apps

Apps, die mit der HID-API erstellt wurden, sind "Pro Benutzer"-Apps. Das bedeutet, dass diese Apps keine Einstellungen speichern können (das ist jedoch eine typische Anforderung für Systemsteuerungs-Apps).

Unterstützung von Point of Service (POS)-Geräten

[Laden Sie sich die Beispiele für Strichcodescanner und Magnetstreifenleser herunter.]

Mit Windows 8.1 wird ein neuer Windows.Devices.PointOfService-Namespace für spezielle Point of Service (POS)-Geräte eingeführt. Diese Version unterstützt Strichcodescanner und Magnetstreifenleser. Mit der herstellerunabhängigen POS-API können Sie Windows Store-Apps erstellen, die auf POS-Geräte von verschiedenen Herstellern zugreifen können und eine n:n-Zuordnung zwischen POS-Apps und POS-Geräten ermöglichen.

Dieser Namespace basiert auf der Standardspezifikation Unified Point of Service (UPOS). Weitere Infos hierzu finden Sie auf der Website UnifiedPOS.

Bei Strichcodescannern erfolgt die Geräteerstellung durch statische Aktivierung mithilfe der GetDefaultAsync-Methode. Diese Methode ruft den ersten verfügbaren Strichcodescanner ab, der mit dem Tablet verbunden ist (sofern mehrere Scanner vorhanden sind). Sie können auch ein spezifisches Gerät mithilfe der FromIdAsync-Methode erstellen, bei der ein Strichcodescanner von einer DeviceInformation-ID abgerufen wird. Mit ClaimScannerAsync erhält Ihre App exklusiven Zugriff auf das Gerät und es wird verhindert, dass andere Apps darauf zugreifen können. Und mit EnableAsync wird das Gerät auf ein DataReceived-Ereignis vorbereitet. Das gleiche Muster und die gleichen API-Elemente gelten für Magnetstreifenleser.

Diese Codebeispiele zeigen, wie ein mit einem Tablet verbundener Strichcodescanner abgerufen und für den Empfang von Daten vorbereitet wird.

// Creates the barcode scanner, claims it for exclusive use, and enables it to receive data.
var _scanner = null;
var _claimedScanner = null;

function startReceivingData() {
    Windows.Devices.PointOfService.BarcodeScanner.getDefaultAsync().then(function (scanner) {
        if (scanner !== null) {
            _scanner = scanner;

            scanner.claimScannerAsync().done(function (claimedScanner) {
                if (claimedScanner !== null) {
                    _claimedScanner = claimedScanner;
                    claimedScanner.isDecodeDataEnabled = true;

                    claimedScanner.addEventListener("datareceived", onDataReceived);
                    claimedScanner.enableAsync().done(function () {

                        document.getElementById("btnStartReading").disabled = true;
                        document.getElementById("btnEndReading").disabled = false;
                    }, function error(e) {
                        // Failed to enable scanner.
                    });

                } else {
                    // Could not claim the scanner.
                }
            }, function error(e) {
                // Could not claim the scanner.
            });

        } else {
            // Barcode scanner not found. Connect a barcode scanner.
        }

    }, function error(e) {
        // Asynchronous method failed.
    });
}

// Creates the default barcode scanner.

private async Task<bool> CreateDefaultScannerObject()
{
    if (scanner == null)
    {
        
        scanner = await BarcodeScanner.GetDefaultAsync();

        if (scanner != null)
        {
            // UpdateOutput("Default barcode scanner created.");
            // UpdateOutput("Device Id is:" + scanner.DeviceId);
        }
        else
        {
            // UpdateOutput("Barcode scanner not found. Please connect a barcode scanner.");
            return false;
        }
    }
    return true;
}

// Claims the barcode scanner for exclusive use. 

private async Task<bool> ClaimScanner()
{
    if (claimedScanner == null)
    {
        // Claim the barcode scanner.
        claimedScanner = await scanner.ClaimScannerAsync();

        if (claimedScanner != null)
        {
            // UpdateOutput("Barcode scanner claimed successfully.");
           
        }
        else
        {
            // UpdateOutput("Failed to claim the barcode scanner.");
            return false;
        }
    }
    return true;
}

// Enables the barcode scanner to receive data. 

private async Task<bool> EnableScanner()
{
   
    if (claimedScanner == null)
    {
        return false;   
    }
    else
    {   
        await claimedScanner.EnableAsync();
      
        return true;
    }            
  
}

// Creates the barcode scanner.
task<void> Scenario1::CreateDefaultScannerObject()
{
    return create_task(BarcodeScanner::GetDefaultAsync()).then([this] (BarcodeScanner^ _scanner)
    {
        this->scanner = _scanner;
        if (this->scanner != nullptr)
        {            
            // UpdateScannerStatusTextBlock("Barcode scanner created.");
            // UpdateScannerStatusTextBlock("Device ID is:" + this->scanner->DeviceId);
        }
        else
        {
            // UpdateScannerStatusTextBlock("Barcode scanner not found. Connect a barcode scanner.");
            // rootPage->NotifyUser("No barcode scanner found.", NotifyType::StatusMessage);
        }
    });

}

// Claims the barcode scanner for exclusive use.
task<void> Scenario1::ClaimScanner()
{
    return create_task(scanner->ClaimScannerAsync()).then([this] (ClaimedBarcodeScanner^ _claimedScanner)
    {
        this->claimedScanner = _claimedScanner;
        if (claimedScanner != nullptr)
        {
            // UpdateScannerStatusTextBlock("Barcode scanner claimed successfully.");        
        }
        else
        {
            // UpdateScannerStatusTextBlock("Failed to claim barcode scanner.");
        }
    });
}

// Enables the barcode scanner to receive data.
task<void> Scenario1::EnableScanner()
{
    return create_task(claimedScanner->EnableAsync()).then([this](void)
    {
        // UpdateScannerStatusTextBlock("Barcode scanner enabled successfully.");
    });
}

Weitere Informationen zu diesen Methoden und Eigenschaften finden Sie unter Windows.Devices.PointOfService-Referenz.

Diese API stellt einen einfachen Migrationspfad für POS-Entwickler bereit. Sie können Ihre Desktop-Apps (die Microsoft POS für .NET verwenden) in Windows Store-Apps verwandeln, die die Windows Runtime verwenden und auf Tablets ausgeführt werden. Das API-Modell ist POS für .NET sehr ähnlich, jedoch gibt es einige Änderungen.

Unterstützung von USB-Geräten

[Laden Sie sich das Beispiel für den Zugriff auf benutzerdefinierte USB-Geräte herunter.]

Ein neuer Namespace in Windows 8.1 bietet App-Unterstützung für USB-Geräte: Windows.Devices.Usb. Sie können mit diesem Namespace eine Windows Store-App erstellen, die mit einem benutzerdefinierten USB-Gerät kommunizieren kann. "Benutzerdefiniert" bedeutet in diesem Fall ein Peripheriegerät, für das Microsoft keinen mitgelieferten Treiber bereitstellt.

Die offizielle USB-Spezifikation ist die Industrienorm für die Hardware-Hersteller, die USB-Peripheriegeräte für PCs herstellen. Windows bietet mitgelieferte Treiber für die meisten dieser Geräte. Für Geräte ohne mitgelieferten Treiber können Benutzer den von Microsoft bereitgestellten generischen Treiber Winusb.sys installieren. Für die Herstellung neuer Peripheriegeräte können Hersteller ihre eigenen benutzerdefinierten Treiber bereitstellen oder Winusb.sys nutzen. Bei Geräten mit Winusb.sys können Sie ganz leicht Begleit-Apps programmieren, mit denen der Benutzer mit dem Gerät kommunizieren kann. In früheren Versionen von Windows waren solche Apps Desktop-Apps, die mit WinUSB-Funktionen geschrieben wurden. In Windows 8.1 können Windows Store-Apps mithilfe des neuen Windows.Devices.Usb-Namespace erstellt werden.

Wann die neue USB-API verwendet werden sollte

Sie können die neue API verwenden, wenn folgende Bedingungen zutreffen:

Der Gerätetreiber ist der von Microsoft bereitgestellte Treiber "Winusb.sys". Der Namespace unterstützt vom Hersteller bereitgestellte Gerätetreiber nicht. Wenn Sie das Gerät anschließen, installiert Windows Winusb.sys je nach Geräteausführung unter Umständen automatisch. Wird der Treiber nicht automatisch installiert, muss die Installation manuell im Geräte-Manager vorgenommen werden:
1. Klicken Sie mit der rechten Maustaste auf das Gerät, und wählen Sie Treibersoftware aktualisieren aus.
2. Wählen Sie im Assistenten Auf dem Computer nach Treibersoftware suchen aus.
3. Wählen Sie auf der nächsten Seite Aus einer Liste von Gerätetreibern auf dem Computer auswählen aus.
4. Wählen Sie in der Liste auf der nächsten Seite USB-Geräte aus.
5. Wählen Sie WinUsb-Gerät aus, und klicken Sie auf Weiter, um den Treiber zu installieren.
Sie geben die Informationen zu Ihrem Gerät als Deklarationen der Gerätefunktionen im App-Manifest an. Dadurch wird Ihre App mit dem Gerät verknüpft.

Weitere Informationen finden Sie unter Aktualisieren des App-Manifestpakets für ein USB-Gerät.
Das Gerät gehört zu einer der Geräteklassen, die von dem Namespace unterstützt werden. Beachten Sie, dass ein benutzerdefiniertes Gerät zu einer vordefinierten USB-Geräteklasse gehören kann, oder die Gerätefunktionen können vom Hersteller definiert sein.

Verwenden Sie den Windows.Devices.Usb-Namespace für die folgenden USB-Geräteklassen, Unterklassen und Protokollcodes:

CDC-Steuerungsklasse (Klassencode: 0x02; Unterklassencode: beliebig; Protokollcode: beliebig)
Physische Klasse (Klassencode: 0x05; Unterklassencode: beliebig; Protokollcode: beliebig)
PersonalHealthcare-Klasse (Klassencode: 0x0f; Unterklassencode: 0x00; Protokollcode: 0x00)
ActiveSync-Klasse (Klassencode: 0xef; Unterklassencode: 0x01; Protokollcode: 0x01)
PalmSync-Klasse (Klassencode: 0xef; Unterklassencode: 0x01; Protokollcode: 0x02)
DeviceFirmwareUpdate-Klasse (Klassencode: 0xfe; Unterklassencode: 0x01; Protokollcode: 0x01)
IrDA-Klasse (Klassencode: 0; Unterklassencode: 0x02; Protokollcode: 0x00)
Measurement-Klasse (Klassencode: 0xfe; Unterklassencode: 0x03; Protokollcode: beliebig)
Herstellerspezifische Klasse (Klassencode: 0xff; Unterklassencode: beliebig; Protokollcode: beliebig)

Wann die neue USB-API nicht verwendet werden sollte

Sie dürfen die neue API nicht verwenden, wenn folgende Bedingungen zutreffen:

Sie möchten, dass Ihre App auf interne Geräte zugreift.Windows.Devices.Usb ist nur für den Zugriff auf Peripheriegeräte bestimmt. Eine Windows Store-App kann nur auf interne USB-Geräte zugreifen, wenn sie eine privilegierte App ist, die explizit vom OEM für das System deklariert wurde.
Ihre App ist eine Systemsteuerungs-App. Apps, die den Namespace verwenden, müssen "Pro Benutzer"-Apps sein. Das bedeutet, die Apps können mit dem Gerät kommunizieren, aber keine Einstellungen außerhalb ihres Bereichs speichern – eine Funktion, die bei vielen Systemsteuerungs-Apps erforderlich ist.

Verwenden Sie nicht den Namespace Windows.Devices.Usb für diese USB-Geräteklassen:

Audioklasse (0x01)
HID-Klasse (0x03)
Bildklasse (0x06)
Druckerklasse (0x07)
Massenspeicherklasse (0x08)
Smartcardklasse (0x0B)
Audio-/Videoklasse (0x10)
Funkcontroller (z. B. drahtloser USB-Host oder -Hub) (0xE0)

Der Namespace blockiert diese USB-Geräteklassen, um einen Konflikt mit anderen APIs zu vermeiden. Verwenden Sie stattdessen für diese Klassen andere relevante APIs. Verwenden Sie z. B. Windows.Devices.HumanInterfaceDevice, wenn Ihr Gerät dem HID-Protokoll entspricht.

Erkennen eines USB-Geräts und Herstellen einer Verbindung

Dieser Beispielcode zeigt, wie Sie nach einem USB-Gerät suchen und eine Verbindung mit ihm herstellen.

 
    var deviceQueryString = UsbDevice.GetDeviceSelector(deviceVid, devicePid, deviceInterfaceClass);

    var myDevices = await Windows.Devices.Enumeration.DeviceInformation.FindAllAsync(deviceQueryString, null);
    
    UsbDevice device = await UsbDevice.FromIdAsync(myDevices[0].Id);

    // Device is in use.
    if (device != null)
    {
        MainPage.Current.NotifyUser("Device " + id + " opened", NotifyType.StatusMessage);
    }
    else
    {
        MainPage.Current.NotifyUser("Unable to open device : " + id, NotifyType.ErrorMessage);
    }

Beginnen Sie das Schreiben einer USB-fähigen Windows Store-App am besten damit, dass Sie das Beispiel CustomUsbDeviceAccess genau durchgehen. Dieses Beispiel zeigt, wie Sie mithilfe des Windows.Devices.Usb-Namespaces mit einem USB-Gerät kommunizieren.

Unterstützung von Bluetooth-Geräten

[Laden Sie sich die Beispiele Bluetooth Rfcomm Chat und Bluetooth-generisches Attributprofil herunter.]

In Windows 8.1 können Windows Store-Apps die neuen Windows-Runtime-APIs RFCOMM und GATT (generisches Attributprofil) verwenden, um auf Bluetooth-Geräte zuzugreifen. Diese APIs bieten Zugriff auf den Bluetooth BR/EDR- und Bluetooth LE-Transport.

Bluetooth Classic- und Bluetooth Smart-Geräte müssen zunächst erkannt und über die PC-Einstellungen von Windows 8.1 (PC und Geräte > Bluetooth) gekoppelt werden, bevor auf diese Geräte über die Windows-Runtime-APIs für Bluetooth zugegriffen werden kann.

Sie geben die Informationen zu Ihren Geräten als Gerätefunktionsdeklarationen im App-Manifest an. Dadurch wird Ihre App mit dem Gerät verknüpft.

Dies sind einige der wichtigsten Punkte zu den neuen APIs:

Bluetooth RFCOMM—Windows.Devices.Bluetooth.Rfcomm

Mit der API können Entwickler von Windows Store-Apps Bluetooth-Profile implementieren, die auf dem RFCOMM-Protokoll basieren, z. B. das Serial Port Profile (SPP).
Client- und Serverrollen sind verfügbar.
Auf Service Discovery Protocol (SDP)-Remotedatensätze kann zugegriffen und lokale SDP-Datensätze können veröffentlicht werden.
Die Sockets.ControlChannelTrigger-Klasse steht nicht für RFCOMM-basierte Sockets zur Verfügung.

Die RFCOMM-API verhindert den Zugriff auf die folgenden Standarddienste und ungültigen Dienste:

Dienst-ID	Dienst (Bluetooth-SIG-Name)
0x1000	Service Discovery (Dienstübermittlung)
0x1001	Browse Group Descriptor (Gruppe durchsuchen – Deskriptor)
0x1102	LAN Access Using PPP (LAN-Zugriff per PPP)
0x1103	Dialup Networking (DFÜ-Netzwerk)
0x1108, 0x1112	Headset (Headset)
0x1109	Cordless Telephony (Telefonie, schnurlos)
0x110A	Audio Source (Audioquelle)
0x110B	Audio Sink (Audiosenke)
0x110C, 0x110E, 0x110F	A/V Remote Control (A/V-Fernbedienung)
0x1110	Intercom (Sprechanlage)
0x1111	Fax (Fax)
0x1113, 0x1114	WAP (WAP)
0x1115	PANU (PANU)
0x1116	NAP (NAP)
0x1117	GN (GN)
0x111E, 0x111F	Handsfree (Freisprechen)
0x1124	Eingabegeräte
0x1126	HCR Print (Drucken (HCR))
0x1127	HCR Scan (Scannen (HCR))
0x1128	Common ISDN Access (Common ISDN-Zugriff)
0x112D	SIM Access (SIM-Zugriff)
0x1131	Headset – HS (Headset – HS)
0x1136	GNSS Server (GNSS-Server)
0x1200	PnP Information (PnP-Informationen)
0x1201	Generic Networking (Netzwerk – generisch)
0x1203	Generic Audio (Audio – generisch)
0x1204	Generic Telephony (Telefonie – generisch)
0x1205, 0x1206	UPnP (UPnP)
0x1300, 0x1301, 0x1302	ESDP UPnP IP (ESDP-UPnP-IP)
0x1303	Video Source (Videoquelle)
0x1304	Video Sink (Videosenke)
0x1305	Video Distribution (Videoverteilung)
0x1401	HDP Source (HDP-Quelle)
0x1402	HDP Sink (HDP-Senke)

Bluetooth GATT—Windows.Device.Bluetooth.Gatt

Mit der API können Entwickler von Windows Store-Apps GATT-Clientprofile implementieren, um Daten von LE-Sensoren zu erfassen.
Für die Verwendung der GATT-API ist ein Bluetooth 4.0-Gerät erforderlich.
Die GATT-API verhindert den Zugriff auf die folgenden Standarddienste und ungültigen Dienste:

Dienst-ID Dienst (Bluetooth-SIG-Name)

0x1812

HID-über-GATT-Dienst
Die GATT-API ermöglicht Lesezugriff auf die folgenden Standarddienste und ungültigen Dienste:

Dienst-ID Dienst (Bluetooth-SIG-Name)

0x1800

GAP-Dienst

0x1801

GATT-Dienst

0x1813

Überprüfungsparameterdienst

Dienst-ID	Dienst (Bluetooth-SIG-Name)
0x1812	HID-über-GATT-Dienst

Dienst-ID	Dienst (Bluetooth-SIG-Name)
0x1800	GAP-Dienst
0x1801	GATT-Dienst
0x1813	Überprüfungsparameterdienst

Hinweis Die Windows-Runtime-APIs für RFCOMM und GATT sind nicht für die Verwendung in Systemsteuerungs-Apps vorgesehen.

Weitere Informationen zur richtigen Verwendung der Windows.Devices.Bluetooth.Rfcomm-API finden Sie in den folgenden zwei Szenarien:

Weitere Informationen zur richtigen Verwendung der Windows.Device.Bluetooth.Gatt-API finden Sie in den folgenden zwei Szenarien:

Unterstützung von 3D-Druckern

[Laden Sie sich jetzt das Beispiel zum 3D-Druck herunter.]

Das Drucken von 3D-Inhalten mit Windows 8.1 ähnelt dem Drucken von 2D-Inhalten. Eigentlich haben wir zum Bereitstellen dieses Features nur die IXpsOMPackageWriter- und die IXpsDocumentPackageTarget-Schnittstelle erweitert. Um 3D-Inhalte von einer App in Windows 8.1 an einen Drucker zu senden, muss Ihre App auf die Windows-Druckfunktion zugreifen und formatierte 3D-Inhalte zum Drucken bereitstellen.

Zum Drucken von 3D-Inhalten in Windows 8.1 müssen Sie 3D-Inhalte erstellen und über die Pipeline des Windows-Spoolers und der Treiberfilter an das 3D-Fertigungsgerät, z. B. einen 3D-Drucker, übergeben.

Zwei Schnittstellen (IXpsDocumentPackageTarget3D und IXpsOMPackageWriter3D) sind in der 3D-Druck-API enthalten. IXpsDocumentPackageTarget3D stellt eine Druckwarteschlange und Auftragsdetails dar. IXpsOMPackageWriter3D stellt Methoden zum Senden von Inhalten an die Windows-Druckpipeline dar. Diese Schnittstelle übergibt 3D-Inhalte als opake Streams über Spooler und Treiberfilter an das 3D-Fertigungsgerät.

Die 3D-Druckschnittstellen weisen die folgenden Merkmale auf:

Sie unterstützen das Übermitteln von 3D-Inhalten zum Drucken im Format Open Packaging Conventions (OPC).
Sie unterstützen die Übermittlung von 3D-Inhalten sowie von XPS-Inhalten für den 2D-Druck.
Die 3D-Inhalte sind auf einen einzelnen 3D-Modellteil beschränkt, der null oder mehr Texturteile und maximal einen Druckticketteil verknüpft.
Die 3D-Modell- und Texturdaten werden von der API als opaker Stream betrachtet, und es gibt keine Überprüfung oder Analyse.

Eine Featureübersicht finden Sie unter Unterstützen des 3D-Drucks. Informationen zum Hinzufügen der 3D-Druckfunktion zu Ihren Apps finden Sie unter Schnellstart: 3D-Druck.

Unterstützung für das Scannen

[Laden Sie sich das Beispiel zum Scannen herunter.]

Sie können zum Scannen von Inhalten über die Windows Store-App jetzt einen Flachbett-, Einzugs- oder automatisch konfigurierten Scanner verwenden.

Der neue Windows.Devices.Scanners-Namespace wird zusätzlich zu den vorhandenen WIA-APIs erstellt und in die Gerätezugriffs-API integriert.

Hinweis Eine Scan-App ist in Windows 8.1 integriert.

Eine Übersicht über die Features finden Sie unter Scannen (JavaScript und HTML) oder Scannen (C#/C++/VB und XAML).