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.

Ah, cool. Thanks for the clarification. I think you just made my day in getting my mind around delegates and Invoke, and how they relate.

Ron and everyone, thank you for your replies. I think the last post is pretty much what I am saying in my hypothetical example that Ron responded to. But in going back over what everyone has said, I still don't see how, once a thread is suspended and queried, that the result should differ afterwards when that very result is then stored in a string variable. The thread is suspended and is not processing any more of its operations. "When you get the value of a property, the debugger executes the property Get code, so the thread isn't entirely stopped. As was already mentioned, the act of viewing an object changes it's state!" If the Schrodinger's Cat analogy is used, it means that when a suspended thread is queried, it for some reason then processes at least some more lines of code OTHER THAN the Get property, that could change that value. Get should not be able to allow its thread to process any other code, like any equations that were about to be executed but were halted. But even then, only one query has been made. When afterwards, that result is stored in a string, it has already been "captured" and is simply sitting there, being copied over into the string. Immediately after the query, shouldn't interaction with that thread already have been finished? The query has been made, which means a result has been pulled OUT of the thread. So the result is now isolated from that thread. The thread is no longer involved and can't somwhow reach out of itself to change that returned value. So the string copy should match the query result, exactly. If what you suggest is true (and maybe it is :) ), that is analogous to taking a digital picture of someone with a camera, and then when you copied that image over to your harddrive, it changed into a picture of someone else!

Hi, Ron. Thanks for your response. I am referring to the fact that a form's controls cannot be directly accessed via a thread other than the main thread that runs the form itself. Delegates are required. That being the case, if I have a TreeView that must be updated from a second thread, do I need to create separate delegates for each and every method I will use for the TreeView? It seems that unless I always use multiple TreeView methods in a set order, and put all of that into a sub that will have a delegate assigned to it, then I will need to do them all separately. Hm...just thought of this...Unless it is possible to create a delegate for the entire TreeView class.

Hi again. I am a little confused about setting up delegates. I believe this is correct: If I have a number of individual statements such as:

MyLocalTreeView.TreeView1.SelectedNode.Parent.FullPath
MyLocalTreeView.TreeView1.SelectedNode.FullPath
MyLocalTreeView.TreeView1.SelectedNode.Expand()
Me.MyLocalTreeView.TreeView1.Focus()

am I correct in assuming that separate delegates for each must be built, if they do not all happen together in some recurring usage where they would all be lumped together in one sub? Thanks for your help!

Sorry for the frustration showing. But in an attempt to understand what is going on, here is the way threads should behave the way I understand it. Let's say I have two threads that calculate the results of some equations: Thread-1 produces 1........2....... 4.......8........16.......32 Thread-2 produces 1.5....1.837....2.49....3.929....7.789....21.737 1. All threads are suspended at time (t). Since Thread-1 is iterating faster than Thread-2, due to simpler equations, Thread-1 makes more progress than Thread-2, by time (t). 2. Since the exact moments that Threads 1 & 2 will be suspended will most likely occur asynchronously, this may add further uncertainty as to when Threads 1 & 2 will actually come to a halt. This could result in another complete iteration "slipping through" in either thread. But most likely, each thread will be suspended somewhere in the middle of an iteration. Nonetheless, the output values will not change until an iteration is completed. 3. At time (t + DELTAt), queries are made of the results from Threads 1 & 2. Obviously, both queries cannot be made at the exact same moment. So let's say that Thread-1 was queried first, followed by the query of Thread-2. The results are: Thread-1.....16 Thread-2.....2.49 4. The queries are NON-suspended actions performed on suspended Threads 1 & 2. Therefore, the results should be the same regardless of when the queries were actually made. Thus, the queries are actions that do not affect the results, once the threads have settled down into their suspended states. There will be many times when the above timing disparities will not be an issue...I may simply need to see the results at time (t) regardless of any synchronization issues. If I need better synchronization so that the outputs are synchronized at some value of an independent variable, then I can simply stop each thread independently on separate time-dependent bounds. Beyond that, why, in your understanding, would the queries affect the results?

That's what is annoying about it. When you take the string representation of an object at any given moment via the ToString method, nothing should change in that moment, and it should be valid as a value. For in that moment, you pulled out a piece of information that in many cases will be used immediately. If vb allows the printing of a value from ThreadState, then that should be the same thing as "printing" it to a string which is nothing more than a storage spot for the same thing. It should be, anyway.

Thanks, Amitosh. Seems awfully convoluted. But that's Microsoft, I guess.

Hi, all. Once again, vb.Net shows how convoluted it can be. Or I'm just stupid. Assume I have a background thread running. Then, if in the Immediate window, I type in

?m_Thread.ThreadState.ToString

I get back, "Background". But if I first assign ThreadState to a string variable:

Dim ThreadState\_str As String
ThreadState\_str = m\_Thread.ThreadState.ToString

and type in

?ThreadState_str

I get back:

"Background, WaitSleepJoin"

What is going on here?!

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".

Hi. I have encountered a peculiar problem with modules that I have never seen before. Here is a very simple example to demonstrate my point:

Module Module1
Dim x as integer = 1
End Module

Module Module2
Dim y as integer =2
End Module

Private Sub Form_Load(bla, bla, bla)
Me.Text = Str(x+y)
End Sub

When the program runs, both modules are automatically initialized so that the result is the value "3" getting sent to the form. Up to now, I have never had a problem with modules not getting initialized. But in a new project I am working on, one gets initialized and the other does not. One of them simply does not get recognized. Adding Public to both/either does not help. Does anyone have an idea as to the kinds of things that can cause this to happen? Many thanks! :)

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.

