Upgrade iCVCTextOut to?

I would like to upgrade source from CVB 11.x using iCVCTextOut to the latest CVB version available. What would be the best route to go? Should I use the TextOutPlugin? If so how do I get the same font as I used in the “FontFile” of function TextInImage().

1 Like

The TextOut tool and the TextOut plugin differ fundamentally in that the TextOut tool creates destructive overlays right inside the image data (which can then also be stored in bitmap files) whereas the TextOut plugin is just an non-destructive overlay plugin for the Display Control - a pure “decoration” of the image data, if you will, which cannot be stored in a file (unless you count saving the client area of the Display Control). Which of the two use-cases are you looking for?

Is there a reason not to continue using the TextOut tool? It is still part of the current version (:cvb: 13.00.004), and since 13.00.000 it is even available as a 64 bit build and for the Linux platforms.

Finally, if you want to select the font that the TextOut plugin is using, please have a look at the TTextOutPlugInData structure:

struct TTextOutPlugInData
  cvbval_t    nFontSize;      // Defines the size of the font
  cvbuint32_t nFontWeight;    // font weight as defined by the FW_ values above
  cvbval_t    nRotation;      // Defines angle of rotation of the text
  cvbuint32_t dwItalic;       // Defines italic text
  cvbuint32_t dwUnderline;    // Defines underlined text
  char*       lpstrFontname;  // Defines the Font name
  char*       lpstrTextOut;   // Defines the Text to be displayed
  STRINGTYPES nStringType;    // string type
  MARKERFLAGS dwFlags;        // marker

The lpstrFontname string is where you can pass the font name to be used (unlike the TextOut tool, the TextOut plugin directly uses any installed TTF font).

1 Like

I thought the TextOut was obsolete, sorry for this.

Trying to use the TextOut in the existing project compiling with version 13.00.000 (64 bit) gives me this version conflict on the iCVCimg :

Error BC32207 The project currently contains references to more than one version of ‘iCVCImg’, a direct reference to version and an indirect reference to version Change the direct reference to use version (or higher) of iCVCImg. xxxxx C:\Projects\xxx\xxx\xxx\Form1.vb 301 Active

How can I resolve this?

This is, unfortunately, not an uncommon occurrence. The iTextOut.dll - like all the .Net wrapper DLLs in :cvb: except the CVCError.dll - has a dependency on the iCVCImg.dll of the same release. In case of :cvb: 13.00.000 (side note: Please consider switching to 13.00.004…) that means the iTextOut.dll version 2.4.x.x depends on iCVCImg.dll version 2.14.x.x.

iCVCImg.dll version 2.4.x.x was shipped with :cvb: 11.01.000. So if the project was generated with 11.01.000 and the iCVCImg.dll dependency was added back then, Visual Studio will have added a reference to the specific version of the iCVCImg.dll that you had installed back then (this is the default behaviour). You can verify this by opening the *.csproj or *.vbproj file in a text editor and looking for the <Reference Include> tags:

    <Reference Include="iCVCImg, Version=, Culture=neutral, PublicKeyToken=..., processorArchitecture=MSIL" />

Most of the time this does not hurt, because :cvb: installs all the wrapper DLLs back to version 11.00.000 (this is for the customers’ convenience, because that way they have a chance of simply deploying their C# or VB.Net application to a new CVB installation and run it). But if you now add the iTextOut.dll reference to this project, it’ll refer the latest build of the iTextOut.dll and the latest iTextOut.dll expects the iCVCImg.dll version 2.14.x.x - hence the warning.

The same warning can also arise in more complex scenarios where you can e.g. build a class library that depends on iCVCImg.dll version 2.4.x.x and use it in a project that uses an up-to-date tool wrapper like iTextOut.dll which depends on the up-to-date iCVCImg.dll - the same warning would pop up (although judging from the text of the warning that you posted I’d guess that you are in the previously described scenario).

My recommendation is to entirely remove the additional information in the <Reference Include> tags. To stay with the example from above: Simply modify this entry to look like this:

    <Reference Include="iCVCImg" />

This way, Visual Studio will make your executable dependent on the most recent versions of the referenced DLLs available on your system, and unless we messed up the dependencies ourselves you should not see this warning any more. What’s also worth noting is that although run-time errors arising from a mix of different versions of referenced .Net DLLs are among the most insidious problems when debugging a .Net application, mixing different versions of :cvb: wrapper DLLs most often will not cause trouble due to the simple interface exported by them. Having said that: Mixing the iCVCImg.dll from :cvb: 11.01.000 with tool wrappers from :cvb: 13.00.000 is probably not the best idea :slightly_smiling_face:

Last comment: If you want to find out what specific DLL versions a given .Net .exe _ or _.dll file references you can either use ildasm or, if you want something more shiny, have a look at JetBrains dotPeek.