Windows Image Acquisition (WIA)

The WIA platform enables imaging/graphics applications to interact with imaging hardware and standardizes the interaction between different applications and scanners. This allows those different applications to talk to and interact with those different scanners without requiring the application writers and scanner manufactures to customize their application or drivers for each application-device combination.

Benefits of Windows Image Acquisition 2.0

WIA provides benefits to application developers, device manufacturers, and scanner users who need to interact with imaging hardware.

For Application Writers

• Windows runs a certification process for WIA drivers so WIA applications are guaranteed to be base-level compatible with all WIA-based scanners.
• WIA drivers are loaded in the WIA service process, thus providing a more stable driver environment.
• Applications can be initiated from the scanner scan button via push events supported by the WIA subsystem.
• The WIA includes a default segmentation filter that all drivers can take advantage of; this way, applications do not have to write code for multi-region scanning for purposes such as separating out a large number of photos spread over a flatbed scanner.

For Device Manufactures

• WIA driver certification process helps driver developers in establishing that their driver is WIA-compliant.
• WIA drivers can take advantage of a built-in segmentation filter, image processing filter and error handler, if they choose to do so.
• WIA-based scanners work right out of the box on Windows with Windows scanning applications such as Windows Fax and Scan and Paint.
• WIA drivers offer better integration with Windows such as the full device experience.
• Windows Vista release includes a WSD-WIA class driver that enables all devices compliant with Web Services for Scanner (WS-Scan) protocol to work with WIA applications without any additional driver or software.

For Scanner Users

• WIA-based scanners can be used from Windows applications such Windows Fax and Scan and Paint without the need for any additional software.
• WIA-based applications and scanners can also take advantage of WIA add-ons such as the segmentation filter which enables such features as processing a number of pictures on the scanner and scanning them all to individual files without user intervention.
• WIA-based devices offers a much better integration with other Windows features such as the Device Stage feature for Windows 7.
• WIA provides a more robust, stable and reliable scanning experience by isolating the driver and the application.

Development of Windows Image Acquisition

The imaging architecture in Windows 2000 and Windows 95 or later consisted of a low-level hardware abstraction, Still Image Architecture (STI), and a high-level set of APIs known as TWAIN. In Windows XP and Windows Me WIA was introduced. WIA is an imaging architecture that builds on STI and does not require TWAIN, although TWAIN is still supported alongside WIA.
WIA 1.0 was introduced in Windows Me and Windows XP and supports scanners, digital cameras and digital video equipment. WIA 2.0 was released with Windows Vista. WIA 2.0 is targeted towards scanners but continues to offer support for legacy WIA 1.0 applications and devices through a WIA 1.0 to WIA 2.0 compatibility layer provided by the WIA service. However, video content support was removed from WIA for Windows Vista. We recommend Windows Portable Devices (WPD) API for digital cameras and digital video equipment in the future. WIA 1.0 as well as STI TWAIN drivers are still supported directly on Windows Vista and Windows 7 alongside native WIA 2.0 device drivers and imaging applications.

Overview of Windows Image Acquisition

WIA provides a framework that allows a device to present its unique capabilities to the operating system and allows imaging applications to invoke those unique capabilities.
The WIA platform includes a data acquisition protocol, a Device Driver Model and Interface (DDI), an API and a dedicated WIA service. The platform also includes a set of built-in kernel mode drivers that support communication with imaging devices locally connected through USB, serial/parallel, SCSI and FireWire interfaces. The WIA subsystem also includes a transparent compatibility layer which allows TWAIN compatible applications to employ and use WIA-driver-based devices.
Network connected imaging devices that support Web Services for Devices (WSD) protocol can also be used from WIA-compliant imaging applications on Windows Vista and Windows 7 out of the box via a WSD-WIA class driver that shipped as part of Windows Vista. The class driver converts WIA calls to WSD calls and vice versa and makes already existing WIA applications work with WSD based scanners without any additional driver.
WIA drivers are made up of a user interface (UI) component and a core driver component, loaded into two different process spaces: UI in the application space and the driver core in the WIA service space. The service runs in Local System context in Windows XP and runs in Local Service context starting with Windows Server 2003 and Windows Vista for enhanced security against buggy or malicious drivers.

