 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / August 2007Unmanaged to managed callback, and GCHandle / gcroot
Hi, I'm coding up an application that has a native c++ layer, asynchronously calling callback in a CLI layer. We originally did this with static inline methods in the CLI layer, but this solution only works with singleton objects. So I have to explore other solutions. So beside pinning pointers, I've been looking at GCHandle. I was looking at this example from MSDN. http://msdn2.microsoft.com/en-us/library/367eeye0(VS.80).aspx They have two examples, one where the GCHandle has class scope, and then another where it is static, and it's global. My problem is that I need each CLI instance of this object to have it's own GCHandle to it's own calback into the native world, will a instance variable of GCHandle cover this? > Hi, > [quoted text clipped - 16 lines] > it's own GCHandle to it's own calback into the native world, will a > instance variable of GCHandle cover this? Just use gcroot instead of GCHandle, it takes care of all the details. You can treat it like a T^ (tracking reference) except it's a member of a native class instead of a managed class. > > Hi, > [quoted text clipped - 22 lines] > > - Show quoted text - I can't use gcroot, because I'm using this reference in a unmanaged class i.e. #pragma unmanaged. And so it doesn't recognize the CLI delegate reference. >> > Hi, >> [quoted text clipped - 28 lines] > class i.e. #pragma unmanaged. And so it doesn't recognize the CLI > delegate reference. Your shim will have to be #pragma managed, native class I believe (not ref class). > >> "DaTurk" <mmagd...@hotmail.com> wrote in message > [quoted text clipped - 37 lines] > > - Show quoted text - I can't though. IT has to be a pragma unmanaged, because the classes are callback classes that get activated via a strait c++ third party orb. >> >> "DaTurk" <mmagd...@hotmail.com> wrote in message >> [quoted text clipped - 42 lines] > are callback classes that get activated via a strait c++ third party > orb. Does this third-party code generator create source code, or binaries? If source code, no problem, compile with /clr and you can use unmanaged classes all day. If binaries, then you have bigger problems than .NET compatibility -- to wit, lockin to a particular compiler version and particular compile options. Um, I'm not entirely sure about code generation. We're talking about CORBA here, all I know is I pass these "callback" c++ #pragma unmanaged classes to the POA_MANAGER, and it "activates" them so that I can use them to receive callbacks from the ORB. So, I'm not sure if that explains it really. But because I'm plugging these classes into a black box, third party, ORB magic thingy .... I'm reluctant to mix too much tech. > Um, I'm not entirely sure about code generation. We're talking about > CORBA here, all I know is I pass these "callback" c++ #pragma [quoted text clipped - 3 lines] > a black box, third party, ORB magic thingy .... I'm reluctant to mix > too much tech. What exactly do you give the manager? Source code? Binary interface pointers? Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.