# Upgrade iCVCTextOut to?

**URL:** <https://forum.commonvisionblox.com/t/upgrade-icvctextout-to/269>\
**Category:** C-style API\
**Tags:** display, overlayplugin, textout\
**Created:** [November 15, 2017, 4:05pm UTC](https://forum.commonvisionblox.com/t/upgrade-icvctextout-to/269 "2017-11-15T16:05:48Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![DSerbee](https://avatars.discourse-cdn.com/v4/letter/d/aca169/32.png) [@DSerbee](https://forum.commonvisionblox.com/u/DSerbee)\
**Post date:** [November 15, 2017, 4:05pm UTC](https://forum.commonvisionblox.com/t/upgrade-icvctextout-to/269/1 "2017-11-15T16:05:48Z")

</div>

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().

---

<div class="post-metadata">

**Author:** ![illusive](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.commonvisionblox.com/illusive/32/61_2.png) [@illusive](https://forum.commonvisionblox.com/u/illusive)\
**Post date:** [November 15, 2017, 9:33pm UTC](https://forum.commonvisionblox.com/t/upgrade-icvctextout-to/269/2 "2017-11-15T21:33:17Z")

</div>

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:

```cpp
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).

---

<div class="post-metadata">

**Author:** ![DSerbee](https://avatars.discourse-cdn.com/v4/letter/d/aca169/32.png) [@DSerbee](https://forum.commonvisionblox.com/u/DSerbee)\
**Post date:** [November 17, 2017, 8:56am UTC](https://forum.commonvisionblox.com/t/upgrade-icvctextout-to/269/3 "2017-11-17T08:56:50Z")

</div>

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 2.4.0.0 and an indirect reference to version 2.14.0.0. Change the direct reference to use version 2.14.0.0 (or higher) of iCVCImg. xxxxx C:\Projects\xxx\xxx\xxx\Form1.vb 301 Active

How can I resolve this?

---

<div class="post-metadata">

**Author:** ![illusive](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.commonvisionblox.com/illusive/32/61_2.png) [@illusive](https://forum.commonvisionblox.com/u/illusive)\
**Post date:** [November 17, 2017, 10:07am UTC](https://forum.commonvisionblox.com/t/upgrade-icvctextout-to/269/4 "2017-11-17T10:07:02Z")

</div>

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:

```xml
  <ItemGroup>
    <Reference Include="iCVCImg, Version=2.4.0.0, 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:

```xml
  <ItemGroup>
    <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 🙂

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](https://www.jetbrains.com/decompiler/download/).
