Mark,

If MyServer does not care what the values in the ppvData than
it is better if MyServer will allocate an array. Also, if you're
using VARIANT to return data because you have scripting client
in mind, you must change DWORD parameter to Automation-compliant
type, such as long. In addition, it will be better if dwNumItems
will be [in, out] long* plNumItems where initial value passed to
MyServer will be a desired maximum number of elements returned by
MyServer. On exit from GetSomeData this parameter will hold the
actual number of elements in the returned array.

One thing I don't understand. In your question you stated that
ppvData is a pointer to an array of VARIANTs and dwNumItems is
the size of the array. If it's true than you're in trouble once
marshalling will take place because marshaller does not have
the knowledge about the size of the array, unless you put this info
in the .idl file in method signature.
If ppvData is a VARIANT which holds a SAFEARRAY(VARIANT) then there is
no need in dwNumItems.

Regards,

Alex Shevchuk

> -----Original Message-----
> From: Mark Jordan [mailto:mark.jordanEXELONCORP.COM]
> Sent: Wednesday, February 20, 2002 8:36 AM
> To: DCOMDISCUSS.MICROSOFT.COM
> Subject: Common Practice
>
>
> Given a function that looks like this:
>
> HRESULT MyServer::GetSomeData(DWORD dwNumItems, VARIANT * ppvData);
>
> ...where dwNumItems is the number of VARIANTS in the array
> pointed to by
> ppvData, ie, the caller allocates the array for the data to
> be returned.
>
> Question:
> Should the server initialize the each of the VARIANTs in the array by
> calling VariantInit?
>
>
>
>
> > -----Original Message-----
> > From: Vagish Kalligudd [SMTP:vagish.kalliguddCELSTREAM.COM]
> > Sent: Friday, February 15, 2002 8:26 AM
> > To: DCOMDISCUSS.MICROSOFT.COM
> > Subject: Re: RPC Exception, Subsequent Calls Hang
> >
> > Your error code 0x80010105 indicates that the server is
> throwing a C++
> > exception. You can enable exception handling. If you are
> using ATL you can
> > use ATLTRY to bracket all code that could possibly throw
> exceptions. If
> > you
> > want to catch memory access violations using catch(...)
> enable /EHa on
> > Visual C++.
> >
> >
> > Quote from MSDN
> > COM and C++ Exceptions
> >
> --------------------------------------------------------------
> ------------
> > --
> > ----
> > COM will not propagate a C++ exception from the callee to
> the caller,
> > even
> > when both the caller and the callee are written in C++.
> This catches some
> > COM newcomers off guard, but it should be no surprise if
> you recall that
> > COM
> > is language-independent. COM boundaries are language
> boundaries. After
> > all,
> > if the caller is written in C and the callee is written in
> C++, what would
> > COM do with the C++ exception? If your code throws an exception, the
> > caller
> > will see a failure with an HRESULT of 0x80010105
> (RPC_E_SERVERFAULT).
> > Interestingly enough, this is the same error the caller
> sees if the callee
> > attempts an illegal memory access. In both cases, the COM
> runtime isolates
> > the caller of the object from runtime errors inside the object and
> > presents
> > them as server errors.
> >
> >
> > -----Original Message-----
> > From: Mark Jordan [mailto:mark.jordanEXELONCORP.COM]
> > Sent: Friday, February 15, 2002 7:43 PM
> > To: DCOMDISCUSS.MICROSOFT.COM
> > Subject: RPC Exception, Subsequent Calls Hang
> >
> >
> > Hey Folks,
> >
> > I have a DCOM Server (OPC) that provides data to many
> clients on many
> > different machines.
> >
> > I have encountered a random bug that is hard to track down.
> As near as I
> > can tell, the following occurs:
> >
> > 1) All clients are working fine for a while (could be days
> or weeks).
> > 2) Suddenly, one client will encounter 0x80010105 (not
> sure where, users
> > aren't much help).
> > 3) From then on, all other attempts to connect to the
> server hang. It
> > appears that CoCreateInstanceEx succeeded and
> QueryInterface for various
> > Interface pointers succeeds, but the first function call
> attempted hangs
> > indefinitely.
> >
> > I don't know enough about the inner-workings of DCOM to
> know where to
> > look.
> >
> > I'm willing to bet there is some bad code in the DCOM
> server somewhere
> > that
> > every once in a while throws an exception (in my experience, random
> > indetermine bugs are memory related). I am rigorously
> looking through the
> > code for potential bugs. I am asking this group for two things.
> >
> > (1) What are some common pitfalls people have seen with
> memory in DCOM
> > servers? Aside from standard C++ coding hazards...I'm talking about
> > CoTaskMemAlloc and the like.
> > (2) If someone could give a clear description of what is
> actually getting
> > hung up (I'm guessing it's marshalling code or proxy/stub code?) and
> > causing
> > problems, I'd appreciate it. I'm asking for this in general terms.
> > Clearly, no one can diagnose my problem from afar.
> >
> > Thanks in advance for any help you can all provide.
> >
> > Mark Jordan
> > mailto:mark.jordanexeloncorp.com
> >
> > ----------------------------------------------------------------
> > Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> > contains important info. Save time, search the archives at
> > http://discuss.microsoft.com/archives/index.html .
> > To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
> >
> > ----------------------------------------------------------------
> > Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> > contains important info. Save time, search the archives at
> > http://discuss.microsoft.com/archives/index.html .
> > To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>
>
> **************************************************************
> **********
> This e-mail and any of its attachments may contain Exelon Corporation
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to the Exelon Corporation family of Companies.
> This e-mail is intended solely for the use of the individual or entity
> to which it is addressed. If you are not the intended
> recipient of this
> e-mail, you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments
> to this e-mail is strictly prohibited and may be unlawful.
> If you have
> received this e-mail in error, please notify the sender
> immediately and
> permanently delete the original and any copy of this e-mail and any
> printout. Thank You.
> **************************************************************
> **********
>
> ----------------------------------------------------------------
> Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
> contains important info. Save time, search the archives at
> http://discuss.microsoft.com/archives/index.html .
> To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM
>

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]