Unmanaged to managed callback, and GCHandle / gcroot

[DaTurk]

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/lib...e0(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?

[Ben Voigt [C++ MVP]]

"DaTurk" <mm******@hotmail.comwrote in message
news:11**********************@e16g2000pri.googlegr oups.com...

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/lib...e0(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?

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.

[DaTurk]

On Jul 19, 4:56 pm, "Ben Voigt [C++ MVP]" <[e-mail]:

"DaTurk" <[e-mail] in message

news:11**********************@e16g2000pri.googlegr oups.com...

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/lib...e0(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?

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.- Hide quoted text -

- 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.

[Ben Voigt [C++ MVP]]

"DaTurk" <mm******@hotmail.comwrote in message
news:11**********************@w3g2000hsg.googlegro ups.com...

On Jul 19, 4:56 pm, "Ben Voigt [C++ MVP]" <[e-mail]:

>"DaTurk" <[e-mail] in message

news:11**********************@e16g2000pri.googleg roups.com...

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/lib...e0(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?

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.- Hide quoted text -

- 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.

Your shim will have to be #pragma managed, native class I believe (not ref
class).

[DaTurk]

On Jul 24, 12:31 pm, "Ben Voigt [C++ MVP]" <[e-mail]:

"DaTurk" <[e-mail] in message

news:11**********************@w3g2000hsg.googlegro ups.com...

On Jul 19, 4:56 pm, "Ben Voigt [C++ MVP]" <[e-mail]:

"DaTurk" <[e-mail] in message

>news:11**********************@e16g2000pri.googleg roups.com...

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/lib...e0(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?

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.- Hide quoted text -

- 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.

Your shim will have to be #pragma managed, native class I believe (not ref
class).- Hide quoted text -

- 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.

[Ben Voigt [C++ MVP]]

"DaTurk" <mm******@hotmail.comwrote in message
news:11**********************@q75g2000hsh.googlegr oups.com...

On Jul 24, 12:31 pm, "Ben Voigt [C++ MVP]" <[e-mail]:

>"DaTurk" <[e-mail] in message

news:11**********************@w3g2000hsg.googlegr oups.com...

On Jul 19, 4:56 pm, "Ben Voigt [C++ MVP]" <[e-mail]:
"DaTurk" <[e-mail] in message

>>news:11**********************@e16g2000pri.google groups.com...

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/lib...e0(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?

>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.- Hide quoted text -

>- 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.

Your shim will have to be #pragma managed, native class I believe (not
ref
class).- Hide quoted text -

- 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.

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.

[DaTurk]

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.

[Ben Voigt [C++ MVP]]

"DaTurk" <mm******@hotmail.comwrote in message
news:11*********************@q75g2000hsh.googlegro ups.com...

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.

What exactly do you give the manager? Source code? Binary interface
pointers?