The WIA API set exposes imaging applications to still image acquisition hardware functionality by providing support for:

• Enumeration of available image acquisition devices.
• Creating connections to multiple devices simultaneously.
• Querying properties of devices in a standard and expandable manner.
• Acquiring device data by using standard and high performance transfer mechanisms.
• Maintaining image properties across data transfers.
• Notification of device status and scan event handling.

Windows added scripting support to WIA by releasing the WIA Automation Library in 2002 that was incorporated in Windows Vista as Windows Image Acquisition (WIA) Automation Layer 2.0 and continues to be a part of Windows 7. The WIA Automation Library provides end-to-end image acquisition capabilities to automation-enabled application development environments and programming languages such as Microsoft Visual Basic 6.0, Active Server Pages (ASP), VBScript and C#.
For Windows 7, WIA APIs have additional support to complement the already existing push-scanning support.

• Auto-configured device initiated scanning with scan parameters configured at the scanner on the device front panel.
• Automatic source selection for device-initiated scan.

Facts about Windows Image Acquisition 2.0

• The data transfer mechanism in WIA 2.0 is stream based. The stream abstraction removes the distinction between different transfer types and also allows exchange of mutually agreed-upon metadata between device and application.
• WIA 2.0 subsystem also includes a basic image processing filter driver add-on that is optionally replaceable by the scanner driver, if the driver chooses to provide a customized image processing filter. The built-in filter enables post processing of images acquired through the scanner. Image processing filter also enables live software previews when small settings such as brightness and contrast are adjusted.
• The segmentation filter is another handy WIA component that can be replaced by a more customized filter by the scanner driver. The segmentation filter can be used for multi-region scanning. Multi-region scanning, as an example, allows an application to automatically detect different scan regions without any user intervention, such as identifying a bunch of photos lying randomly on the scanner flatbed.
• WIA 2.0 provides a replaceable/extensible error handler to gracefully handle, and possibly recover from, software, hardware and configuration errors and delays. The error handler is another WIA component that can be replaced with a more customized version by the scanner driver. This extension provides status and error messages during data acquisitions such as "Lamp warming up," "Cover open," "Paper jam," and so on. This extension also allows cleaner support for "Cancel operations."

Developer Audience

The WIA API is designed for use by C/C++ programmers. Familiarity with the Windows GUI and Component Object Model (COM) interfaces is required.
For developers familiar with Microsoft Visual Basic 6.0, Active Server Pages (ASP), or scripting, WIA provides an automation layer for Windows XP Service Pack 1 (SP1) or later that builds upon and simplifies access to the foundation provided by C/C++. For information about the automation layer, see Windows Image Acquisition Automation Layer.

Note The WIA Automation Layer supersedes Windows Image Acquisition (WIA) 1.0 scripting.

Run-Time Requirements

Applications that use the WIA API require Windows XP or later.

ListView Riordinabile

Una delle esigenze più frequenti durante lo sviluppo di applicazioni con Windows Presentation Foundation è la rappresentazione di dati nel classico formato Grid. In Windows Presentation Foundation, almeno fino alla versione 3.5 del framework, viene utilizzato il controllo ListView.

Il controllo ListView di WPF, infatti, mette a disposizione un tipo di visualizzazione di tipo, appunto, GridView che permette la gestione di più colonne. Nell’esempio seguente viene definito un controllo ListView con modalità di visualizzazione GridView composta da 4 colonne in binding con alcune proprietà dell’entità Person.

