Thanks. I asked here because it's not obvious that object.contains() is actually a LINQ extension. Sadly, you can't do what I want with object.contains(), which does not let you compare nested values directly. Turns out that what I need is

foo.Any(f => f.bar.data == "hello")

Which makes me a little sad, because

foo.Contains(nested value I was looking for)

would have been a lot simpler than having to break out my book and re-learn lambdas. Oh well, wave of the future :-)

I cannot figure out the syntax for using the LINQ extensions on IList (and other interfaces) to search for values that are in nested objects. For instance, I have a List<foo>, where object foo contains two other objects, each of which have field "data". How do I use List.Contains<foo>("hello") to search for a foo object where foo.nestedobject.data = hello?

Hmm... okay, I found Assembly.GetExecutingAssembly. Now I need to determine if I need the assembly name or the module name... what is the difference between a module and an assembly?

I need to know the name of the module (or assembly) which is currently executing my code. ie, if application X has loaded DLL Y, and DLL Y calls a callback method in application X, I want to get the name of DLL Y. I can figure out how to get the name of the MainModule for the current process, or even the list of modules that are loaded for the current process, but I can't figure out how to get the currently executing module from this.

Well, it works. Not sure about design quality, but it was better than the hacks I was using before. Thanks for all the help! Let me know if it sucks. Here's a sample which demonstrates the pattern; first the caller/form:

using System;
using System.Windows.Forms;
using GrowingDataTable;

namespace dgv
{
public partial class Form1 : Form
{
public DataGridView dgvMain;
public delegate void delEventHandler(object sender,
GrowingDataTable.UpdateDataTableOnYourThreadContextEventArgs e);
public GrowingDataTable gt;

    public Form1()
    {
        InitializeComponent();
    }

    private void Form1\_Load(object sender, EventArgs e)
    {
        // add a datagridview to the form
        dgvMain = new DataGridView();
        Controls.Add(dgvMain);
        dgvMain.Dock = System.Windows.Forms.DockStyle.Fill;

        // create the GrowingTable object
        gt = new GrowingDataTable();

        // subscribe to the GrowingTable event
        gt.RaiseUpdateTableAgainstYourThreadContextEvent += new 
       EventHandler<GrowingDataTable.UpdateDataTableOnYourThreadContextEventArgs>
      (gt\_RaiseUpdateTableAgainstYourThreadContextEvent);

        // tell gt that we want to be updated
        gt.UpdateDataTableOnCallerThreadContext = true;

        // assign the DataTable as DataSource for our datagridview
        dgvMain.DataSource = gt.itemTable;
        
        // tell the GrowingTable to start growing; 
        // delay start for 3 seconds, add row every 1 second
        gt.Start(3000, 1000);
    }

    void gt\_RaiseUpdateTableAgainstYourThreadContextEvent(object sender,
            GrowingDataTable.UpdateDataTableOnYourThreadContextEventArgs e)
    {
        if (InvokeRequired) {
            Invoke(new
            delEventHandler(gt\_RaiseUpdateTableAgainstYourThreadContextEvent),
            new object\[\] { sender, e}); }
        else
        {
            if ((e.Updates != null) || (e.Updates.Count > 0))
            {
                gt.UpdateTableOnMyThreadContext(e.Updates);
            }
        }
    }
}

}

Then the library class GrowingDataTable:

using System;
using System.Collections.Concurrent;

