472,127 Members | 1,886 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,127 software developers and data experts.

Accessing COM Component arguments defined by "ref", after it raise COM+ error

Hi,

I have defined interface for COM components which inludes an argument being
filled with additional error info, if such occurs. If inside I raise COM
Error, I populate that parameter.
In COM environment this architecture works beautifully -- caller application
gets negative HRESULT and error description from IErrorInfo object, and
additional "log" information from that "ref" parameter:

In .Net it just never returns that paramter populated!
Can any one help?

COM IDL declaration:
HRESULT MyFunction([in] LONG lngA, [in] LONG lngB, [in, out] BSTR
*bstrLog)

In C++ Code:
.....
// error happened --> raise COM Error, fill log
*bstrLog = SysAllocString("something bad happened");
IErrorInfo *pErr ........ //code to raise error.
.....

In .Net

MyLib.MyClass objFunc = new MyLib.MyClass()

string strLog = "";
try
{
objFunc.MyFunction(12, 34, ref strLog);
}
catch(System.Runtime.InteropServices.COMException ex)
{
string strErrMesg = ex.Message;
long hr = ex.ErrorCode;
MessageBox.Show(strLog); // <<==== always empty --- seems .Net looses
information.
}

Thanks
Dmitry
Jul 21 '05 #1
3 1872
First of all HRESULT types don't exist in the .NET Framework so they become
32-bit integers in managed code with the MarshalAs attribute applied.

HRESULT Foo([in] HRESULT hr)

gets marshaled as:

