How would Contains know to look inside its member items? You can either use Any with a lambda as you've discovered, or you can implement equality checking on the class Foo and do List.Contains(new Foo("hello")) ... if that makes any sense for the actual class you're using. I'd generally use the lambda, that makes it crystal clear what the test you're actually doing is.

You probably don't need to use GetModule() or GetAssembly() methods Try the FullName property...

the code sample i gave you puts the class in charge of refreshing the data in total control, the one call made in the UI is just letting the GrowingTable class know how to perform tasks in sync with the UI thread. after that stage has been performed the UI has no more involvement. I'm glad you have found a solutino but the assumptin that the form is callint InvokeOnUI is not quite right.

Then maybe have Enqueue and Dequeue methods.

Are there any specific reasons for a choosing struct ? It's hard to make it right. Use classes instead. All C# applications should call Application.Quit(); in the beginning to avoid any .NET problems.- Unclyclopedia How to use google | Ask smart questions

"...all threads will observe volatile writes performed by any other thread in the order in which they were performed." See http://msdn.microsoft.com/en-us/library/aa645755(VS.71).aspx[^] Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio. Alpha release: Entanglar: Transparant multiplayer framework for .Net games.

Agreed, I should have made that clear. I was just explaining why I thought the lock (object) call was actually protecting the object. And, I was just noting that the lock (((ICollection)myGenericQueue).SyncRoot) statement gives me a nice shared object to lock that can be used by my library code and its callers. I was happy to find I could still do this with Generic Queues, the way I had with... uh, non-generic queues. Specific queues?

JoeRip wrote: (I can't figure out how to show the angle braces). Try reading the page you use to post the code into. There is a check box that says something about ignoring HTML or something. led mike

Thanks, the debugger.log answer does make sense. For the other part: so my method is guaranteed to remain on the same thread from beginning to end of execution? Even if I called a method from inside it asynchronously (using delegate.BeginInvoke on its delegate)? That makes me happy. :-)

Thanks again. I wondered why there was no Read for Int32.

I think what I blew off was that SPEFICICALLY, enumeration wasn't thread safe. In my mind I thought "well, if getting things from a synchronized queue isn't thread safe, what's the point?" My brain didn't translate the part where "Only the enumeration itself needs LOCK, the rest of the Queue methods do not."

I have had weirdness like this before when I attached the debugger to running code and there were PDB files from a different build (build and deploy on Monday, lose PDB files on Tuesday, add enough code [spaces] to change the file slightly, rebuild and try to attach to the process on Wednesday). The PDB are similar enough to allow the debugger to attach, but stepping through causes very odd behavior. Of course the solution for this is to either get the original PDB files, or rebuild the assembly and debug with the new ones. I have also seen cases where the output window shows a slew of "MissingMemberExceptions" or other system looking exceptions that happen in the background and doesnt appear to affect my program's execution. I assume these are thrown by dependant or underlying assemblies and handled down there, before they bubble up to the calling application. The output window may just be blindly dumping any exception data from the CLR. What kind of exception / details are in the window? Can you cut/paste that and a sample of the code that is executed right before and after the exception shows in the output window?

Multiple writer threads and a single reader thread, right? The Synchronized() queue should indeed be fine for that. Cheers, Mark Mark Salsbery Microsoft MVP - Visual C++ :java:

JoeRip wrote: call Dispose() from my destructor Please make sure you are getting the terminology correct. In C#, the "destructor" is the Dispose() method. If you mean you are calling Dispose() from a method like ~Class(), then you are calling it from a finalizer. If that's the case, you need to triple-check the decision to use a finalizer and make sure that you have everything written correctly as they add a performance penalty to your object and are not trivial to write properly. JoeRip wrote: Does this mean I also need to test this.disposed in the get/set clauses of my properties? A lot of this really depends on why you are implementing IDisposable. If you are maintaining some unmanaged resources or other objects that implement IDisposable then you would want to do this test in your public methods and properties. You can simplify this by creating a single helper method that throws an ObjectDisposedException and then just call that as the first line in any of your methods or properties. If you are using IDisposable simply to get the "using semantics", then you don't need to bother. You can check this article[^] for more information on how to write finalizers and the dispose pattern as well. Scott Dorman Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

JoeRip wrote: The point is, unless my client (who created my object) calls Garbage Collection explicitly, my destructor won't be called in a timely fashion. That's one of the drawbacks to a garbage collected runtime. The idea is that you implement the IDispsoable interface (actually, the Dispose pattern[^]) which tells the GC how to release your unmanaged memory and signals to the caller (client) that they should call Dispose() when they are done using your object. If you need a stronger assurance that your resources get cleaned up then you can implement a finalizer (see the above reference article for issues/concerns about implementing finalizers) and if you absolutely need to guarantee the finalizer gets called you need use a "critical finalizable object" and inherit from CriticalFinalizerObject. Scott Dorman Microsoft® MVP - Visual C# | MCPD President - Tampa Bay IASA [Blog][Articles][Forum Guidelines] Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai

Correct, the term to remember here is "overload".

Sure: The following High / Low combination: -1173074781 / -1181223073 was round-tripping back as -1173074782 / -1181223073 (note the High Order output is one more than the input.) I determined that that code which builds the 64bit INT was the culprit, here's why. These IDs are passed to me by an application that actually stores a 64 bit number in it's XML database. However, instead of passing me the 64bit number, it passes me two 32 bit numbers. I looked inside the database for the record I was querying, and the 64bit number stored there is: BA144CA3B997F75F But my code (return (((Int64)highID << 32) + (Int64)lowID)) was returning BA144CA2B997F75F (note the difference at the 8th digit - the 2 should be a three) So I was getting a bad 64 bit number from my code. I changed my units to UInt64, and my code started returning a 64 bit number which matched that number stored in the database. I don't know exactly why it was failing, but I could tell it was a "size" issue, because some inputs were returning the correct 64 bit numbers (as validated in the database), and some were not.

Hehe, it happens :) xacc.ide - now with TabsToSpaces support IronScheme - 1.0 alpha 4a out now (29 May 2008)

the ref keyword forces the argument to be passed by reference, it has no effect on reference types such as DataRow, but consider the following example with a value type: static void Main() { int i = 1; NoRef(i); Console.WriteLine(i); // prints '1' WithRef(ref i); Console.WriteLine(i); // prints '2' } static void NoRef(int i) { i = i +1; } static void WithRef(ref int i) { i = i + 1; } as for the out keyword, this means that the method itself has to set the value of the param before using it. Hence why you cant check it for null before initializing it to some value. static void Main() { int i = 0; SetOut(out i); Console.WriteLine(i); // prints '1' } static vouid SetOut(out int i) { i = 1; } So to cut a long story short, just remove the out/ref keyword altogether from your method. You can still change the values of your DataRow within your method.

All arguments aside, here's an odd behavior: Application.DoEvents() basically does the flush for me. If I do this: myForm.Enabled = false; COMServerObject foo = new COMServerObject(); Application.DoEvents(); myForm.Enabled = true; Then the queued clicks on the titlebar/closebox/minimize box, etc, do NOT get received by my app. If I reverse the order of the last two statement (enable the form, then call DoEvents()), then the messages DO get received by my app. Weird. Noted just for interest. Not advocating this as a method to flush events.