ISupportErrorInfo problems
Your test client is buggy. You are NOT supposed to use Cthe_interface.
That's the raw C++ class, and is an implementation detail the client is
not supposed to know about or rely upon. Remove #include
"...\the_interface.h", replace
Cthe_interface *intrfc_ptr = NULL;
with
Ithe_interface *intrfc_ptr = NULL;
and the test runs just fine.
You also leak a reference - after QueryInterface, you never Release
pUnk1.
--
With best wishes,
Igor Tandetnik
"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken
Quote:
> Igor (or anyone else)
> I have attached the 2nd file I promised, the calling
> driver of the component, a console C++ program, along with
> files from the build environment. You'll see that it is
> quite simple ! Do you think I am having code generation
> errors ?
> Thanks !
> Jim Trela
> >-----Original Message-----
> >Igor,
> > I added in the calls you mentioned in the return to
> >fill in the rich error info. However, I am still getting
> >an access violation when I merely try to call the method
> >in the component. I'm calling the method from a C++
> >console program. When I traced the call in the de{*filter*},
> >the values in my interface pointer variable
> ("intrfc_ptr")
> >have very small funny values, line 0x02, which (to me, at
> >least) cannot be addresses. When I call a method of a
> >component that was not created with ISupportInfo, the
> >values of "intrfc_ptr" seem normal, like addresses, when
> >viewed with QuickWatch. I went to the assembler display,
> >and saw that a specific CALL instruction was causing the
> >access violation. The register it used was loaded with an
> >unexpectedly small value.
> > I have attached my component file's source, along
> with
> >the various support files, in a ZIP file. You will see in
> >the code that it is very trivial, just having an output
> >message and a return. I will post a second message with
> >the calling driver attached.
> > Is this a code generation error ? I have had advice
> >that the order of SDK installations, or the search order
> >of include or source files are to blame.
> > I thank you very much for your help and efforts so
> >far !
> > Jim Trela
> >>-----Original Message-----
> >>Are you returning an error HRESULT from the method? If
> >the class
> >>declares that it supports error info, it must always set
> >up rich error
> >>info when reporting an error code. Use
> CComCoClass::Error
> >or
> >>AtlReportError consistently.
> >>--
> >>With best wishes,
> >> Igor Tandetnik
> >>"For every complex problem, there is a solution that is
> >simple, neat,
> >>and wrong." H.L. Mencken
> >>> I get a memory access violation when calling a method
> of
> >>> an ATL class that I created w/ ISupportErrorInfo
> >checked.
> >>> When I create a class w/o this checked, I do not get an
> >>> error when calling a method of this latter class. I
> >merely
> >>> have simple cout trace statements in these methods. Why
> >>> does this happen ? How can have ISupportErrorInfo
> >checked
> >>> and not get an access violation ? Thank you !
> >>.
