#import " ... Resources for Visual Basic - problem

[Guest]

Hi,

Not sure if this is the right place but...I'm trying to automate InDesign CS5 to create a proof of concept prior to purchasing a bunch of licences.

I've been using VBScript to test with but in production we'll use C++ and there's the problem.

I'm trying to use #import to import the TLB and build the interfaces for me so I can start coding. But I get LOADS of errors, such as:

1>d:\indesign scripting\cpp\createtest\x64\debug\resources for visual basic.tlh(80720) : error C2370: 'InDesign::idBeforePlace' : redefinition; different storage class

1>        d:\indesign scripting\cpp\createtest\x64\debug\resources for visual basic.tlh(80718) : see declaration of 'InDesign::idBeforePlace'

1>d:\indesign scripting\cpp\createtest\x64\debug\resources for visual basic.tlh(80721) : error C2370: 'InDesign::idAfterPlace' : redefinition; different storage class

1>        d:\indesign scripting\cpp\createtest\x64\debug\resources for visual basic.tlh(80719) : see declaration of 'InDesign::idAfterPlace'

1>d:\indesign scripting\cpp\createtest\x64\debug\resources for visual basic.tlh(80725) : error C2370: 'InDesign::idBeforePlace' : redefinition; different storage class

1>        d:\indesign scripting\cpp\createtest\x64\debug\resources for visual basic.tlh(80718) : see declaration of 'InDesign::idBeforePlace'

...

Caused by code in the TLH such as:

    const BSTR idBeforePlace = (wchar_t*) L"beforePlace";

    const BSTR idAfterPlace = (wchar_t*) L"afterPlace";

    const BSTR idBeforePlace = (wchar_t*) L"beforePlace";

    const BSTR idAfterPlace = (wchar_t*) L"afterPlace";

    const BSTR idBeforePrint = (wchar_t*) L"beforePrint";

    const BSTR idAfterPrint = (wchar_t*) L"afterPrint";

    const BSTR idAfterAttributeChanged = (wchar_t*) L"afterAttributeChanged";

    const BSTR idBeforePlace = (wchar_t*) L"beforePlace";

    const BSTR idAfterPlace = (wchar_t*) L"afterPlace";

    const BSTR idBeforePlace = (wchar_t*) L"beforePlace";

    const BSTR idAfterPlace = (wchar_t*) L"afterPlace";

    const BSTR idBeforePlace = (wchar_t*) L"beforePlace";

    const BSTR idAfterPlace = (wchar_t*) L"afterPlace";

This is using VS2008 and the latest InDesign CS5 downloaded from the side a day or two ago.

Any suggestions? Is there a better way? Any help would be greatly appreciated.

russ.

[Guest]

Oh, I should add - I am NOT generating a plugin, I'm using the scripting API from C++.

[Guest]

Hi RusskieF,

I've looked at your post in the SDK forum and here (thanks to Dirk for alerting me)--I have to say, you would be better off using either the C++ API or using scripting. Attempting to somehow merge the two will only lead to pain. Even using C#, rather than C++, would be an improvement--though there are many things that you cannot do using the scripting DOM from C#.

The thing is--there's nothing wrong with the TLB from VBScript's point of view. The majority of InDesign's properties and method parameters expect to work with Variants. This loose typing is by design--a scripter, when specifying a measurement unit, should be able to use either a double or a measurement override string (for example).

If you, for whatever reason, must use C++, you would be better off using the application.doScript() method and sending strings of VBScript (or JavaScript) to the application, rather than trying to force C++ to work with loose typing.

I hope this makes some kind of sense.

Thanks,

Ole

[Guest]

Hi Olav,

Thanks for the reply.

I've used C++ to automate many applications such as Excel, Word, etc. without problem in the, using the powerful #import mechanism of Visual C++ many times. I'd love to continue using it 🙂  I have no problem with using variants, although they do lack a little flavour.

When I get time I'll take a good look at the TLB as I do believe it's broken in some way but for now work pressure has driven me to a dirty hack solution, hehe.

I'll will just generate VBS and use wscript for the automation, and use C++ for the remainder of the problems I have to solve.

russ.

[Guest]

Hi RuskieF,

Understood--I was just trying to save you time and trouble.

It's possible that there is something about the way that the TLB is constructed that causes problems for this use--if you happen to figure out what it is, please let me know.

On the events--note that they can have two forms, and that they're not exactly enums. I'm not sure how they get emitted for the TLB, exactly--our scripting libraries are made to work for all supported languages (that is, the same resources are used to build the libraries for AppleScript, JavaScript, and VBScript). One change for CS5 was to make the events visible in the VBScript model--they were not "discoverable" before. I don't know how this was done, and they do look a bit odd when viewed in a COM library browser.

Hope this helps!

Thanks,

Ole

[Dirk Becker]

With the events showing up as duplicates (probably per supporting class) one idea is to step back a version and hope the matching TLB does not have the new "feature".

Is the quoted TLH file available from some temporary build folder? You could then extract all const BSTR and sort them to eliminate duplicates.

Another approach: some C# users have managed to decode the TLB and butcher them to their needs. Probably you mean that with "good look at the TLB" ...

Finally, along your current hack: you could continue to use your prototype, advance it towards regular VB and link to that from your VC++.

Dirk

[Guest]

Thanks again guys.

I'm under pressure to provide a working solution so I don't have time for the elegance I normally enjoy 🙂

I'll stick with the generate-script-and-execute-it dirty hack and hopefully in a week or two I'll be able to revisit the problem with a view to properly automating ID.

russ.