It seems to me that you are actually getting the trace output after you call Thread.Start and before the generated thread finishes. This suggests that your thread starting code isn't a problem at all, but perhaps something that your main code is doing after it starts the threads is causing the GUI to lock up. I would look closely at the code which gets executed on your main thread after you start the worker threads (I don't think you posted that code on the boards).

Sincerely, Alexander Wiseman

Did you put a trace command after the new Thread(new ThreadStart(...)) line in the main code? If not, try that first. If so, did it get output? That is an important point because it will determine whether your main application is getting stuck on the creation of the thread, or on a subsequent call. Sincerely, Alexander Wiseman

I'm glad you figured it out! You said in the first part of your response: "i tried changing it to new tabpage(); then making the tabpage equal to my blanktabpage" Setting the tabpage equal to blanktabpage would defeat the purpose, because you are changing what your variable refers to. The main point was to create a wholly new tab page and add that to the tab control. I see that is what you did, which is great. As far as two tab pages getting added, I have an idea about it. I did not want to mention it in my previous post because I wasn't sure if this was the issue. Here goes: I was thinking that perhaps you did not actually have two tab pages being added, but rather the first tab page in your control changing to look exactly the same as the other tab page, since you only really have one tab page in memory. Thus, when your function got called, the tab page in memory got changed to look exactly the same as the "new" tab page you were adding. You could verify this by checking how many tab pages total there are before and after the call to your function. If there are two more than before, then I am simply wrong. If there is only one more tab page total, then I think what I said is happening. If you get a chance, could you check it out, I would like to know. This is a really interesting issue! Sincerely, Alexander Wiseman

One thing I notice about your function is this line:

TabPage newtabpage = blanktabpage

Where is blanktabpage initialized and created? The question is important because I think your code is not actually creating a new TabPage every time the function is called. The reason for this is that class types are reference types, which means that unless you actually have the new keyword in there, you are not creating another instance of the class in memory. I'm not completely sure I have this down properly (I may have been wrong in my explanation), but have a look at this article by Jon Skeet[^] on the distinction between reference types and value types. What this means (I think) for your code is that newtabpage refers to an already existing TabPage in memory. Changes that you are making with the variable newtabpage are affecting what blanktabpage points to. I'm not sure that this will necessarily produce the effect you are describing, but it is a problem. Try this instead: at the beginning of your addatab function, use the new keyword instead, like this:

TabPage newtabpage = new TabPage()

Then set the properties of the tab page based on the properties of blanktabpage and see what happens when you call Add or Insert. I'm fairly sure what I have said in this post is correct concerning reference types, but if I am wrong, I would welcome a correction from anyone who knows better. Sincerely, Alexander Wiseman

There are two ways to see the output: First, the quick and easy way: 1) If you're using Visual Studio, then run the program in debug mode by pressing F5. When the program exits, you can see all of the trace output in the "Output" window - the same window in which you see the results of the last Build command. In VS 2003 (and I think it is probably in 2002 as well), there is a drop-down box which allows you to select what kind of output you wish to view. After running the program in debug mode, my VS window shows two options "Build" and "Debug". If you set it on "Debug", you should see the trace output. Second, the way which takes a little bit longer, but results are more permanent: 2) Setup a TextWriterTraceListener which will automatically write trace output to a file. Here's how: first, you'll need to make sure you reference the System.Diagnostics namespace in your main form file:

using System.Diagnostics;

Second, put a variable in your main form code:

private TextWriterTraceListener myListener;

Now, put the following code into your application's main form constructor, or Load event handler:

myListener = new TextWriterTraceListener("logFile.txt");
Trace.Listeners.Add(myListener);

And you're done! Run the program and then look at the file "logFile.txt" for the output. Hope that helps! Let me know what you find. Sincerely, Alexander Wiseman

If you want, you can post the trace output on the forum here and I'll see if I can help. Sincerely, Alexander Wiseman

I think you can solve this issue by using .NET Reflection. Take a look at this article (TraceListeners and Reflection)[^] - it contains enough to get you started. In the example, the author of the article shows how to log information such as the calling function on the stack and the argument list of that function. He also explains how you retrieve information about the call stack. Hope that helps! Sincerely, Alexander Wiseman

I would put some tracing in a few of those functions to try and narrow down the bottle-neck. For instance, put a System.Diagnostics.Trace.WriteLine call before and after you spawn the new thread. Also put in a trace inside each thread function, at the beginning and at the end. Run the program in debug mode and check the output. It would be particularly helpful to know if your main thread is getting stuck on Thread.Start or on some subsequent function. Sincerely, Alexander Wiseman

