UseTrial returns TA_E_PDETS for my TurboActivate.dat

Actually all the api calles to TurboActivate returns TA_E_PDETS, how so? I already get the TurboActivate.dat into the same folder as my app.

Even if I use PDetsFromPath to set the path to the TurboActivate.dat file manually, it won't work, the PDetsFromPath returns TA_E_PDETS. What's going on here?

The TurboActivate.dat might be corrupt. Login to LimeLM and redownload it, then replace all copies you have of that file. Next, make sure TurboActivate.dat is in the same folder as TurboActivate.dll (which may or may not be the same folder as your exe file).

If you want to do custom paths then use PDetsFromPath().

The TurboActivate.dat might be corrupt. Login to LimeLM and redownload it, then replace all copies you have of that file. Next, make sure TurboActivate.dat is in the same folder as TurboActivate.dll (which may or may not be the same folder as your exe file).

If you want to do custom paths then use PDetsFromPath().

That's exactly what I did when I found out that the api calls returns TA_E_PDETS. I log in, download the .dat file, replace everything. I did it twice to make it sure.

There is one catch though, I can use this .dat file without problem in my windows machine for the same app. This mac app is the same app ported to Mac, same source code (99% the same). Is that the reason? Do I have to create another app in LimeLm to support MAC?

Things are different on Mac OS X. Namely, the *.app "file" isn't really a file, but is instead a folder structure that contains the executable in a subfolder. See: Anatomy of an OS X Application Bundle.

Short answer: put the TurboActivate.dat file in the same folder as the executable. So, inside the *.app folder (in the same folder as YourApp.app/Contents/MacOS/yourexecutable).

Does that make sense?

No, it doesn't make much sense. I haven't gone into packaging yet. And I said a few times that I did put the TurboActivate.dat along with my executable and the libTurboActivate.dylib file ( Yes, I am capable of doing that, although to my own surprise, 😉 ). I even tried to set the absolute path of the .dat file using PDetsFromPath , the PDetsFromPath call of setting the path throws the same error as the UseTrial call. I hope that you really read into the context of what my problem is. My question is that does TurboActivate work with MAC or not? I am using the latest Yosemite with MacBook Pro. Is that something that can cause problems? The thing is I don't know what I have done wrong! I followed the instructions literally, step to step, word to word, letter by letter, still having problems. Can somebody please help me out here?

My question is that does TurboActivate work with MAC or not?

Yes, it does.

1. What language are you using (C / C++ / RealStudio / etc.)?
2. If your app a console app or a GUI app? If it's a GUI app, then your compiler might be making a *.app "file" (a.k.a. a folder) automatically.
3. What version of TurboActivate are you using?
4. Give me the exact code you're using when calling PDetsFromPath().
5. Are you calling PDetsFromPath() before you call any other TurboActivate function?
6. Give me the exact return code from PDetsFromPath(). Tell me if it's in decimal or hexadecimal.

I am using it in C# with P/Invoke through Mono, I successfully called into libWkhtmlToPdf.dylib of the excellent WkHtmlToPdf project through C#/Mono/P/Invoke so I think the plumbing of Mono is working correctly. And I am doing a console app. The executable is not an .app file, but an .exe file. I am still working on the packaging (to a .app file). The fact that UseTrial call returns error code suggests that P/Invoke is working. Here is my code, please see the comments to know wha code starts executing first.

using System;using System.Diagnostics;using System.IO;

namespace BatchPDFCommand.Main.Authorization{ internal static class Licensing { public static bool IsLicensed { get { return TrialDaysRemaining > 0 || (IsProductKeyValid && IsActivated); } }

public static bool IsActivated { get { return TurboActivate.IsActivated(); } }

public static int TrialDaysRemaining { get { return TurboActivate.TrialDaysRemaining(); } }

public static bool IsProductKeyValid { get { return TurboActivate.IsProductKeyValid(); } }

public static string ProductKey { get { return TurboActivate.GetPKey(); } }

// Here is the static constructor so the below code will be called before any other methods static Licensing() { TurboActivate.VersionGUID = "21090479944cfb886acadba4.08142155"; TurboActivate.PDetsFromPath("/User/.../bin/Debug/TurboActivate.dat"); TurboActivate.UseTrial(); }

public static void Activate(string key) { if (!IsActivated) { TurboActivate.CheckAndSavePKey(key, TurboActivate.TA_Flags.TA_USER); TurboActivate.Activate(); } }

public static void Deactivate() { if (IsActivated) { try { TurboActivate.Deactivate(false); } catch (Exception ex) { Console.Error.WriteLine("Deactivation failed: " + ex.ToString()); } } else { Console.Error.WriteLine("Error: unable to deactivate when the copy is not activated"); } } }}

