License code for Version 3.6 not working

[Uwe Keim]

I just upgraded from VPE 3.5 standard to VPE 3.6 standard.

When using the new license code (which starts with "VPE-S2360-****") it still prints "DEMO VERSION" on top of the preview window.

Question: Is there a way to further investigate why it does not accept the license code? (i.e. some kind of verbose mode/trace output to read)

Thanks
Uwe

[IDEAL Software Support]

Your v3.60 license key will unlock VPE v3.60. Except you are trying to unlock the wrong edition (e.g. the Professional Edition) with your key, which is for the Standard Edition.

Another cause might be that you are using VPE in a server environment, in this case VPE will not unlock unless you have acquired and installed additional server license keys.

Regards
Thorsten Radde
IDEAL Software GmbH

[Uwe Keim]

The DLL that is being used is "vpes3236.dll", so I assume "S" stands for "standard".

The application is on a share on a server, but my application is running on Windows XP Professional workstation.

Version 3.5 was in the same environment and was successfully unlocked. (Of course with 3.5 license keys).

Question: Does Version 3.6 behaves different in the environment described above?

Thanks
Uwe

[IDEAL Software Support]

> Question: Does Version 3.6 behaves different in the environment described above?

No, VPE behaves the same.

I don't know why your unlocking does not work, maybe you are loading the wrong DLL into your application. I assume the key worked when entering it during the setup?

Regards
Thorsten Radde
IDEAL Software GmbH

[Uwe Keim]

Ha! solved it .

It is the same issue I had with Unicode here: http://idealsoftware.com/phpBB2/viewtopic.php?t=169

I was passing the license code in my Unicode-application as CString-objects. Again, the VpeLicense function expects LPCTSTR (i.e. Unicode-pointers) that are actually LPCSTR (i.e. Ansi-pointers).

When I internally convert my Unicode-CStrings to Ansi CStrings, it works.

[IDEAL Software Support]

Please let me correct you.

LPCWSTR declares a pointer to a unicode string, while LPCTSTR does not. The T-macros of the Windows API depend on the compiler settings, whether the expanded macros are for unicode or ANSI. Since VPE is compiled for ANSI, the LPCTSTR declarations definitely declare pointers to ANSI strings.

Regards
Thorsten Radde
IDEAL Software GmbH

[Uwe Keim]

Form a VPE-library-developer's point-of-view you are correct.

But when compiling my VPE-consuming application with _UNICODE defined and including your "vpiface.h", the LPCTSTRs become LPCWSTR.

And I do see no #undef _UNICODE in "vpiface.h".

Or am I understanding something wrong?

[IDEAL Software Support]

The mistake is that you might think all functions which take LPCTSTR parameters should exist twice in the VPE-DLL. But they can't, because they exist only once. So to ship a unicode enabled version, the VPE-DLL would need to have a different name when compiled for unicode. But there is no such DLL currently available.

Regards
Thorsten Radde
IDEAL Software GmbH