Hi shultas, Give the following a try: Search Text Box Settings First, make sure the Dock property is set to "None". Set the Anchor property to Left, Top, Right. This should make the text box expand its width, but not its height when the form is expanded. Search Button Settings Again, make sure Dock is set to "None". Set the Anchor property to Top, Right. This should make the search button attach itself to the right side of the form when the form is expanded, but keep its width the same. Data Grid Settings Make sure Dock is set to "None". Set the Anchor property to Left, Top, Right, Bottom. This should make the data grid expand its width and height with the form when it is resized. Tab Control Settings I'm not sure where your two tab controls are positioned relative to the form, but you'll need to adjust the Anchor property of the tab control which contains the data grid, search text box, and search button. I think you'd probably want to set the Anchor property to Left, Top, Right, Bottom, so that it gets its share of the extra horizontal and vertical space when the form is expanded. Give those settings a shot. If it doesn't work, please let me know and I'll try to help you as best I can. Sincerely, Alexander Wiseman

It isn't just a reference issue, see my other post for details. Also look at this page from MSDN: About Thread Pools[^]. There is a section at the bottom entitled "Best Practices" that sums things up nicely. As regards your second question about apartment models, according to the following quote from another part of MSDN, you cannot use a thread pool thread in STA: "Each thread uses the default stack size, runs at the default priority, and is in the multithreaded apartment." Hope that helps! Sincerely, Alexander Wiseman

Hello, First, as a general answer to your question about threading, take a look at this web-page[^]. It is long, but well worth the read. Jon Skeet (the author of that document) speaks of the difference between thread pool threads and threads created with ThreadStart. The main difference is that thread pool threads are already created and waiting for a job to execute. This means that it is faster to use a thread from the thread pool to do a task. That does not mean it is better, by any means. Mr. Skeet recommends (and I think this is wise) that you use threads from the thread pool if you have a short, quick task that you would like to be multithreaded, but that you should never use thread pool threads to perform long operations. Using threads from the thread pool for long operations is a bad idea because other applications need access to the threads as well. Also, the Framework itself uses threads from the threads pool, so it is bad idea to tie them up for a long time. If the Framework needs a thread and they are all involved in long tasks, then bad things can happen to your application. To sum up: if you have long tasks to be accomplished by other threads, use ThreadStart without a doubt. The extra time and resources it takes to create a new thread will not matter so much. If you have quick and easy tasks which need to be accomplished by other threads, use a thread pool thread. Hope that helps! Sincerely, Alexander Wiseman

:laugh: This gets the best post of the day award hands down! I can just see the Valley Girl SQL compiler error messages now:

line 1: "CREATE PROCEDURE"
compile error, expected token UMM, LIKE, or UHH

Sincerely, Alexander Wiseman

Hello, I don't have an answer to your second question right now, but I can make a suggestion for the first question. My suggestion is to use a grid control which allows you to implement a "virtual grid". Basically, a virtual grid does not store the data in memory for any of the cells in the grid. Instead, when the data for one of the cells needs to be displayed, the control makes a request (some sort of callback function) and retrieves the data that way. This would allow you to store only a small part of the data of your database in memory at a time - namely, just as much data as the user can see at one time. Here is basically how I see it working (I have done a virtual grid pulling from a database before, though my implementation was in C++ and probably not the most efficient one): 1) Application loads and so does the grid. 2) Grid requests data for the first hundred rows. 3) Your app queries your database and gets back a data set with those hundred rows and hands them to the grid view. The SQL pull back is fast, because it is SQL, and displaying the items in the grid is fast, because they are stored in memory. [now there are only one hundred rows in memory] 4) The user uses the scroll bar to scroll down to the next hundred rows. The first hundred rows are now hidden, the next hundred must be displayed. 5) Grid request data for the second hundred rows. 6) Your app queries your databse and gets back a data set with the second hundred rows and hands them to the grid view. This takes about the same amount of time for the first hundred rows. [there are only one hundred rows in memory) And so on: as the user scrolls or searches, you simply pull back the data which needs to be displayed and pass it to the grid. The great thing about doing it this way is that everything takes roughly the same amount of time and is fairly quick, even if your database grows bigger. Obviously the more rows you wish to display at once, the longer it will take and the memory it will take, but this isn't really an issue, because the number of rows that can fit on the screen is limited. Now, I haven't built an application that has had to deal with the volume of data which you are working with, but conceptually I think this idea works. Please take this simply a suggestion, and not an expert opinion. For a C# grid which supports virtual grid, just do a search on this site. One such grid is: SourceGrid[

Hello, It looks like you are placing the size change code inside the constructor for the form. I'm not quite sure why that isn't working, but in an application I am working on, I have initial resizing done inside the Load event handler and it works perfectly. Try putting your sizing code inside the Load event handler instead and see if that works out. For example:

private void FrmOne_Load(object sender, System.EventArgs e)
{
...
this.BackgroundImage = global::Project1.Properties.Resources.img_1;
this.ClientSize = this.BackgroundImage.Size;
...
}

Hope that helps! Sincerely, Alexander Wiseman

