Hi Bernie, the SDKs have been updated and there are new ones for the new Integration API.  You can find them here:

http://www.translationzone.com/openexchange/developer/sdk.html

I can’t answer your other question I’m afraid, but I’m sure someone here can.  I’ll ask someone to take a look.

Regards

Paul

Hi, Paul.

I was using the latest materials as downloaded a week before from your site. I was not able get to the point where I needed the Integration API.

Bernie

try changing the build output path from 'roaming' to 'local'

example:

change

C:\Users\Patrick\AppData\roaming\SDL\SDL Trados Studio\11\Plugins\Packages\

to

C:\Users\Patrick\AppData\local\SDL\SDL Trados Studio\11\Plugins\Packages\

Hey, PHarnett!  That did it, and made my day!  Many thanks!

Bernie

also remember to remove that compiled plugin from the roaming folders (i.e. /packages etc...) otherwise SDL Studio will complain that they exist in both places :-)

While I now can build it into Local/..../Packages successfully, the "deployment" documentation states that I must move it (i.e., the .sdlplugin file) into Roaming/..../Packages before Trados will recognize it.  I copied what I had built into Local/.../Packages into Roaming/.../Packages, restarted Trados, and yet, I do not see it under Add-Ins->Plug-Ins  (where you say it should see two of them, in fact, it seems to see neither of them).

How can I debug this?

Thanks again

Bernie

Hi Bernie,

I had a quick chat with a developer who gave me this info that might help (based on his experience)...

I don’t think it should cause any problem compiling into the local directory and ignoring the roaming directory... seem remember testing this a while back...

Try this:

Keep the output path for the development project pointing to the local directory (for debug and release)

Roaming directory
Remove the .plugin from {roaming} /packages directory
Remove the unpacked plugin folder from the {roaming} /unpacked directory

Local directory
Leave the .plugin in the {local} /packages directory
Remove the unpacked plugin folder from the {local} /unpacked directory

Now launch Studio 2014, Studio should read your plugin correctly.

Note: Might be that you need to delete the unpacked plugin folder from the {local} /unpacked directory each time you compile a new build so that studio re-explodes the archive -> recreating that /unpacked folder from the compiled .plugin each time; think I remember coming across an issue like this a few weeks ago but can’t remember the particulars; worth a try.

if this doesn't work, then simply go back to compiling everything into the {roaming} directory again... the plugin should get compiled correctly before you receive the access violation error message; in this case remember to delete the .plugin and /unpacked folder from the {local} directories.

I hope this helps.

Regards

Paul

Hi Bernie,

I had a quick chat with a developer who gave me this info that might help (based on his experience)...

I don’t think it should cause any problem compiling into the local directory and ignoring the roaming directory... seem remember testing this a while back...

Try this:

Keep the output path for the development project pointing to the local directory (for debug and release)

Roaming directory
Remove the .plugin from {roaming} /packages directory
Remove the unpacked plugin folder from the {roaming} /unpacked directory

Local directory
Leave the .plugin in the {local} /packages directory
Remove the unpacked plugin folder from the {local} /unpacked directory

Now launch Studio 2014, Studio should read your plugin correctly.

Note: Might be that you need to delete the unpacked plugin folder from the {local} /unpacked directory each time you compile a new build so that studio re-explodes the archive -> recreating that /unpacked folder from the compiled .plugin each time; think I remember coming across an issue like this a few weeks ago but can’t remember the particulars; worth a try.

if this doesn't work, then simply go back to compiling everything into the {roaming} directory again... the plugin should get compiled correctly before you receive the access violation error message; in this case remember to delete the .plugin and /unpacked folder from the {local} directories.

I hope this helps.

Regards

Paul

None of this seems to help.  I have deleted one .sdlplugin and its sibling Unpacked directory and then the other, rebuilding to the Roaming directory (getting and ignoring the access violation message), and the plugin never shows up in 2014.

Is it possible that the fact that there is nothing in the plugin other than the resource and definition files is contributing to the problem? Shouldn't Trados say -something- if it sees the plugin and it is somehow inadequate?

Bernie

Hi Bernie,

Can you share your plugin?  I had a chat with development who are almost certain that you are missing something so they can take a quick look and see how to help.

I’m not sure I see how Studio (Trados doesn't have this capability) could say something because unless the plugin actually breaks the code there is no action to trigger anything.

Regards

Paul

Sure.  The plugin has absolutely nothing other than the template provided by your SDK to visual studio (perhaps that is the problem?), no code at all, with some of the names in the files changed appropriately.  How would you like me to package it, and to whom and how shall I send it.

You can email it zipped up to me - pfilkin@sdl.com - or just add it to your post as an attachment (choose the rich formatting option and you get more features)

Sorry Bernie... seems our over zealous IT system is stripping everything out of emails.  Can you attach it to a post here, or use dropbox maybe?  Alternatively I can give you an ftp address?

Hi bernie,

Ok - it seems to be a simple typo in the end.  I asked a developer to look and they noted that the required version in pluginpackage.manifest.xml is wrong:

<RequiredProduct name="SDLTradosStudio" minversion="14.0" />

We are at 11 right now.

Regards

Paul

Thank you.  That works now.  I mistakenly associated "2011" with "11".  Sorry for this confusion, and many thanks again.

Although it is still saying "cannot access file, used by another process", "1 failed', etc., but I am ignoring it as instructed.