Hi Ian ,
Thanks for your detailed response.
I was considering whether to use delegates to render from a render loop
instead of the traditional direct method calls (via an Irenderable
interface). Considering the details below and the much cleaner
implementation I will use delegates.
Regards,
Thanks Jeroen!
-S
===
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
Thanks everyone for your help. I have time to experiment as the project
starting date has slipped to march.
-Original Message-
From: Unmoderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Roni Burd
Sent: Friday, January 07, 2005 9:26 PM
To: ADVANCED-DOTNET
I don't have an answer as to which approach might work better. However, I
wonder why you're trying so hard to avoid having your .NET code run within the
COM caller's process. The only reason I can see for that is that you want to
support multiple COM callers within different processes all work
Użytkownik Marek Malowidzki <[EMAIL PROTECTED]> napisał:
>Użytkownik Jeroen Frijters <[EMAIL PROTECTED]> napisał:
>>Shawn A. Van Ness wrote:
>>> Ok, so I grant that GC.KeepAlive(this) does have some effect.
>
> System.Threading.Thread.Sleep(5000);
Yeah, I knew posting a program in pieces woul
Użytkownik Jeroen Frijters <[EMAIL PROTECTED]> napisał:
>Shawn A. Van Ness wrote:
>> Ok, so I grant that GC.KeepAlive(this) does have some effect.
Well, I cannot produce the problem with a C#/Managed C++ program. The C# part
looks as follows (it is a bit messy, as I have modified a more complex p
Shawn A. Van Ness wrote:
> Ok, so I grant that GC.KeepAlive(this) does have some effect. But
> what does this have to do with IntPtr fields?
The (somewhat dubious) assumption is that an IntPtr represents an
unmanaged resource.
> I mean, is there something special about IntPtr (like, maybe the
>
Depends on what you mean by a 'direct call'.
There are various different forms of method call in .NET. You've got
interface-based, virtual, non-virtual instance, and non-virtual static.
And for the two non-virtual cases, it'll be very different depending on
whether the method call is inlined or n
Użytkownik Fabian Schmied <[EMAIL PROTECTED]> napisał:
>> http://www.gotdotnet.com/team/fxcop/Docs/Rules/SecurityRules/IntptrAndFinalize.html
>>
>> I struggle to comprehend the above FxCop rule. Does it make a lick of
>> sense to anyone?
>
>Just want to point you to this [1] blog by Chris Brumme,
Assume the following class:
class C {
public static readonly C Instance1 = new C(state1);
public static readonly C Instance2 = new C(state2);
public static readonly C Instance3 = new C(state3);
private SomeState state;
private C(SomeState state) {this.state = state;}
// plus some helper
Thanks for the replies, everyone. Yes, I see now that objects can be
finalized while instance methods are still executing -- the first
couple of test apps I put together, to demonstrate this, gave me false
results for some reason.
Ok, so I grant that GC.KeepAlive(this) does have some effect. But
Hello All,
My question is "How do I automate a .Net exe?"
The details are like this:
Problem:
I have a .exe written in .Net (C#)
I want to make this similar to a COM out-of-proc server (Automation Server)
so that automation clients can interact with automation objects in this .exe
I found in .Ne
Użytkownik Shawn A. Van Ness <[EMAIL PROTECTED]> napisał:
>http://www.gotdotnet.com/team/fxcop/Docs/Rules/SecurityRules/IntptrAndFinalize.html
>
>I struggle to comprehend the above FxCop rule. Does it make a lick of
>sense to anyone?
Well, I would start with a remark that the introduction is a bi
http://www.gotdotnet.com/team/fxcop/Docs/Rules/SecurityRules/IntptrAndFinalize.html
I struggle to comprehend the above FxCop rule. Does it make a lick of
sense to anyone?
Just want to point you to this [1] blog by Chris Brumme, where he
discusses the same problem. He also suggests a solution which
Shawn A. Van Ness wrote:
> How could the finalizer decide to collect an object, if one or more
> threads is currently executing code against it? (Put simply: doesn't
> the 'this' pointer count as a reachable reference, for the duration of
> any instance-method call?)
The easiest way to think abou
15 matches
Mail list logo