Excellent! I'm glad you got it working. The purpose of my second question was to make sure that the serial library was explicitly spawning a new thread and not asynchronously invoking a delegate function. I see by the code you put there that it is indeed explicitly creating the thread, so you probably don't want to kill the thread. I think you solution is perfect, and I understand now why you had said that the thread was still running. Switching to the main thread before doing any of the data processing seems to be the best way to go. Let me know if you run into any more problems :cool: Sincerely, Alexander Wiseman

McSmack, Sorry for the late response. I'm not sure I have enough information to accurately answer your question, but let me ask you two things to clarify: 1) What symptoms cause you to think that the secondary thread is still running? 2) How is the thread created in the serial library? If you don't know, could you point me to the place on this site that has the serial library so I can check the code? I think what may be happening is that your secondary thread is ending, but then more data is sent to the serial port, so your callback function is getting called again and probably causing another dialog box to be displayed. If this is the case, then inside your ShowMyDialogBox function (but after you marshal back to the main thread (i.e. after the InvokeRequired statement) you should check if a dialog box has already been created, and if it has, then do nothing. The best way to do this is to make your secondary dialog variable a member variable of the main form and simply check if the dialog is already created. If it is, don't open another one. Let me know if that helps point you in the right direction. We should be able to work this out! Sincerely, Alexander Wiseman

There is a way to terminate a thread, but it is not generally the best way to deal with a thread which needs to be stopped. The best way is to simply exit out of the function which the thread is processing, which should stop the thread. This may be different, however, depending on how your second thread was created. So, how is your second thread created? From your first post, it sounds like you are not explicitly creating the thread (with code like Thread myThread = new Thread(new ThreadStart(SomeFunctionToProcess));). It sounds rather like a thread is being created by a component you are using and that thread executes the callback code, part of which is calling the ShowMyDialogBox function. If you do not know how the second thread is being created, try this: inside the callback function (the function which calls the ShowMyDialogBox function) make sure that the function ends after the call to ShowMyDialogBox. Also make sure that after the call to BeginInvoke in the ShowMyDialogBox function you have the return keyword - this will force the secondary thread to quit the ShowMyDialogBox after it tells the main thread to process the function with the BeginInvoke function. Final question: what is the method signature of your callback function? Specifically, what are the parameters? If you can get me the answers to these few questions, I should be able to help you out. Sincerely, Alexander Wiseman

Martin, If you want to pass arguments to the method that you invoke, you cannot use MethodInvoker. The other constructor of MethodInvoker won't help you. The function which you specify with the delegate has to have the same signature as the delegate, and because the MethodInvoker delegate has a void parameter list, the method you invoke with it must also have a void parameter list. I'm not exactly clear about what your XXXChanged function is supposed to be doing. However, if you want to invoke the YYYChanged function from it and change back to the main thread, then you can do exactly the same thing you did in the YYYChanged function, like this:

private void XXXChanged(object sender, XXEventArgs e)
{
if(InvokeRequired)
{
BeginInvoke(new ActionDelegate(YYYChanged), new object [] { e } );
return;
}
...
}

If you do not need to change threads and you want to call the function YYYChanged directly from XXXChanged then I see no reason to use the Invoke function. Let me know if that helps you out. If not, could you be a little more specific with what you want the XXXChanged function to do? Sincerely, Alexander Wiseman

Martin, You won't be able to invoke a method with parameters if you are using the MethodInvoker delegate. Here is what MSDN says about MethodInvoker: "MethodInvoker provides a simple delegate that is used to invoke a method with a void parameter list. This delegate can be used when making calls to a control's invoke method, or when you need a simple delegate but don't want to define one yourself." Since MethodInvoker has a void parameter list, and since the function you specify must have the same parameters as the delegate in question, you won't be able to invoke a method with parameters using it. In order to do this, you need to define your own delegate, which has the correct argument list. Let's suppose that the function you want to invoke by BeginInvoke has two parameters, a bool and a String, and that it looks like this:

public void ShowMyDialogBox(bool bTest, String message)

Now, you would define your delegate like this:

public delegate void MyDelegate(bool bTest, String message)

The name of the delegate is completely optional, as are the names of the parameters. We could have called the boolean parameter anything we want (e.g. bBoolParam) and we could have called the string parameter anything we want. Now we would invoke this as follows:

BeginInvoke(new MyDelegate(ShowMyDialogBox), new object [] { varToBeParam1, varToBeParam2 });

So now, if we put that together, our ShowMyDialogBox function would look something like this (assuming the scenario which McSmack had laid out):

public void ShowMyDialogBox(bool bTest, String message)
{
if(this.InvokeRequired)
{
this.BeginInvoke(new this.MyDelegate(this.ShowMyDialogBox), new object [] { bTest, message });
return;
}
// now we're on the main thread and can do processing as normal
// the parameters also have their proper values
...
}

Hope that helps! Feel free to respond if you have any more questions about this, or if you do not understand something in the answer. Sincerely, Alexander Wiseman

Excellent! I'm glad it worked out for you. :cool: Sincerely, Alexander Wiseman