Thanks for the clarification, TnTinMan. Much obliged. So much to learn...So little time! :)

Gawd I'm so stupid sometimes. I was driving home from the store today, and realized I hadn't started the listening process during form load. My version works now...You're version worked perfectly from the get-go. But furthermore, to get mine to work, I had to change the function declarations to the "other" style. From:

Private Declare Function SetWindowLong Lib "user32" (ByVal hWnd As IntPtr, \_
                                                     ByVal nIndex As Integer, \_
                                                     ByVal newProc As Win32WndProc) As IntPtr

Private Declare Function CallWindowProc Lib "user32" (ByVal lpPrevWndFunc As IntPtr, \_
                                                      ByVal hWnd As IntPtr, \_
                                                      ByVal Msg As Integer, \_
                                                      ByVal wParam As Integer, \_
                                                      ByVal lParam As Integer) As Integer

To:

\_

Private Shared Function SetWindowLong(ByVal hWnd As IntPtr, _
ByVal nIndex As Integer,
ByVal newProc As Win32WndProc) As IntPtr
End Function

\_

Private Shared Function CallWindowProc(ByVal lpPrevWndFunc As IntPtr, _
ByVal hWnd As IntPtr, _
ByVal Msg As Integer, _
ByVal wParam As Integer, _
ByVal lParam As Integer) As Integer
End Function

Why is one different than the other? I notice that the first is not shared and the second one is. But I have never encountered any problems before using the first syntax.

That is the function, but the problem is the last argument, dwNewLong. In vb6, you could just use AddressOf dwNewLong and the world was happy. But in vb.Net you can't do that because its AddressOf() does not return an address, but a delegate object.

That's what I couldn't understand, was how to get the address out of the delegate. But one of the things I still get caught up with is that the documented data types for API functions are apparently not sacrosanct. I guess there is some leeway via overloading (which seems hard to find info on in the official sources). In that regard, is overloading the same as subclassing?

Thanks Richard! I am trying out all three suggestions to see what happens!

Thank you, Bernhard! I am testing it now.

Thanks for the link! I tried it and it does not work, yet. I am assuming that WindowProc is constantly listening for events, so that no button-click handler is required (which would defeat the purpose of using the API, anyway). But as it it is written now, I think it is deaf! :)

Public Class Form1

'A delegate that matches Win32 WNDPROC:
Public Delegate Function Win32WndProc(ByVal hWnd As IntPtr, \_
                                      ByVal Msg As Integer, \_
                                      ByVal wParam As Integer, \_
                                      ByVal lParam As Integer) As Integer

'-----------------------------------------------------------------------------------------
'-----------------------------------------------------------------------------------------
'Win32 API functions:

Private Declare Function SetWindowLong Lib "user32" (ByVal hWnd As IntPtr, \_
                                                     ByVal nIndex As Integer, \_
                                                     ByVal newProc As Win32WndProc) \_
                                                     As IntPtr
    ''Aother version of SetWindowLong that takes 2 pointers:
    'Private Declare Function SetWindowLong Lib "user32" (ByVal hWnd As IntPtr, ByVal nIndex As Integer, ByVal newProc As IntPtr) As IntPtr
        ''And call it like this:
        'Dim MyAddress As IntPtr
        'MyAddress = SetWindowLong(hWnd, GWL\_WNDPROC, oldWndProc)

Private Declare Function CallWindowProc Lib "user32" (ByVal lpPrevWndFunc As IntPtr, \_
                                                      ByVal hWnd As IntPtr, \_
                                                      ByVal Msg As Integer, \_
                                                      ByVal wParam As Integer, \_
                                                      ByVal lParam As Integer) \_
                                                      As Integer

Private Const GWL\_WNDPROC As Integer = -4

Private Const WM\_LBUTTONDOWN As Integer = 513

'--------------------------------------------------------------------------------------------------------
'--------------------------------------------------------------------------------------------------------

'Program variables:
Private oldWndProc As IntPtr = IntPtr.Zero

Private newWndProc As Win32WndProc = Nothing

Private Sub SubclassHWnd(ByVal hWnd As IntPtr)

Hi. I think an answer to this problem lies in the use of delegates and marshaling, but if so, I cannot figure this one out. In vb6, you could use the AddressOf method to get the address of a function. vb.Net no longer allows such a simple idea. Some have even suggested that you do not need to get the address of a function. Apparently they do not use API functions, where getting the address of a function is essential. Now, in vb.Net, if you attempt to use AddressOf(SomeFunction), as in:

lPrevWndProc = SetWindowLong(hControl, GWL_WNDPROC, AddressOf WindowProc)

You get the following error:

'addressof' expression cannot be converted to 'IntPtr' because 'IntPtr' is not a delegate type

MSDN is as obtuse as ever when describing this problem where a simple example of how to replace the as-simple-as-it-gets vb6 "AddressOf" method with a vb.Net method would have been the obvious thing to do. I reference: http://msdn.microsoft.com/en-us/library/ms184628%28v=vs.90%29.aspx[^] which explains no more than the IDE message does in that respect, so they might as well have not even created that link. They offer other links to study which venture off into space because...All they needed to do was offer a simple comparison of how to do in vb.Net, to what was done in vb6. I have searched high and low for an answer and all I have found is frustration. Any help would be greatly appreciated. HELP! SOS!