Migrating from COM to .NETCognex VisionPro

This topic contains information that may be useful to you as you migrate from COM-based VisionPro (VisionPro 4.0 and earlier) to .NET-based VisionPro. Starting with VisionPro 4.1 Cognex discontinued support for COM altogether, including the tool edit controls, the API, and some utilities.

See VisionPro Programming Differences to learn about important differences between programming VisionPro under COM and .NET.

VisionPro QuickStart and Tool Edit Control Differences

VisionPro no longer includes a .NET version of QuickStart. Instead, you can use QuickBuild. In most cases, you can import saved QuickStart projects into QuickBuild.

Results Analysis is a Tool in .NET

In the COM version, the Results Analysis window was part of the Tool Group Edit Control. In the .NET version Results Analysis is a tool.

VB Script Is Not Available in .NET

The .NET version of the ToolGroup Edit Control does not support VB Script. However, a much more extensive scripting facility that gives you access to the entire .NET framework is available in VisionPro. See Scripting in QuickBuild to learn more.

Using Previously Saved Tool Groups in QuickBuild

Generally speaking, you can use the File->Import ToolGroup command in QuickBuild to import tool group (.VPP) files the you saved with earlier versions of QuickStart as individual jobs. The differences between COM and .NET, however, mean that some aspects of tool groups created with COM may not be imported completely.

Some non-default terminals cannot be converted to QuickBuild. In particular, terminals that expose indexed results will not be converted unless you saved the tool group with results. When you load a tool group saved with the COM version, you may see an error message like this:

Migrating terminalsfail

The ToolGroupUpgradeError.txt named in the error message contains the names of the terminals that could not be converted. After you run the tool once, you will be able to add the terminals.

If your COM-based tool group used Results Analysis, you will see this error message.

Migrating resultsfail

Use the CogResultsAnalysis Tool in QuickBuild to recreate the results analysis settings.

Behavior of Reset and Load from File Buttons Differs from COM to .NET

In the earlier COM versions of VisionPro, when you clicked the Reset to Initial State button or the Load from File button in a VisionPro tool edit control, the existing COM tool to which the tool edit control is connected was either reset to its default state or initialized using the contents of a file. Any other objects, including the tool edit control, that had a reference to the tool could continue to manipulate the tool using the existing reference.

With VisionPro .NET, this behavior is not supported. Instead, whenever you click the Reset to Initial State button or the Load from File button, the existing .NET tool is released and a new tool is created and initialized. The VisionPro tool edit control's reference to the tool is automatically updated , but any other objects in your application that might have references to the old .NET tool will no longer be referring to the same tool as the edit control.

To help your application deal with this change, VisionPro .NET edit controls fire two events: SubjectChanging and SubjectChanged. By listening to these events, your application can make sure to update any tool references that might be changed as a result of the user clicking those buttons.

VisionPro Programming Differences

While the majority of the VisionPro .NET API remains the same as in the COM version, the sections that follow describe some issue that you are likely to encounter as you migrate to the .NET version of VisionPro.

For general information about the .NET Framework and Visual Studio .NET see Introducing Visual Studio .NET which also includes links to topics concerning upgrading from Visual Studio 6.0 and C++.

Garbage Collection and Memory Handling

The .NET Framework handles the allocation and freeing of memory automatically. There are, however, some issues relating to VisionPro that you should be aware of. Be sure to read Memory Management in VisionPro.

Event Handling Is Different in .NET

The .NET version of VisionPro uses a different event-handling model than the COM version. You can learn more in About Events in VisionPro and see examples in Using Changed Events and Writing a Drag Event Handler.

In addition to the differences in event handling, the names of some events have changed:

Table 1. Changes in Event Names
COM Event Name.NET Event Name
ChangeChanged
PreRunRunning
PostRunRan
ItemAddedInsertingItemInsertedItem
ClearedClearingCleared
ItemReplacedReplacingItemReplacedItem
KeyChangedKeyChangingKeyChanged
ItemMovedMovingItemMovedItem
ItemRemovedRemovingItemRemovedItem
noneReplacingItem

ReplacedItem

Automatic Tool Creation On By Default in .NET

In the COM version of VisionPro, edit controls that you create and add to a form programmatically have the AutoCreateTool property set to False. In the .NET version, this property is set to True. If you want to prevent the edit control from creating the underlying vision tool automatically when you add it to a form you must set this property to False before you add it to the form.

Some Properties Become Set/Get Methods in .NET

COM properties that take parameters are implemented as Set and Get methods in .NET. For example, the COM property ICogAcqLookupTable.LookupTable is implemented as the .NET methods SetLookupTable and GetLookupTable

Most Constants Have New Names

Most of the enumeration constants have new names in the .NET version of VisionPro. In general, the "prefix" part of the COM constant has been stripped off. The only exception is when stripping the prefix would result in a constant whose name starts with a number. The following table shows some examples.

Note: When you use the .NET constants, you generally provide the enumeration name.

Table 2. Enumeration Constant Name Changes Examples
COM Constant Name.NET Constant Name
CogAcqSyncModelConstants.cogAcqSyncModelInternalDriveCogAcqSyncModelConstants.InternalDrive
CogBarcodeRSSTypeConstants.cogBarcodeRSSType2DCompositeCogBarcodeRSSTypeConstants.Type2DComposite

Multi-dimensional Array Index Ordering Differs Between VB6 and .NET Languages

The ordering of array indices is different between Visual Basic 6 and all .NET languages. The following code illustrates the differences.

Visual Basic 6 code

Dim objPoly2 As CogPolygon
Set objPoly2 = New CogPolygon
objPoly2.AddVertex 1, 2
objPoly2.AddVertex 3, 4
objPoly2.AddVertex 5, 6

Dim aPts2() As Double
aPts2 = objPoly2.GetVertices
' At this point aPts2 is set as follows:
' aPts2(0, 0) = 1
' aPts2(1, 0) = 2
' aPts2(0, 1) = 3
' aPts2(1, 1) = 4
' aPts2(0, 2) = 5
' aPts2(1, 2) = 6

Visual Basic .NET code

Dim objPoly2 As CogPolygon
objPoly2 = New CogPolygon
objPoly2.AddVertex(1, 2, -1)
objPoly2.AddVertex(3, 4, -1)
objPoly2.AddVertex(5, 6, -1)

Dim aPts2(,) As Double
aPts2 = objPoly2.GetVertices()
' At this point aPts2 is set as follows:
' aPts2(0, 0) = 1
' aPts2(0, 1) = 2
' aPts2(1, 0) = 3
' aPts2(1, 1) = 4
' aPts2(2, 0) = 5
' aPts2(2, 1) = 6

As you can see, the indices of the array named aPts2 are reversed between Visual Basic 6 and Visual Basic .NET.