Forum

First of all, let me say well done for a great library. However, I expect (a lot) more improvement in documentation field. The help file you gave in trial version doesn’t cover a lot of classes.

I tried to use prof-uis freeware 2.21 with a MFC program.
The project is configured to use MFC in static library and Unicode text.

Before I’ve gone too far, I am getting a linking error in Debug build (haven’t tried Release yet) as follows:

test_mfc.obj : error LNK2019: unresolved external symbol "public: bool __thiscall CExtCmdManager::ProfileSetup(wchar_t const *,struct HWND__ *,class CExtCmdProfile *)" (?ProfileSetup@CExtCmdManager@@QAE_NPB_WPAUHWND__@@PAVCExtCmdProfile@@@Z) referenced in function "public: virtual int __thiscall Ctest_mfcApp::InitInstance(void)" (?InitInstance@Ctest_mfcApp@@UAEHXZ)
Debug/test_mfc.exe : fatal error LNK1120: 1 unresolved externals

Note that if I change the text setting to either ANSI or MBCS, it links and runs properly. Can you see what’s wrong?

Note that I built the library and my mfc program in Visual Studio .NET 2003. I’ve built all different versions of library successfully (including the Static Unicode Debug) without any error.

Also note that if I use Static Unicode Debug with MFC DLL (using MFC shared library in my MFC program), I get more unresolved symbols.

Hi,

Thank you for your interest.

I built all the libraries and samples under VC++ 6.0 / VC++ .NET - 2002 / VC++ .NET - 2003 before publishing them. I have also checked the library in my current projects. All is OK. Probably the problem hides somewhere else. Please send me a letter with your (real or sample) project to l_sergiy@fossware.com so that I can find the cause of the problem.

As for the help, some classes are omitted because the toolbar/menu/keyboard customization subsystem is not finished yet.

Best regards, Sergiy.

Hi, I think I’ve found the culprit. You can try this with any of the sample program under Static Unicode Debug build.
(Assuming you’re running VC 7.1, don’t know about VC 7, maybe I think it’s there too)
Go to Project Properties -> C/C++ -> Language
Select Treat wchar_t as Build-In Type to Yes.
Rebuild.
You’ll see the linking error.

The problem is that this option is Yes by default when you create a new MFC project using VC7/VC7.1.

Have a look at /Zc on MSDN for a comment on how to create libraries that can easily be linked with code compiled with or without /Zc:wchar_t and avoid the need to provide two different builds of the library (one with and one without /Zc:wchar_t enabled).

Cheers.

Hi,

First of all I must note: Your question is the most interesting question since Prof-UIS was published. Thank you.

Microsoft says "By providing overloads for both the unsigned short and __wchar_t variations of wchar_t, you can create libraries that can easily be linked with code compiled with or without /Zc:wchar_t and avoid the need to provide two different builds of the library (one with and one without /Zc:wchar_t enabled)". I am not sure "overloads" for the thousands class methods is the easy way.

If you try to create your small test MFC extension library with at least one exported class you can face these problems (with Unicode build, using withing EXE project based on the different /Zc:wchar_t option):

1) you should provide overrides for each method which have TCHAR, LPTSTR or LPCTSTR parameters or return value
2) you will have unresolved problems with virtual methods which are based on TCHAR, LPTSTR or LPCTSTR parameters/return value
3) you will need to replace public properties of these types with the get/set methods that are also should have overrides :-)
4) the same problems with the message handler classes
5) CString class is based on the ATL::CStringT<TCHAR> template class, so you can multiply the problems 1-4 by two !! :-)
6) the CStringArray, CStringList, CMapStringToPtr, CMapStringToOb and CMapStringToString classes are linked with CString, so you can multiply the problems 1-5 by ??? !!!
7) the problem list is stopped at this point, that’s enough for the one message in this forum

============================
Q.A.
============================

Why this problem appear?
Each exported name of the function, variable or class method includes encoded signatures for each parameter and return value. If you using the native wchar_t type - each exported name will include signatures for this native type. If you NOT using the native wchar_t type - each exported name will include signatures for the unsigned short type.

Is it possible to solve this problem?
Yes.

Is it possible to solve this problem easily?
Not. Exactly not.

How MFC solves this problem?
MFC provides an alternative stub library mfcsubs.lib which includes names for all the wchar_t-based class methods but with the unsigned short signatures. But I don not know how to create the same library for Prof-UIS. I even have no idea about where to find a tool/utility program’s for this task.

Is it possible to solve this problem using any other way?
Yes. I have done it. Without any stubs. Without any overloads. I have spent 3 days to find the pure C++ method. I will not open you the secret now :-) but the solution will be provided with the next version of the library soon. Currently please use the Unicode-compiled Prof-UIS libraries with the /Zc:wchar_t option same as your project.

Best regards,
Sergiy.