开发者

CRT types across process boundaries

开发者 https://www.devze.com 2023-01-06 01:54 出处:网络
I\'m doing drag/drop out of an activeX control. On drag, I provide a CComQIPtr which has COM methods implemented to pass information to the drop target. On drop, the drop target\'s process calls my CO

I'm doing drag/drop out of an activeX control. On drag, I provide a CComQIPtr which has COM methods implemented to pass information to the drop target. On drop, the drop target's process calls my COM methods to get information.

Am I not allowed to use CRT types or pointers to CRT types near that interface boundary? I would love for my IDataObject to have a private std::list and some std::strings, and on the foreign side of the interface be able to call my COM methods which can access those priv开发者_C百科ate members.

I think it's OK because I'm not actually passing CRT types across the boundary.

MSDN: Potential Errors Passing CRT Objects Across DLL Boundaries


You can use anything you like in the implementation of your com object as that always stays in the process (or dll) that creates it.

You need to stick to COM types in your COM interface so that the types can be marshalled between the process where your object is used and the process where your object was created.

You are correct. That article doesn't apply to this situation as you aren't passing anything across the boundary. The COM infrastructure deals with marshalling the COM types across the boundary for you.

Just be sure that you catch all exceptions within your COM methods, you can't allow them to leak out of the function as the COM infrastructure wont know what to do with them.

Personally I tend to have a thin layer of COM code that deals with conversion between COM types and 'normal' types and then calls into the code that does the real work (see here). This layer includes an exception handler that catches everything and converts to appropriate HRESULTs.

0

精彩评论

暂无评论...
验证码 换一张
取 消