When using a delegate for callback from an unmanaged dll: do I have to fix (
(how do i?) that delegate somehow so that is will not be 'moved' on garbage
collection or voided totaly after the procedure is vacated so the unmanaged
pointer will loose it's relevance?
Thanks!
tb

Declare the delegate outside the function at the type level (assuming the
instance of the type is not eligible for GC, neither will the delegate). If
you are still in doubt, post your snippet.

Cheers
Daniel
--
http://www.danielmoth.com/Blog/

"tb2000" <(E-Mail Removed)> wrote in message
news:C84CC5B9-F590-41E2-86FA-(E-Mail Removed)...
> When using a delegate for callback from an unmanaged dll: do I have to fix
> (
> (how do i?) that delegate somehow so that is will not be 'moved' on
> garbage
> collection or voided totaly after the procedure is vacated so the
> unmanaged
> pointer will loose it's relevance?
> Thanks!
> tb
>
>
>

Thanks Daniel, to make sure here's the code snippet:

public class WrapCDLL
{
public delegate void CallBack(IntPtr data);
static WrapCDLL()
....}

public class MyApp
{
public static WrapCDLL.CallBack myNotifyListenerDelegate;
public static void NotifyListener(IntPtr lpUnmanagedData)

{...}

public int Run() //the main loop entered after instantiating
MyApp

{myNotifyListenerDelegate = new
WrapCDLL.CallBack(NotifyListener);
......}
....}



"Daniel Moth" wrote:

> Declare the delegate outside the function at the type level (assuming the
> instance of the type is not eligible for GC, neither will the delegate). If
> you are still in doubt, post your snippet.
>
> Cheers
> Daniel
> --
> http://www.danielmoth.com/Blog/
>
> "tb2000" <(E-Mail Removed)> wrote in message
> news:C84CC5B9-F590-41E2-86FA-(E-Mail Removed)...
> > When using a delegate for callback from an unmanaged dll: do I have to fix
> > (
> > (how do i?) that delegate somehow so that is will not be 'moved' on
> > garbage
> > collection or voided totaly after the procedure is vacated so the
> > unmanaged
> > pointer will loose it's relevance?
> > Thanks!
> > tb
> >
> >
> >
>
>
>

Also - my question probably was unprecise: It's clear that GC won't destroy
the delegate as long as there is a valid reference (!=eligible for GC). But
what about moving it in memory and thereby changing it's address. (I thought
I had read somewhere that the GC might do this with managed types in order to
defragment memory usage?)

"Daniel Moth" wrote:

> Declare the delegate outside the function at the type level (assuming the
> instance of the type is not eligible for GC, neither will the delegate). If
> you are still in doubt, post your snippet.
>
> Cheers
> Daniel
> --
> http://www.danielmoth.com/Blog/
>
> "tb2000" <(E-Mail Removed)> wrote in message
> news:C84CC5B9-F590-41E2-86FA-(E-Mail Removed)...
> > When using a delegate for callback from an unmanaged dll: do I have to fix
> > (
> > (how do i?) that delegate somehow so that is will not be 'moved' on
> > garbage
> > collection or voided totaly after the procedure is vacated so the
> > unmanaged
> > pointer will loose it's relevance?
> > Thanks!
> > tb
> >
> >
> >
>
>
>

The CF actually keeps an internal pointer to it, so even if it needs to move
itt, it keeps track of that so you don't need to worry about pinning it.

-Chris


"tb2000" <(E-Mail Removed)> wrote in message
news:A3CEED37-1220-47EF-8347-(E-Mail Removed)...
> Also - my question probably was unprecise: It's clear that GC won't
> destroy
> the delegate as long as there is a valid reference (!=eligible for GC).
> But
> what about moving it in memory and thereby changing it's address. (I
> thought
> I had read somewhere that the GC might do this with managed types in order
> to
> defragment memory usage?)
>
> "Daniel Moth" wrote:
>
>> Declare the delegate outside the function at the type level (assuming the
>> instance of the type is not eligible for GC, neither will the delegate).
>> If
>> you are still in doubt, post your snippet.
>>
>> Cheers
>> Daniel
>> --
>> http://www.danielmoth.com/Blog/
>>
>> "tb2000" <(E-Mail Removed)> wrote in message
>> news:C84CC5B9-F590-41E2-86FA-(E-Mail Removed)...
>> > When using a delegate for callback from an unmanaged dll: do I have to
>> > fix
>> > (
>> > (how do i?) that delegate somehow so that is will not be 'moved' on
>> > garbage
>> > collection or voided totaly after the procedure is vacated so the
>> > unmanaged
>> > pointer will loose it's relevance?
>> > Thanks!
>> > tb
>> >
>> >
>> >
>>
>>
>>

Thanks, wow that was quick!
Cheers
Theo

"Chris Tacke [MVP]" wrote:

> The CF actually keeps an internal pointer to it, so even if it needs to move
> itt, it keeps track of that so you don't need to worry about pinning it.
>
> -Chris
>
>
> "tb2000" <(E-Mail Removed)> wrote in message
> news:A3CEED37-1220-47EF-8347-(E-Mail Removed)...
> > Also - my question probably was unprecise: It's clear that GC won't
> > destroy
> > the delegate as long as there is a valid reference (!=eligible for GC).
> > But
> > what about moving it in memory and thereby changing it's address. (I
> > thought
> > I had read somewhere that the GC might do this with managed types in order
> > to
> > defragment memory usage?)
> >
> > "Daniel Moth" wrote:
> >
> >> Declare the delegate outside the function at the type level (assuming the
> >> instance of the type is not eligible for GC, neither will the delegate).
> >> If
> >> you are still in doubt, post your snippet.
> >>
> >> Cheers
> >> Daniel
> >> --
> >> http://www.danielmoth.com/Blog/
> >>
> >> "tb2000" <(E-Mail Removed)> wrote in message
> >> news:C84CC5B9-F590-41E2-86FA-(E-Mail Removed)...
> >> > When using a delegate for callback from an unmanaged dll: do I have to
> >> > fix
> >> > (
> >> > (how do i?) that delegate somehow so that is will not be 'moved' on
> >> > garbage
> >> > collection or voided totaly after the procedure is vacated so the
> >> > unmanaged
> >> > pointer will loose it's relevance?
> >> > Thanks!
> >> > tb
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>
>