That sounds like the retain/release is then being automatically handled.  Once the object is referenced inside C# the retain occurs.  Then when the C# object is GCed the release should occur.  Is that correct?  Which if it is then all I should have to do is set the C# variable to null or call Dispose and I have the same basic functionality I listed.<br>
<br>It would probably also be worthwhile making retainCount public.  As this is a useful debugging technique for memory leaks.<br><br>I have yet to use MonoMac so I&#39;m still guessing a bit on how the interaction with native obj-c code will work.  I just want to ensure I&#39;m not loosing obj-c functionality.  Having control of the retain cycle is an important &#39;feature&#39; of obj-c.<br>
<br>Duane<br><br><div class="gmail_quote">On Tue, Apr 20, 2010 at 1:37 PM, Geoff Norton <span dir="ltr">&lt;<a href="mailto:gnorton@novell.com">gnorton@novell.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Whenever we bubble a proxy object, it takes a reference to the underlying native object, as such in the circumstance you described the object could not &quot;go away&quot;<br>
<br>
-g<br>
<div><div></div><div class="h5"><br>
On 2010-04-20, at 1:24 PM, Duane Wandless wrote:<br>
<br>
&gt; I noticed that retain/release/autorelease our internal methods.  I&#39;m not fan of doing memory management as that takes away time from solving business needs.  Memory management is required with obj-c.  And I believe these should be public.<br>

&gt;<br>
&gt; There are times when an object is passed as an argument into my C# code that must be retained while the C# code manipulates the object (typically a UI object)... then release that object when done.  The most common usage is the UI is a delegate for the async C# method.  At times the UI object will go away while the C# code is running its async task.  The retain of course prevents sending a selector to a deallocated object.  And there are times when the UI delegate selector is not invoked so I must be able to release the UI object from the C# code.<br>

&gt;<br>
&gt; I think one of the fundamental design patterns of MonoTouch and now MonoMac is that all the code will be written in C#.  I do think this assumption is limiting.  Giving the C# code full access to the obj-c objects allows for truly the best of both worlds.  The advantages of the C# language can be leveraged.. but without limiting the functionality of the various NS classes within C#.<br>

&gt;<br>
&gt; Again my usage is a native obj-c app for the UI with the business logic in C#.  There are advantages to fully developing within C# MonoMac .. I just want to push the design so that is not required.<br>
&gt;<br>
&gt; Duane<br>
</div></div>&gt; _______________________________________________<br>
&gt; Mono-osx mailing list<br>
&gt; <a href="mailto:Mono-osx@lists.ximian.com">Mono-osx@lists.ximian.com</a><br>
&gt; <a href="http://lists.ximian.com/mailman/listinfo/mono-osx" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-osx</a><br>
<br>
</blockquote></div><br>