|
Impact Acquire SDK .NET
|
This chapter contains a detailed description about changes in the interface that have been made, that either might break existing code or lead to the deprecation of certain functions and structures and data types.
For each release version of the interface where changes that are important for development have been introduced this chapter will contain a section that will explain as detailed as necessary what these changes are and how to modify the code to run with the latest version of the interface.
Apart from that possible impacts on existing applications will be described as well.
Normally there won't be changes that require the developer to change his code. However when changes have been made it will only take a few minutes to port code to the latest version of the interface when sticking to this document.
Functions and classes that have been declared deprecated for some time have been removed from the interface. This will not break existing binaries, but will force you to change your code during rebuilds when deprecated code was used by your application.
List of classes, functions and data types that have been removed and their replacement:
Functions and classes that have been declared deprecated for some time have been removed from the interface. This will not break existing binaries, but will force you to change your code during rebuilds when deprecated code was used by your application.
List of classes, functions and data types that have been removed and their replacement:
Functions and classes that have been declared deprecated for some time have been removed from the interface. This will not break existing binaries, but will force you to change your code during rebuilds when deprecated code was used by your application.
List of classes, functions and data types that have been removed and their replacement:
The support for the Generic interface layout has finally been removed. Please port your applications to use the interface layout mv.impact.acquire.dilGenICam instead. Systems depending on the generic interface layout will NO LONGER work starting from this version of Impact Acquire!
Functions and classes that have been declared deprecated for some time have been removed from the interface. This will not break existing binaries, but will force you to change your code during rebuilds when deprecated code was used by your application.
List of classes, functions and data types that have been removed and their replacement:
Functions and classes that have been declared deprecated for some time have been removed from the interface. This will not break existing binaries, but will force you to change your code during rebuilds when deprecated code was used by your application.
List of classes, functions and data types that have been removed and their replacement:
Functions and classes that have been declared deprecated for some time have been removed from the interface. This will not break existing binaries, but will force you to change your code during rebuilds when deprecated code was used by your application.
List of classes, functions and data types that have been removed as the products supporting them are no longer available:
Simply remove all references from your code.
Functions and classes that have been declared deprecated for a long time have been removed from the interface as they also have from the SFNC some time ago. This will not break existing binaries, but will force you to change your code during rebuilds when deprecated code was used by your application.
List of classes, functions and data types that have been removed as they have been declared deprecated for a very long time
All the features above might be accessible using the mv.impact.acquire.GenICam.TransportLayerControl.gevSupportedOptionSelector and mv.impact.acquire.GenICam.TransportLayerControl.gevSupportedOption if supported by the device.
All the features above might be accessible using the mv.impact.acquire.GenICam.DeviceControl.deviceManifestEntrySelector and other manifest table related features in the mv.impact.acquire.GenICam.DeviceControl category if supported by the device.
If the device you are using depends on any of the removed properties and does not support the recommended replacement derive from the existing classes the features have been removed from and add the features you need there. Therefore the code from an earlier release of this SDK can be used to copy most of the code from.
Raw feature uses a different unit/data type than the one without the Raw postfix. Please take care when changing your code!List of classes, functions and data types that have been removed and their replacement:
List of classes, functions and data types that have been removed and their replacement:
List of classes, functions and data types that have been moved to another namespace:
FirmwareUpdater class has moved from the mv.impact.acquire.labs namespace to mv.impact.acquire.FirmwareUpdater as it has been tested for a sufficient amount of time without any major issues. The API has been changed during that evaluation time and is supposed to be stable now. There is a suitable example as well now called FirmwareUpdate.cs. Simply remove all occurrences of the labs namespace in connection with the updater class.List of classes and functions and data types that have be removed and their replacement:
List of frame grabber specific classes that have been declared deprecated:
List of frame grabber specific data types that have been declared deprecated:
When an application has been developed using the .NET Framework version of the Impact Acquire .NET interface and this now shall be migrated to use the .NET Standard version there is really not too much to do. The first thing that must be done obviously is to migrate the application itself to .NET Standard (for libraries) or .NET Core (for applications). Essentially this boils down to recreate project files for the desired target frameworks and is described in various places on the net and therefore out the scope of this documentation. A good starting point might be this page: https://docs.microsoft.com/en-us/dotnet/core/porting/.
Once this has been done 2 more things are needed:
System.Drawing.Common package for .NET Standard is installed. This is required for allowing the Impact Acquire .NET API to return instances of the System.Drawing.Bitmap class. Refer to Efficiently create System.Drawing.Bitmap instances for details and support information.The latter requirement is also the sole reason for the Impact Acquire API being bound to the .NET Standard version 2.0 or above as with this version bitmap support was added to the .NET Standard API.
With the introduction of this interface all code inside the namespace mvIMPACT_NET.acquire in the assembly mvIMPACT_NET.dll which is part of the mvIMPACT-SDK image processing library became obsolete.
The latter implementation provides a couple of advantages:
Porting existing applications to use the mv.impact.acquire namespace will not require much work. This section will list the most important differences.
As the new interface is exported from a different assembly, this new assembly must of course also be referenced by the application:
All code previously located in the namespace mvIMPACT_NET.acquire in the assembly mvIMPACT_NET.dll is replaced by the namespace mv.impact.acquire in mv.impact.acquire.dll thus using statements must be changed for existing applications. So
becomes
Of course if only the acquire namespace has been used simply remove ALL the using statements referencing the mvIMPACT_NET assembly and remove the reference to mvIMPACT_NET.dll from your project as well! It is no longer needed then!
While the previous implementation of the acquisition interface in mvIMPACT_NET.dll did require an explicit use of the 'ref' keyword, the new interface exported by mv.impact.acquire.dll does not, thus e.g. code like this:
becomes
So by simply removing the 'ref' keyword the client code can be compiled again.
The Impact Acquire interface always requires at least one instance of the class mv.impact.acquire.DeviceManager (mvIMPACT_NET.acquire.DeviceManager previously). In the previous implementation this sometimes resulted in either strange behaviour:
or complicated code that made sure at least one device manager was present:
To address this problem this implementation now made mv.impact.acquire.DeviceManager a static class. In an application this requires a small change. Instances of mv.impact.acquire.DeviceManager must no longer be created, but its member functions must be accessed directly:
Previous code probably looked like this:
Now this can be written in a much shorter way with a defined behaviour that is no longer affected by garbage collection issues:
In case an existing application did not only use image acquisition module of mvIMPACT_NET but the image processing functions as well a slight change when creating image in a mvIMPACT-SDK compatible format is needed.
While previous code did look like this:
After porting the application to use the mv.impact.acquire.dll it will look like this:
So the mvIMPACT_NET.Image constructor must be invoked explicitly now, while the previous application did directly return the mvIMPACT_NET.Image instance. This change is one result of the decoupling of the image acquisition related part of the interface from the image processing related one.
Enumerated properties use generics now to define their data types. So e.g. code like this:
becomes
So each occurrence of
must be replaced by