namespace GrowingDataTable
{
public class GrowingDataTable
{
public System.Data.DataTable item

I think this is not general enough for what I need. GrowingTable updates its table at arbitrary times. The caller (form) can't know when to call InvokeOnIU. If I understand the code above correctly, the form is only calling InvokeOnIU when it wants to. How about this: GrowingTable will have a property, method and event:

bool fCallerNeedsUpdateOnItsOwnContext

void UpdateGTDataSource(GTUpdates updates)

event UpdateDataAgainstYourOwnContext

When GrowingTable needs to update its data, it will create a queue of updates (typically, rows to add, rows to replace other rows by id, or id's of rows to be deleted). If fCallerNeedsUpdateOnItsOwnContext is true, it will raise the UpdateDataAgainstYourOwnContext event, passing the queue of updates. Then the subscriber can call or Invoke GT.UpdateGTDataSource(updates) as it needs, to insure thread context safety. If fCallerNeedsUpdateOnItsOwnContext is false, GrowingTable will simply execute the queue of updates itself. What say you, coders?

Thanks! Very nice. This is very similar to what I eventually settled on. Since GrowingTable() is actually in another (library) assembly completely, it can't have intimate knowledge of the UI's Form methods. And in fact, it may not be called from a Form at all. So, I simply added an optional callBack delegate parameter to GrowingTables constructor, and I let the caller pass in a callBack function, to be called on each AddRow. That way, the caller can check NeedsInvoke on his side, and invoke the callBack over to the UI thread if necessary. It's still ugly, but it's doable. I think the real solution is to not expose a DataTable directly, and handle the binding directly. Actually, looking closer at what you've done here... this might be cleaner. Will play with it tomorrow. Thanks!

Thanks, but those articles assume that the non-Form thread knows about the Form, and call Form methods. In my case, this library object does NOT know about the Form, and therefore cannot use Invoke to call Form methods. This is by design - the DataTable in the library object has no idea who is connecting to its DataSource, nor should it. So there is no clear place where Invoke can be used, that I can tell. On the DataGridView's side, the RowsAdded event is simply not firing, because it's on the wrong thread. So the DGV is not getting updated. I think it comes down to this: should I redesign the library object so that it takes a delegate to call after Rows.Add (seriously ugly)? Or should I not expose the DataTable directly, and look to find another method of making the DataTable's content available?

Okay, here is a very simplified version of the problem. Note that the GrowingTable() class is normally in a separate assembly and namespace. So - I can't just convert the Timer to a FormTimer, unless I pass the form itself to the GrowingTable class, which would be incredibly ugly. And there's no clear place where I can Invoke, as there is no actual update function (that is hidden in the DataSource mechanism).

using System;
using System.Windows.Forms;

namespace dgv
{
public partial class Form1 : Form
{
DataGridView dgvMain = new DataGridView();
GrowingTable ra = new GrowingTable();

    public Form1()
    {
        InitializeComponent();
    }

    private void Form1\_Load(object sender, EventArgs e)
    {

        Controls.Add(dgvMain);
        dgvMain.Dock = System.Windows.Forms.DockStyle.Fill;
        dgvMain.Location = new System.Drawing.Point(0, 45);
        dgvMain.DataSource = ra.itemTable;
        ra.Start();
    }

    // this class would normally appear in a separate assembly and namespace
    public class GrowingTable
    {
        public System.Data.DataTable itemTable; 
        private System.Threading.Timer myTimer = null;

        // constructor
        public GrowingTable()
        {
            itemTable = new System.Data.DataTable();
            myTimer = new System.Threading.Timer(this.AddRow, null, System.Threading.Timeout.Infinite, System.Threading.Timeout.Infinite); 
            for (int i = 0; i < 11; i++)
            {
                itemTable.Columns.Add(new System.Data.DataColumn(i.ToString(), typeof(System.DateTime)));
            }
        }

        public void Start()
        {
            myTimer.Change(0, 500);
        }

        private void AddRow(object state)
        {
            if (itemTable.Rows.Count < 50)
            {
                System.Data.DataRow dr = this.itemTable.NewRow();
                for (int i = 0; i < 11; i++) { dr\[i.ToString()\] = DateTime.Now; }
                this.itemTable.Rows.Add(dr);
            }
            else
            {
                myTimer.Dispose();
                myTimer = null;
            }
        }
    }
}

}

Hello - In one hand, I have a form which contains a DataGridView. Clearly, the DGV is running on the UI thread. In the other hand, I have an library object, which contains a DataTable. That datatable is updated by an internal System.Threading.Timer (not a form timer). A couple of times a second, a row is added to that table. Once I set the DataSource of the DataGridView to be the DataTable of that library object, the DGV never redraws. The data is there, it just doesn't draw. The problem is that the DataTable is being updated by a different thread than the UI thread (verified). Apparently, the "your data has changed" methods of the DGV are also being called on that other thread. So: how do I avoid this? Since the update mechanisms are private to the DataSource/Binding mechanism, there is no clear place where I can use Invoke to sync the datatable with the UI thread, so I can cross the thread boundary safely. I do own the library object. I am currently exposing the DataTable as a public object. Is there another way to get the data in the table to the DGV, in a way that crosses the thread boundary safely?

Heh. Actually, this code was written to prevent the user from having to deal with events. I'm wrapping a COM object which does raise events, but has complexities and issues that are problematic. This code maps an event raiser to something a user can poll. If those are the primary concerns, I'll stick with this model for now. My stress tests should tell me how much collision I'm seeing during my internal enqueue. Thanks everybody!

I'm exposing a recorded history of events (changes to a database), in the order that they occured. I expect to update the queue periodically. Original order of events is important. I expect the user to periodically consume this information, in order, and then come back for more. So I was using a queue as it enables them to dequeue at will, while maintaining the original order, and keeping track of which events they have already noted/processed. The user really only needs to dequeue (ie, remove one item at a time, and be able to tell that they have consumed all the items currently available).

Is anybody aware of any guidelines, issued by Microsoft or any other parties, about exposing a Queue or Queue<T> as a public property on an object? I recall some old guidelines about exposing a generic collection, but I can't find any recent information about that, either.

It's still not clear what it is you want to do. 1. do you have data sitting in a System.Queue object? 2. would you like to Dequeue that queue, and put a copy of the text/values there in a text box?

yeah, that kind of defeats my purpose. I need more resolution than that. I need to be able to hand the top level struct around and let any code in my class modify any individual field therein, no matter how nested. So I'm left with either (a) flattening out the entire struct, which I am loathe to do or (b) writing Set() methods at the top level which are knowledgeable about all of the fields of the nested structs. I'm leaning towards (b). But I hate it.

Doh. Apparently you can't set properties in nested structs... the following is not allowed:

my Class
{
myStructInner
{
public int myInt { get; set; }
}

myStructOuter
{
public myStructInner structProp { get; set; }
}

myMethod()
{
myStructOuter thingy = new myStructOuter();
myStructOuter.myStructInner.myInt = 5;
}
}

Compiler claims that you cannot "change the return value from myStructOuter.myStructInner.myInt", as it's not a "variable".

Thanks, I believe you lead me down the right path. I've implemented all the struct fields as auto-properties:

public DateTime TimeStamp { get; internal set; }

The internal setter allows my class to change fields at will, but prevents the caller from doing so. Bravo!

I'm still not following. I have fields who's value I want the caller to be able to see. I need to change them internally, before I "finalize" the values, but I don't want the caller to be able to change them. Are you suggesting that I implement properties, and in the "Set" property, I check my boolean to see if the struct has been "finished"? If so, what access properties do I put on this boolean, so that I can change it to "locked" but the caller cannot change it to "unlocked"? I'm assuming that I'm misunderstanding your suggestion.

I think you might be mixing objects here. There is the System.PrintQueue class, which represents a queue of printer jobs queued up by Windows to submit to a printer; and there are Queue objects (System.Collections.Queue), which you use to hold collections of data. There is no "print" method for a Queue object.

I have a library class which does a bunch of work and eventually returns to the caller a struct (call it UserInfo). That struct contains other structs. All of the members of all of the structs are public readonly, as I don't want the caller to able to change any of the values. However, I want all of the values visible. So I'm limited to using constructors to build all the nested structs. However, this isn't practical in the flow of my class - I need to be able to create a new UserInfo and update the members of its nested structs as it bounces around inside my class. I really only want to "seal" the struct right before I pass it to the caller. What's the best design pattern for this? Should I create a mirrored "TempUserInfo" struct with all public members and fill that out instead, and at the last minute copy those values into the final UserInfo struct?