<ListView x:Name="listPersons" ItemsSource="{StaticResource persons}"
          BorderThickness="0" Margin="5"
          GridViewColumnHeader.Click="GridViewColumnHeader_Click" >
    <ListView.View>
        <GridView AllowsColumnReorder="True">
            <GridViewColumn Header="ID" 
                            DisplayMemberBinding="{Binding Path=ID}" 
                            Width="50" />
            <GridViewColumn Header="FirstName" 
                            DisplayMemberBinding="{Binding Path=FirstName}" 
                            Width="100"/>
            <GridViewColumn Header="LastName" 
                            DisplayMemberBinding="{Binding Path=LastName}" 
                            Width="100"/>
            <GridViewColumn Header="City" 
                            DisplayMemberBinding="{Binding Path=City}" 
                            Width="80"  />
        </GridView>
    </ListView.View>
</ListView>

Nel listato, come noterete, viene definito l’handler dell’evento Click di GridViewColumnHeader dove verrà gestito, appunto, il riordinamento della colonna cliccata.

Per ottenere l’ordinamento della collection utilizzeremo un metodo chiamato Sort che, attraverso l’uso di una CollectionViewSource effettua l’ordinamento per il campo passato come parametro al metodo (sortBy).

private void Sort(string sortBy, ListSortDirection direction)
{
    ICollectionView dataView = CollectionViewSource.GetDefaultView(listPersons.ItemsSource);

    dataView.SortDescriptions.Clear();
    SortDescription sd = new SortDescription(sortBy, direction);
    dataView.SortDescriptions.Add(sd);
    dataView.Refresh();
}

Passiamo ora alla gestione dell’evento di click sull’header di una colonna della ListView.

GridViewColumnHeader _lastSelectedHeader = null;
ListSortDirection _lastDirection = ListSortDirection.Ascending;

void GridViewColumnHeader_Click(object sender, RoutedEventArgs e)
{
    GridViewColumnHeader selectedHeader = e.OriginalSource as GridViewColumnHeader;
    ListSortDirection direction;

    if (selectedHeader != null)
    {
        if (selectedHeader.Role != GridViewColumnHeaderRole.Padding)
        {
            if (selectedHeader != _lastSelectedHeader)
            {
                direction = ListSortDirection.Ascending;
            }
            else
            {
                if (_lastDirection == ListSortDirection.Ascending)
                {
                    direction = ListSortDirection.Descending;
                }
                else
                {
                    direction = ListSortDirection.Ascending;
                }
            }

            string header = string.Empty;
            if (selectedHeader.Column.CellTemplateSelector != null)
            {
                header = selectedHeader.Column.Header.ToString();
            }
            else if (selectedHeader.Column.DisplayMemberBinding != null)
            {
                header = ((Binding)selectedHeader.Column.DisplayMemberBinding).Path.Path;
            }
            else
            {
                return;
            }

            Sort(header, direction);

            if (direction == ListSortDirection.Ascending)
            {
                selectedHeader.Column.HeaderTemplate =
                  FindResource("HeaderTemplateArrowUp") as DataTemplate;
            }
            else
            {
                selectedHeader.Column.HeaderTemplate =
                  FindResource("HeaderTemplateArrowDown") as DataTemplate;
            }

            // Remove arrow from previously sorted header
            if (_lastSelectedHeader != null && _lastSelectedHeader != selectedHeader)
            {
                _lastSelectedHeader.Column.HeaderTemplate = null;
            }

            _lastSelectedHeader = selectedHeader;
            _lastDirection = direction;
        }
    }
}

Come potete vedere, la logica presente nell’evento è abbastanza semplice. Qui, infatti, viene, innanzitutto, intercettato l’intestazione cliccata, e, in base alla direzione di ordinamento (Ascending o Descending) viene applicato un template diverso per visualizzare una freccetta nell’intestazione per identificarnet, appunto, l’orientamento.
Ovviemente, in questo evento, viene richiamata il metodo Sort dichiarato in precedenza. Il codice XAML per la definizione dei template da utilizzare per la visualizzazione delle freccetta di indicazione nelle intestazioni è il seguente.

