Adobe ExternalObject Dll

Adobe allows loading of dll's as objects through their ExtendScript (jsx). I have their sample Visual Studio project and the LimeLM example project that both work fine on their own. When I try to include the C example code into the Adobe sample project, it compiles without error. When I try to load it, I get a not-so-descriptive "I/O error". The offending line is the call to IsGenuineEx.

I feel like I'm missing a setting somewhere (I am new to C++).

To sum up: I am making a dll that uses TurboActivate.dll. Are there any special considerations to make in that situation?

Sam

When I try to load it, I get a not-so-descriptive "I/O error".

What do you mean? What's the exact error code (the number) that IsGenuineEx() is giving?

Ah, the error happens in Adobe's ExtendScript Toolkit when I try to load the the dll that is wrapping TurboActivate.dll.The uniformative error is Adobe's.

My question is more a matter of using TurboActivate.dll in another dll. I tried wrapping a dll based on an example in the VS help, and it worked. Of course, that base dll was simple in its structure. I was wondering if there was a setting to change when converting your Example project from an Application (.exe) to a library (.dll).

Sam

Well, I succeeded in making a dll > dll > exe chain. The base dll was based on your C example project. The second dll called an exported function. The exe called a simple function exported from the wrapper dll.

The problem (unsurprisingly) is in the integration with Adobe. I'll keep hammering on it.

Sam

OK. 🙂

Since I was able to load a simple dll through Adobe's sample project dll, maybe it's an issue of C vs C++. I'm not sure I'll be able to discern that.

If you give us more information about an error we'll be able to help you. If you're making another DLL, your best bet is to use the static libraries version of TurboActivate.

Sadly, "I/O Error" is as much information as I get back from Adobe's ExtendScript Editor. From what I've read, usually that's a matter of people mixing 32- and 64-bit parts.

Thanks for the suggestion of the static library. I will give it another try.

Sam

Well, I have something working in as far as it doesn't crash.

However, now I'm stuck with a TA_E_PDETS return code. The dat file is in the same folder as the dll. I tried specifying with PDetsFromPath, but the result was the same.

Sam

Is there a way to ask where the dll is currently looking for the dat file?

No, but you can tell it using PDetsFromPath(). Call that before you call any other TurboActivate function.

Is this the correct form?

hr = PDetsFromPath((STRCTYPE)"C:/TurboActivate.dat");

I get the same return code,TA_E_PDETS, from that.

Okay, after digging around the forum some more I found this:-- PDetsFromPath(L"C:\\Users\\...\\TurboActivate.dat");

Notice the "L" before the opening quote of the string. That marks the string as a UTF16 string for the compiler.--

And now it works. On to the the next step.

Are they supposed to be the same value?

From TurboActivate.h :

/* MessageId: TA_E_TRIAL_EEXP

MessageText:

The trial extension has expired.*/#define TA_E_TRIAL_EEXP ((HRESULT)0x0000000DL)

/* MessageId: TA_E_EXPIRED

MessageText:

The activation has expired or the system time has been tampered with. Ensure your time, timezone, and date settings are correct.*/#define TA_E_EXPIRED ((HRESULT)0x0000000DL)

Are they supposed to be the same value?

Yes.

Reply
Discard post