This topic contains the following sections.
- VisionPro QuickStart and Tool Edit Control Differences
- Results Analysis is a Tool in .NET
- VB Script Is Not Available in .NET
- Using Previously Saved Tool Groups in QuickBuild
- Behavior of Reset and Load from File Buttons Differs from COM to .NET
- VisionPro Programming Differences
- Garbage Collection and Memory Handling
- Event Handling Is Different in .NET
- Automatic Tool Creation On By Default in .NET
- Some Properties Become Set/Get Methods in .NET
- Most Constants Have New Names
- Multi-dimensional Array Index Ordering Differs Between VB6 and .NET Languages
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 no longer includes a .NET version of QuickStart. Instead, you can use QuickBuild. In most cases, you can import saved QuickStart projects into QuickBuild.
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.
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.
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:

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.

Use the CogResultsAnalysis Tool in QuickBuild to recreate the results analysis settings.
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.
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++.
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.
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:
| COM Event Name | .NET Event Name |
| Change | Changed |
| PreRun | Running |
| PostRun | Ran |
| ItemAdded | InsertingItemInsertedItem |
| Cleared | ClearingCleared |
| ItemReplaced | ReplacingItemReplacedItem |
| KeyChanged | KeyChangingKeyChanged |
| ItemMoved | MovingItemMovedItem |
| ItemRemoved | RemovingItemRemovedItem |
| none | ReplacingItemReplacedItem |
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.
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 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.
| COM Constant Name | .NET Constant Name |
| CogAcqSyncModelConstants.cogAcqSyncModelInternalDrive | CogAcqSyncModelConstants.InternalDrive |
| CogBarcodeRSSTypeConstants.cogBarcodeRSSType2DComposite | CogBarcodeRSSTypeConstants.Type2DComposite |
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.