Besides the restrictions mentioned in this section and in section “General Aspects of Code Generation”, please also check the description of the HDevelop operators in section “Menu 算子”.
In contrast to C, C++, or HDevelop, Visual Basic .NET has many reserved words. Thus, the export adds the prefix ho_ to all iconic and hv_ to all control variables, respectively, to avoid collisions with these reserved words. See also section “Variable Names” about case sensitivity.
In HDevelop, every exception normally causes the program to stop and report an error message in a dialog window. This might not be useful in Visual Basic .NET. The standard way to handle this in Visual Basic .NET is by using the Try-Catch mechanism. This allows you to access the reason for the exception and to continue accordingly. For HDevelop programs containing error handling using dev_set_check('~give_error') (or set_check('~give_error')), the corresponding code is automatically included. Every operator call, for which it is assumed that the HALCON error mechanism is turned off, is enclosed in a Try block followed by a Catch block. The latter handles the exception and assigns the corresponding HALCON error number to the error variable activated by dev_error_var or to a local error variable otherwise.
Please note that a call of dev_set_check('~give_error') has no influence on the operator call. The exception will always be raised. This is also true for messages like H_MSG_FAIL, which are not handled as exceptions in C++, for example.
The .NET Framework's runtime environment CLR (Common Language Runtime) has a mechanism called garbage collector, which is used by the CLR to remove no longer needed .NET objects from memory. As mentioned earlier, in the exported Visual Basic .NET code every iconic object is represented by a .NET HObject object. From the garbage collector's point of view, a .NET HObject object is rather small. Thus, it might not be collected from memory although the underlying iconic object (for example, an image) might in fact occupy a large portion of memory. To avoid memory leaks caused by this effect, in the exported code every iconic object is deleted explicitly before it is assigned a new value.
If the program to be exported includes the parallel execution of procedure or operator calls using par_start (see section “Parallel Execution”), the exported code requires Visual Studio 2010 or higher.