public virtual Foo([MarshalAs(UnmanagedType.Error] int hr);

Any success HRESULT values are swallowed by the RCW and the values are
unattainable from .NET clients unless the managed signature coresponding to
the method returning the HRESULT is marked with the PreserveSigAttribute
pseudo-custom attribute.

This all turns out to be a pain so you you shouldn't write interfaces like
this if you plan to call them for managed clients. Instead the CLR takes the
Exception object's properties with data from the COM error object. So
instead of your strLog variable which didn't get marshaled correctly and
swallowed, you should be looking in and printing out the ex properties like
ex.Message which gets stuffed with IErrorInfo.GetDescrription and Ex.Source
which is the string returned from IErrorInfo.GetSource.

HTH,
--
Sam Gentile [C#/.NET MVP]
..NET Blog http://samgentile.com/blog/
MSDN Column:
http://msdn.microsoft.com/library/de...tml/bridge.asp
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dmitry" <dk***********@fmco.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Hi,

I have defined interface for COM components which inludes an argument being filled with additional error info, if such occurs. If inside I raise COM
Error, I populate that parameter.
In COM environment this architecture works beautifully -- caller application gets negative HRESULT and error description from IErrorInfo object, and
additional "log" information from that "ref" parameter:

In .Net it just never returns that paramter populated!
Can any one help?

COM IDL declaration:
HRESULT MyFunction([in] LONG lngA, [in] LONG lngB, [in, out] BSTR
*bstrLog)

In C++ Code:
....
// error happened --> raise COM Error, fill log
*bstrLog = SysAllocString("something bad happened");
IErrorInfo *pErr ........ //code to raise error.
....

In .Net

MyLib.MyClass objFunc = new MyLib.MyClass()

string strLog = "";
try
{
objFunc.MyFunction(12, 34, ref strLog);
}
catch(System.Runtime.InteropServices.COMException ex)
{
string strErrMesg = ex.Message;
long hr = ex.ErrorCode;
MessageBox.Show(strLog); // <<==== always empty --- seems .Net looses
information.
}

Thanks
Dmitry

Jul 21 '05 #2
Sam,

strLog -- may contain from 1 to 10 K of data, depending on number of
errors, warnings coming from COM object. so packing that data in ErrorInfo
properties might be waste of resource.
Code is written for interaction within COM environment, but now I am looking
in compatibility with .Net callers.

"Sam Gentile [MVP]" <sa*@nomail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
First of all HRESULT types don't exist in the .NET Framework so they become 32-bit integers in managed code with the MarshalAs attribute applied.

HRESULT Foo([in] HRESULT hr)

gets marshaled as:

public virtual Foo([MarshalAs(UnmanagedType.Error] int hr);

Any success HRESULT values are swallowed by the RCW and the values are
unattainable from .NET clients unless the managed signature coresponding to the method returning the HRESULT is marked with the PreserveSigAttribute
pseudo-custom attribute.

This all turns out to be a pain so you you shouldn't write interfaces like
this if you plan to call them for managed clients. Instead the CLR takes the Exception object's properties with data from the COM error object. So
instead of your strLog variable which didn't get marshaled correctly and
swallowed, you should be looking in and printing out the ex properties like ex.Message which gets stuffed with IErrorInfo.GetDescrription and Ex.Source which is the string returned from IErrorInfo.GetSource.

HTH,
--
Sam Gentile [C#/.NET MVP]
.NET Blog http://samgentile.com/blog/
MSDN Column:
http://msdn.microsoft.com/library/de...tml/bridge.asp Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights. "Dmitry" <dk***********@fmco.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Hi,

I have defined interface for COM components which inludes an argument

being
filled with additional error info, if such occurs. If inside I raise COM
Error, I populate that parameter.
In COM environment this architecture works beautifully -- caller

application
gets negative HRESULT and error description from IErrorInfo object, and
additional "log" information from that "ref" parameter:

In .Net it just never returns that paramter populated!
Can any one help?

COM IDL declaration:
HRESULT MyFunction([in] LONG lngA, [in] LONG lngB, [in, out] BSTR
*bstrLog)

In C++ Code:
....
// error happened --> raise COM Error, fill log
*bstrLog = SysAllocString("something bad happened");
IErrorInfo *pErr ........ //code to raise error.
....

In .Net

MyLib.MyClass objFunc = new MyLib.MyClass()

string strLog = "";
try
{
objFunc.MyFunction(12, 34, ref strLog);
}
catch(System.Runtime.InteropServices.COMException ex)
{
string strErrMesg = ex.Message;
long hr = ex.ErrorCode;
MessageBox.Show(strLog); // <<==== always empty --- seems .Net looses information.
}

Thanks
Dmitry


Jul 21 '05 #3
I am describing what the COM Interop marshaler does to your COM types in
..NET. You *don't* get a choice (unless you write a custom RCW or marshaler)

--
Sam Gentile [C#/.NET MVP]
..NET Blog http://samgentile.com/blog/
MSDN Column:
http://msdn.microsoft.com/library/de...tml/bridge.asp
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dmitry" <dk***********@fmco.com> wrote in message
news:O6**************@TK2MSFTNGP09.phx.gbl...
Sam,

strLog -- may contain from 1 to 10 K of data, depending on number of
errors, warnings coming from COM object. so packing that data in ErrorInfo
properties might be waste of resource.
Code is written for interaction within COM environment, but now I am looking in compatibility with .Net callers.

"Sam Gentile [MVP]" <sa*@nomail.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
First of all HRESULT types don't exist in the .NET Framework so they

become
32-bit integers in managed code with the MarshalAs attribute applied.

HRESULT Foo([in] HRESULT hr)

gets marshaled as:

public virtual Foo([MarshalAs(UnmanagedType.Error] int hr);

Any success HRESULT values are swallowed by the RCW and the values are
unattainable from .NET clients unless the managed signature coresponding

to
the method returning the HRESULT is marked with the PreserveSigAttribute
pseudo-custom attribute.

This all turns out to be a pain so you you shouldn't write interfaces like
this if you plan to call them for managed clients. Instead the CLR takes

the
Exception object's properties with data from the COM error object. So
instead of your strLog variable which didn't get marshaled correctly and
swallowed, you should be looking in and printing out the ex properties

like
ex.Message which gets stuffed with IErrorInfo.GetDescrription and

Ex.Source
which is the string returned from IErrorInfo.GetSource.

HTH,
--
Sam Gentile [C#/.NET MVP]
.NET Blog http://samgentile.com/blog/
MSDN Column:

http://msdn.microsoft.com/library/de...tml/bridge.asp
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no

rights.
"Dmitry" <dk***********@fmco.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Hi,

I have defined interface for COM components which inludes an argument

being
filled with additional error info, if such occurs. If inside I raise COM Error, I populate that parameter.
In COM environment this architecture works beautifully -- caller

application
gets negative HRESULT and error description from IErrorInfo object, and additional "log" information from that "ref" parameter:

In .Net it just never returns that paramter populated!
Can any one help?

COM IDL declaration:
HRESULT MyFunction([in] LONG lngA, [in] LONG lngB, [in, out] BSTR
*bstrLog)

In C++ Code:
....
// error happened --> raise COM Error, fill log
*bstrLog = SysAllocString("something bad happened");
IErrorInfo *pErr ........ //code to raise error.
....

In .Net

MyLib.MyClass objFunc = new MyLib.MyClass()

string strLog = "";
try
{
objFunc.MyFunction(12, 34, ref strLog);
}
catch(System.Runtime.InteropServices.COMException ex)
{
string strErrMesg = ex.Message;
long hr = ex.ErrorCode;
MessageBox.Show(strLog); // <<==== always empty --- seems .Net

looses information.
}

Thanks
Dmitry



Jul 21 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.