Linker Errors from XTPDocking Pane derived class

We are looking to upgrade our (rather large) product from version 8.6 to version 10.3 of the XTP toolkit (so far so good!).

 

I downloaded the "demo" version to see if I could switch it over "before I buy" (and see what cool features we get for free).

 

I am running into one problem.  In one of our DLLs, we have a class that inherits from CXTPDockingPane, and when we try to build that project, we get a set of link errors, all similar to the following:

 

LToolBox.obj : error LNK2001: unresolved external symbol "public: virtual long __thiscall CXTPAccessible::PutAccessibleValue(struct tagVARIANT,unsigned short *)" (?PutAccessibleValue@CXTPAccessible@@UAEJUtagVARIANT@@PAG@Z)

 

When I look at the header file (XTPManageState.h) that defines this method (CXTPAccessible, which is one of the multiple base classes for the XTPDockingPane), it states that these methods which generate lihnk errors are "obsolete", specifically PutAccessibleName, PutAccessibleValue.

 

We are also getting link errors on the following CXTPAccessible methods: GetAccessibleDefaultAction, GetAccessibleKeyboardShortcut, GetAccessibleHelpTopic, GetAccessibleHelp, GetAccessibleDescription, GetAccessibleValue, GetAccessibleName.

 

Are these methods not exported from the XTP export library?  Note that I am not getting any other linker errors for any other CXTPDockingPane (or base class) methods, so the linker is working.

 

I just checked our code and this is the only place where we inherit from the CXTPDockingPane class.

 

Note that we are NOT CALLING these methods, but since they are virtual, any object that I define that is derived (eventually) from CXTPAccessible must have linking knowledge of all virtual methods of any base classes.

 

If the answer is "you cannot inherit from the CXTPDockingPane with the demo version", that is totally acceptable (I plan on buying it anyway, it just gives me more ammo for justifying the purchase!!)

 

Any help would be greatly appreciated!  Thanks!!

That fixed it!

The question now becomes, is the built-in wchar_t memory size consistent with the unsigned short non-built-in type such that anything and everything that I may be using/linking (i.e. MFC, other 3rd party libraries).  Specifically, both are 16 bits long and there is no sign extension code for either "implementations".

oleg wrote: Hi,   Try to change this oiption   Configuration Properties->C/C++->Language->Treat wchar_t as Builtin Type = Yes.

Hi... forgive me for being pedantic, but when I checked this, the default setting on Visual Studio 2008 was "Yes"... are you saying "change this option" where Yes should become No, or are you saying that the option should be changed so it = Yes?

I assume the latter but I'm getting build errors when running the 13.4.2 deployment wizard, and for the error I'm getting, all signs point to this setting.

Here's the exact error from the deployment wizard:

Copyright (C) Microsoft Corporation.  All rights reserved.
Linking...
   Creating library ../../lib/vc90/ToolkitPro1342vc90D.lib and object ../../lib/vc90/ToolkitPro1342vc90D.exp
XTPReportDataManager.obj : error LNK2019: unresolved external symbol "char * __stdcall _com_util::ConvertBSTRToString(wchar_t *)" (?ConvertBSTRToString@_com_util@@YGPADPA_W@Z) referenced in function "public: char const * __thiscall _bstr_t::Data_t::GetString(void)const " (?GetString@Data_t@_bstr_t@@QBEPBDXZ)
../../bin/vc90/ToolkitPro1342vc90D.dll : fatal error LNK1120: 1 unresolved externals

property -> Linker -> Input -> Additional Dependencies