<DataTemplate x:Key="HeaderTemplateArrowUp">
    <DockPanel>
        <TextBlock HorizontalAlignment="Center" Text="{Binding}"/>
        <Path x:Name="arrow"
    StrokeThickness = "1" Fill="Black"
    Data="M 5,10 L 15,10 L 10,5 L 5,10"/>
    </DockPanel>
</DataTemplate>

<DataTemplate x:Key="HeaderTemplateArrowDown">
    <DockPanel>
        <TextBlock HorizontalAlignment="Center" Text="{Binding }"/>
        <Path x:Name="arrow"
    StrokeThickness="1" Fill="Black" 
    Data= "M 5,5 L 10,10 L 15,5 L 5,5"/>
    </DockPanel>
</DataTemplate>

Concludendo, quindi, ad un click su qualsiasi intestazione di colonna, viene effettuato l’ordinamento per la colonna in oggetto e sostituito il template dell’intestazione stessa affinchè venga in essa visualizzata una freccetta per identificarne la direzione dell’ordinamento effettuato.

WPF Ribbon

Ribbon Control Updates
Straight from the update details document, here's what was updated in this version:

• Ribbon Split Button is only half-highlighted when users mouse over the button
• Ribbon Title is bottom-aligned, should be centered
• Ribbon Quick Access Toolbar icons are clipped and top-aligned
• Ribbon Contextual Tab header text is getting truncated if too long
• Ribbon Gallery Item does not stretch to fit its Parent Panel
• Initial enabled state of Ribbon Split Menu Items can be incorrect if they have children
• Ribbon Split Menu Item with sub-items is disabled if CanExecute=false
• WPF Ribbon Dropdown does not close when CanAddToQuickAccessToolBarDirectly="False" was set at various level within the Ribbon
• InvalidOperationException may occur when switching themes and the WPF Ribbon is Minimized
• Ribbon Tab Header content may not appear when Ribbon starts out collapsed
• RibbonTab.TabHeaderLeft & RibbonTab.TabHeaderRight are incorrect when Ribbon starts out hosted in a Collapsed control
• Ribbon Tool Tip: Title and Footer Title gets clipped if the stringis too long
• Vertical and horizontal alignments for the standard Ribbon controls should be centered, they were not.
• After removing all items from the Quick Access Toolbar, phantom items remain visible
• Right clicking on the System icon will not place the Context Menu properly
• System Icon, Title and Quick Access Toolbar are not displayed correctly when Ribbon Windows is maximized
• A minimized Ribbon will render on top of the window when a Popup is opened.
• RibbonWindow.Icon does not pick appropriate small size icon from *.ico Icon file.
• IndexOutofRange Exception would pop when removing a Tab from an Observable Collection.
• WPF Ribbon can use ClearType when targeting .NET Framework 4.0 control.

The two most important fixes in here for me are the cleartype fix, and the support for the Express SKUs. You know I go nuts overproper ClearType rendering.
Note that the ClearType fix is in the .NET 4 version of the DLL, not in the 3.5sp1 version. That's due to it using ClearType enhancements that came about only in .NET 4. One interesting thing to note here is that we do actually have two different DLLs now, so you can have your .NET 4 project and use a version compiled specifically for .NET 4.

Download the WPF Ribbon

Samples

This release includes several samples, including a nice MVVM sample.
RibbonWindow Wordpad Sample
This sample illustrates a Ribbon control hosted within a RibbonWindow that emulates the Wordpad appearance.
RibbonWindow MVVM Sample
This sample illustrates a Ribbon control hosted within a RibbonWindow that is completely populated from a view-model collection.

RibbonBrowser Wordpad sample
This sample illustrates a Ribbon control hosted within a browser window that emulates the Wordpad appearance.

RibbonBrowser MVVM sample
This sample illustrates a Ribbon control hosted within a browser window that is completely populated from a view model collection.