XE7 C++ Package cannot compile using 64 Bit.NET Assembly Type Lib

I have an XE7 C++ Package that uses a .Net Assembly (via COM / Type LIbrary).

If I build the package with a Win32 "Target Platform", it works BUT, If I change to a Win64 "Target Platform", I get the following bcc64 compiler error

 [bcc64 Error] mscorlib_TLB.h(22889): expected ')'
  mscorlib_TLB.h(22888): to match this '('

The method in mscorlib_TLB.h that is causing this is listed below.

// *********************************************************************//
// Interface: ITrackingHandler
// Flags:     (4416) Dual OleAutomation Dispatchable
// GUID:      {03EC7D10-17A5-3585-9A2E-0596FCAC3870}
// *********************************************************************//
interface ITrackingHandler  : public IDispatch
{
public:
  virtual HRESULT STDMETHODCALLTYPE MarshaledObject(VARIANT obj/*[in]*/, 
                                                    Mscorlib_tlb::_ObjRef* or/*[in]*/) = 0; // [-1]
  virtual HRESULT STDMETHODCALLTYPE UnmarshaledObject(VARIANT obj/*[in]*/, 
                                                      Mscorlib_tlb::_ObjRef* or/*[in]*/) = 0; // [-1]
  virtual HRESULT STDMETHODCALLTYPE DisconnectedObject(VARIANT obj/*[in]*/) = 0; // [-1]


The .Net Assembly is compiled with "Any CPU".

Does anyone have an idea what might be going on?

Thanks in advance.

Best Regards,

Ignasi
0
Ignasi
7/9/2015 11:35:11 AM
embarcadero.cppbuilder.ide 2180 articles. 1 followers. Follow

4 Replies
298 Views

Similar Articles

[PageSpeed] 55

Don't know, but two thoughts...

<Ignasi Mateos> wrote in message news:728110@forums.embarcadero.com...
>I have an XE7 C++ Package that uses a .Net Assembly (via COM / Type 
>LIbrary).
>
> If I build the package with a Win32 "Target Platform", it works BUT, If I 
> change to a Win64 "Target Platform", I get the following bcc64 compiler 
> error
>
> [bcc64 Error] mscorlib_TLB.h(22889): expected ')'
>  mscorlib_TLB.h(22888): to match this '('
>
> The method in mscorlib_TLB.h that is causing this is listed below.
>
> // *********************************************************************//
> // Interface: ITrackingHandler
> // Flags:     (4416) Dual OleAutomation Dispatchable
> // GUID:      {03EC7D10-17A5-3585-9A2E-0596FCAC3870}
> // *********************************************************************//
> interface ITrackingHandler  : public IDispatch
> {
> public:
>  virtual HRESULT STDMETHODCALLTYPE MarshaledObject(VARIANT obj/*[in]*/,
>                                                    Mscorlib_tlb::_ObjRef* 
> or/*[in]*/) = 0; // [-1]
>  virtual HRESULT STDMETHODCALLTYPE UnmarshaledObject(VARIANT obj/*[in]*/,
> 
> Mscorlib_tlb::_ObjRef* or/*[in]*/) = 0; // [-1]
>  virtual HRESULT STDMETHODCALLTYPE DisconnectedObject(VARIANT obj/*[in]*/) 
> = 0; // [-1]
>
>
> The .Net Assembly is compiled with "Any CPU".
>
> Does anyone have an idea what might be going on?
>

1) Can you preprocess one of the files and examine the results, to see what 
the compiler is actually attempting to parse after pre-processing?

2) Is the formal parameter name 'or' somewhere preprocessor or otherwise 
(language extension?) defined as something (perhaps '|' or '||') that is not 
acceptable?  (Preprocessing the top-level including source file should be 
able to reveal that.)
0
david
7/9/2015 1:19:52 PM
"david hoke" <dhoke.nojunk@east-shore.com> wrote in message 
news:728114@forums.embarcadero.com...
> Don't know, but two thoughts...
>
> 2) Is the formal parameter name 'or' somewhere preprocessor or otherwise 
> (language extension?) defined as something (perhaps '|' or '||') that is 
> not acceptable?  (Preprocessing the top-level including source file should 
> be able to reveal that.)

Umm, if it turned out to be a language extension, preprocessing would 
probably not reveal that...
0
david
7/9/2015 1:41:37 PM
Hi David,

Thanks for your response, but I'm afraid I doesn't understand exactly what to look for in the preprocess result.

I've tried to attach the .i result file, but haven't been able to...

Thanks in advance,

Ignasi

> {quote:title=david hoke wrote:}{quote}
> "david hoke" <dhoke.nojunk@east-shore.com> wrote in message 
> news:728114@forums.embarcadero.com...
> > Don't know, but two thoughts...
> >
> > 2) Is the formal parameter name 'or' somewhere preprocessor or otherwise 
> > (language extension?) defined as something (perhaps '|' or '||') that is 
> > not acceptable?  (Preprocessing the top-level including source file should 
> > be able to reveal that.)
> 
> Umm, if it turned out to be a language extension, preprocessing would 
> probably not reveal that...
0
Ignasi
7/9/2015 3:05:21 PM
<Ignasi Mateos> wrote in message news:728121@forums.embarcadero.com...
> Hi David,
>
> Thanks for your response, but I'm afraid I doesn't understand exactly what 
> to look for in the preprocess result.
>

Look at those prototype declarations where the error is occurring, to see if 
something is different from the original (unpreprocessed header) file.

You can also rename the .i file appending a .cpp, and compile that (with 
same settings being used by IDE - you'll have to capture/cut/paste out of 
messages window with 'verbose' enabled, I think) and see what the compiler 
points to in that preprocessed file - hopefully that will show you what its 
choking on.

(Having said that, I will mention that IIRC, I did once have a problem 
(earlier 32bit version compilers) that would not compile properly in the 
IDE, but when fed the preprocessed file did compile that file without error.

But, I've also had them where this approach would point directly to the 
problem...
)

If the prototypes in the preprocessed file look exactly the same in 
preprocessed file as the original file, then you'll need to explore if the 
compiler is possibly supporting a language extension for the characters 'or' 
(that formal parameter name in those prototypes), possibly as a logical 
operator...

If none of this is helpful, sorry, that's all my ideas at the moment...
0
david
7/9/2015 4:03:49 PM
Reply: