Sorry for responding late. My A/C went out last night, and I need to get a window unit in for temporary use. In the meantime, it is 91degF inside my home and I can only use my laptop for brief stints, that with a cooler pad underneath. My desktop computer needs to stay shut down.

I'm not going to get into this any further because you're beating a dead horse. But, to add to the description that Ron just posted, in your description, you're ASSUMING that both of your background threads are running at the same time. This is NOT the case! Both threads, MAY be running, or one thread will run and the other won't be, or neither of them will be. Oh, and you're also assuming that threads will run in the order created. None of this is true. Threads can run in any order, for any amount of time, not necessarily the exact same size timeslice. Normally, the only time you ever look at ThreadState is when you're waiting for it to spin up or waiting for it to end. That's it. Any other use is not reliable as a synchronization method. A guide to posting questions on CodeProject[^] Dave Kreskowiak

Eddy Vluggen wrote: Check your usings; is there any "Module2" in the other namespaces? No, no others. Eddy Vluggen wrote: Modules are initialized on first use, and the compiler has no incentive to change that behaviour. OK, I think I see what you mean. The form_load procedure is referencing two variables with each declared in each module. Since they are both referenced in the form_load procedure, both modules initialize. But when I change the variable in module2 to "z" instead of "y", there is no reference for it in the form_load, so the compiler deems module2 uneccessary at the present time. At least a test of this confirms it in principle. Eddy Vluggen wrote: those x and y values should be prefixed with their module-name That part I knew about...I was just making a very simple demo which was not "safe".

DoH!...I should have known better, but I forgot...Many years ago, I first learned about subclassing to solve a graphics issue, and should have recalled that subclasssing is, in a way, a sort of "hijacking", in that you make Windows THINK you are using a standard WindowProc(), when in fact you have redirected execution to a function of your own making. That way, Windows is satisfied, and you get to do neat stuff as a result.

It was already there[^], yes :) Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

After studying this for a while, It seems that setting up an action and an extension is really just a simplification of doing an explicit delegate and attaching a method to it. So my existing code should do the same thing, then, except that I think I have the guts wrong in the Run() procedure and other places. Unless my assumptions are wrong, it seems that before I jump into Actions and Extensions, I need to understand the explicit delegate approach. UPDATE: I am running your extensions idea, and I can get the b/g thread to run a task, but I am still not getting the button to respond, once I have the main thread caught in a long task. I was thinking that part of my problem is that I don't think the background thread is monitoring mouse behavior. When I start the program, the Form_Load sub starts the background thread, which gets the delegate going and the Run() sub is called. Even if I make the Run() procedure a continuous loop, it is going directly to the button click procedure every time, regardless of whether or not I have clicked the button. That part seems to make sense...Why would I WANT it to keep looping through the click event?! So I think I have one choice in that respect: 1. Have the Run() procedure monitor mouse behavior continuously, and when any button is clicked, check sender and only go to the Pause_Continue button click handler when it was the button in question. A monitor like that sounds like some sort of event listener. Not sure how to do that without some API functions. UPDATE 2: After researching some more, it looks like maybe something involving WithEvents could work. UPDATE 3: Now it looks more like AddHandler/RemoveHandler is the way to go.

Lol! There you go. ...That's a true story by the way. Happened this afternoon. :)

Ahhh, but of course. Unless the compiler has a magical fix.

Ahh, OK. Then my theory is poop. :) I will have to invent a new theory about something else, then! Thanks for the clarification!

Hey, has anyone heard of the Delimon.win32.IO library? I just ran into it at MS and it it is a direct replacement for the System.IO functions, with same function names, to boot. The great part is that it crosses the MAX_PATH barrier by design. It requires NET Framework 4. So that means VS2010, unless there is a way to get VS2008 to see it. If someone mentioned this earlier, I apologize. But I did not find anything on it when doing a search here. I have added a reference to it in my project and am about to test it. UPDATE: Is NOT a direct replacement! Going through the properties/methods, a lot are simply not there, or stuff has been moved around and called by different names. Not sure if it completely covers all the functionality of System.IO. Also, since it requires framework 4, I don't think WinXP can use it. Which is a bummer since there are still a lot of XP systems out there. UPDATE 2: It MAY be a direct replacement after all...I might have attempted to type in methods while the dll reference was not properly set up. At any rate, this is a brand new library apparently, and it IS buggy. For instance, Directory.Exists and File.Exists methods do not filter correctly...Each returns "True" regardless of whether the resource is a folder or a file.

But the example program I showed does basically what I'm suggesting. So it doesn't SEEM like a kludge. Especially since all I basically have is one procedure that I need to thread, and everything else is called from it sequentially. So from a performance point of view, it all has to work sequentially anyway, so my only benefit from threading is to have the ability to pause execution at will, which was the primary reason to begin with. Is that a reasonable enough reason for doing it that way? I don't see any future versions of this program gaining any other benefits from threading.

Dang. I was afraid of that. I think i buggered it up! :( I'm going to have to go through it with a fine tooth comb, and figure out what I did, then. Which may just be an exercise in understanding something I will never use again. As I research threading more, there might be a reasonably easy way of making the transition to it.

Heheh...That's why I didn't want to go that route. It's a lot of work that is for temporary use. Oddly, though, I had already set up a logging system for this program to write to a text file at key points in the code, so that any customers who buy my program could send me that file if they run into any bugs. The only thing missing are the time stamps. So, come to think of it, since it's already in place, it's not such a big deal to add time stamps. As for the two profilers I located: This one is free, but appears tailored to AMD chips: http://developer.amd.com/tools/heterogeneous-computing/amd-codeanalyst-performance-analyzer/ This company has a free version of their product, but didn't have time to check what it's limitations are: http://eqatec.com/Profiler/Download.aspx?BannerId=1&VendorId=1&PortalId=0

Eddy Vluggen wrote: Search CP, and you'll find that a lot of people think something similar. Well, at least I'm not alone. Eddy Vluggen wrote: The moment I recognize the repeating pattern; same code, same handler, just a different level. Neat piece o' code that TnTinMan posted, mine would have been longer Problem is I couldn't find a way to generalize the repeating code. I looked all over for something to do just that and continued to try to solve it, but my unfamiliarity with the TreeView properties bit my ass. That really is a nice compact piece of code. After looking at it, it seems that what makes it work, is that once each match is made, what is important is the handle of the node. Otherwise, since two nodes can have the same name and text label, there would be no way for vb to know what node was being referred to. But the handles are all different. I tried working with the handles earlier, but could not find a way to get a node selected based on its handle.

Thanks, Edward! I'll check into it and report back.

You need to expose the properties you want to modify in your user control. For example, to change the column count property of the table layout control, from your user control, you have to expose the ColumnCount property: c# Control public partial class UserControl1 : UserControl { public UserControl1() { InitializeComponent(); } public int ColumnCount { get { return this.tableLayoutPanel1.ColumnCount; } set { this.tableLayoutPanel1.ColumnCount = value; } } }

Makes total sense.

treddie wrote: Thanks for all your help, Eddy! My pleasure, glad I could help a bit :) Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]

You're welcome :)

Ahhhhh, OK. Was right in front of me the whole time. Thanks for the brain reset.