The return code is 8. So it doesn't matter whether it's in decimal or hexdecimal.

Ok, assuming the code is correct, then either (a) the path used in PDetsFromPath() is incorrect or (b) the TurboActivate.dat file is corrupted.

My guess is that it's (a).

(a) the path used in PDetsFromPath() is incorrect

What does this line do?:

TurboActivate.PDetsFromPath("/User/.../bin/Debug/TurboActivate.dat");

Do you get an exception? If so, which exception? Is the path actually correct? (I know the one you copied and pasted is not correct, but I assume that's just because you don't want your username on this forum). Try to open the file from a terminal session with a terminal "text editing" app using the path that's in those quotes. Does the text editor actually open a file?

(b) the TurboActivate.dat file is corrupted.

Make sure you download the TurboActivate.dat file from LimeLM directly onto that Mac. Don't use any file-transfer apps like FTP to transfer to/from your Mac because there's a chance the FTP app might be set in ASCII mode and thus corrupting the TurboActivate.dat.

Also,

3. What version of TurboActivate are you using?

a). The line just sets the path of the TurboActivate.data. I omitted the path in the middle so that the line is not too long. It should be correct since I use a Finder services to copy the path. I did get an error because the return code is 8 - thus TA_E_PDETS. If I call UseTrial without calling PDetsFromPath, I get the same error.b). No, it shouldn't be corrupted. How many times I have to guarantee that? I downloaded the file twice and replaced the file in the folder twice. If it's corrupted, it should be because the file is corrupted on the server, not on my mac. Can we get pass these basics now. I am able to download and copy file. I am capable like that. c). I assume it's the latest cause I just downloaded from your website.

Ok, then the culprit is TurboActivate.cs. Since our C# example supports only Windows, presumably you modified the TurboActivate.cs file. Show me the PInvoke line for PDetsFromPath(). Here's what it looks like for Windows:

[DllImport("TurboActivate.dll", CharSet = CharSet.Unicode, CallingConvention = CallingConvention.Cdecl)]public static extern int PDetsFromPath(string filename);

A couple things that are different from Windows & Mac OS X. Firstly, strings in Windows are double-byte UTF-16 strings, while on Unix (including Mac OS X) strings are UTF-8. Hence, TurboActivate uses UTF-16 strings on Windows and UTF-8 strings on all other platforms.

So, 1 things you must change with the DllImport lines is the "CharSet" directive. Don't use "CharSet.Unicode" (a.k.a. UTF-16 strings, a.k.a. double-byte character strings). Instead use "CharSet = CharSet.Ansi" (a.k.a. multi-byte character strings like UTF-8).

Make sense?

Yes, finally we are getting somewhere. I will try the things you pointed out. Regarding the TurboActivate.cs, I did change the DllImport part, hence the fact that the call to TurboActivate is returning values instead of throwing DllNotFound exception. I will get back to you when I get back to my MAC at home ( I am at work right now).

But I am curious why UseTrial throws error. It doesn't have any string parameter as far as I can say.

BTW, how do I paste code in like you did with highlighting and white background, etc?

BTW, how do I paste code in like you did with highlighting and white background, etc?

Only forum admins can due to limitations in the forum software.

But I am curious why UseTrial throws error. It doesn't have any string parameter as far as I can say.

Likely because the Mono runtime doesn't properly populate all the fields used by TurboActivate (for example, the location of the executable). You wouldn't run into this problem with a "native" executable on Mac OS X.

Regarding code highlighting, yeah, it's a pity that only admin can do the fancy stuff.

I think you are right about Mono not populating the fields correctly part. I tried with your suggestions, and it's working!!!!!!! But I have to call PDetsFromPath before I call UseTrial and other stuff thanks to Mono's fault. Thanks a lot. This saved my day.

BTW, how do I paste code in like you did with highlighting and white background, etc?

Only forum admins can due to limitations in the forum software.

But I am curious why UseTrial throws error. It doesn't have any string parameter as far as I can say.

Likely because the Mono runtime doesn't properly populate all the fields used by TurboActivate (for example, the location of the executable). You wouldn't run into this problem with a "native" executable on Mac OS X.

I'm glad I could help.