How to achieve true 100% multi-threading in VB. OLD THREAD

Would a simple approach be to have your main app, and it creates a few instances of an activex control or class or whatever you want.
Now, you give to it the address of various functions in your application, and it can then, through the use of CallWindowLong (If I remember the API name correctly!) call those functions as they need to...

Look, you must know by now that I don't do simple :D

Hahahaha...

Is CallWindowLong like an API version of CallByName?
Wouldn't this be like using SendMessage, in the sense that it won't return execution until the function I have called is finished?

Can't find that API in APIGuide :(

Woka

Sorry. I keep getting it wrong, its this :

VB Code:

Declare Function CallWindowProc Lib "user32" Alias "CallWindowProcA" (ByVal lpPrevWndFunc As Long, ByVal hWnd As Long, ByVal Msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long

You call it, but it doesn't wait for a response. It just does its thang and then that's that.
Well from what I remember anyway!

I have some sample code at home for calling a function by its address. I can show it to you tonight.

Cool. Will be on laterz tonight, around 9pm'ish.
However, you will still have to read the parameters from the client processes memory.
My exmples use the uMsg to tell the app what function/sub to execute, and the lParam as the memory location for the datastruct UDT. I would still have to pass the lParam with this API...

I am failing to see how this can be easier??? :(

Mind you, I have been doing documentation for the last 4 ****ing days and my head is fried...plus I have other things on my mind as you well know ;)

Woka

Well the only time I've used this, it was to call a parameterless function - basically to kick off another function.
And if I remember correctly, I think duncan said that that's only for code inside the same process's memory space.

Don't remember though. I'll have a fiddle tonight.
... speaking of which, and what's on your mind, ... ;)

Maybe for a paramater-less function this may be ok, but I feel that using Postmessage and the uMsg to determind what function to run may be a better method in the long run. The code will be almost identical, yet using Postmessage gives you more functionality and makes the app easier to maintain.

Am still intregued mind you...:)

Woka

Here's the code. Basically I have 3 screenshots built into one of my applications. They're compressed into the VB code.
I have a window in the app taht the user might want help on.
On it is this :

VB Code:

Private Sub lblLink_Click(Index As Integer)
    Dim imgHandle As Long: imgHandle = -1
    Dim strHeading As String, strContent As String
    Set callingForm = Me
    Select Case True
        Case Index = 0 Or Index = 1:
            [b]imgHandle = getAddressOf(AddressOf modScreenShot1.getFile)[/b]
            strHeading = "Create & Share Folder"
            strContent = STR_DOC_1
        Case Index = 3:
            [b]imgHandle = getAddressOf(AddressOf modScreenShot3.getFile)[/b]
            strHeading = "Copy Files"
            strContent = STR_DOC_2
        Case Index = 4:
            [b]imgHandle = getAddressOf(AddressOf modScreenShot2.getFile)[/b]
            strHeading = "Modify User Scripts"
            strContent = STR_DOC_3
    End Select
    makeDocumentationWindow strHeading, strContent, imgHandle
End Sub

Then the makeDocumentationWindow function is declared in a code module as follows :

VB Code:

Public Sub makeDocumentationWindow(ByVal strTitle As String, ByVal strContent As String, Optional imgHandle As Long = -1)
    With frmDoc
        .Hide
        .Caption = .Caption & strTitle
        .lblShowImage.Visible = Not imgHandle = -1
        .lblShowImage.Enabled = .lblShowImage.Visible
        .imgImageHandle = imgHandle
        With .rtbText1
            .Text = strTitle
            .Find (strTitle)
            .SelBold = True
            .Text = .Text & vbCrLf & vbCrLf & strContent
            .SelStart = Len(strTitle)
            .SelLength = Len(Mid(.Text, InStr(.Text, strTitle) + .SelStart))
            .SelBold = False
            .SelStart = 0
        End With
        centerMe frmDoc: .Show
        SetTopmost frmDoc, True
        .cmdClose.SetFocus
    End With
End Sub

The frmDoc window has the following code. This form is what actually displays the help information, and gives the user what looks like a hyperlink to generate the image.

VB Code:

Option Explicit
 
Public imgImageHandle As Long
 
Private Declare Function CallWindowProc& Lib "user32" Alias "CallWindowProcA" (ByVal lpPrevWndFunc&, ByVal hWnd&, ByVal Msg&, ByVal wParam&, ByVal lParam&)
Private Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpvDest As Any, lpvSource As Any, ByVal cbCopy As Long)
 
Private Sub cmdClose_Click()
    Unload Me
End Sub
 
Private Sub Form_Unload(Cancel As Integer)
    If callingForm Is frmA_1_Splash2 Then frmA_1_Splash2.cmdNext.SetFocus
End Sub
 
Private Sub lblShowImage_Click()
    MousePointer = vbHourglass
[b]    CallWindowProc imgImageHandle, 0, 0, 0, 0[/b]
    imagesUsed(UBound(imagesUsed)) = tempPathToUse
    ReDim Preserve imagesUsed(UBound(imagesUsed) + 1)
    SetTopmost Me, False
    [i]StartDoc tempPathToUse[/i]
    MousePointer = vbNormal
End Sub

Now, I have attached modScreenshot3 so that you can see what getFile() does.

You'll see that I'm using a module level String variable - tempPathToUse (italicized above).
That variable is populated inside getFile() in modScreenshot1, modScreenshot2 and modScreenshot3.

The screenshot modules are generated using this code :
http://www.vbforums.com/showthread.p...hreadid=195896

Arggg where was this fabulous code about a year ago when I was trying to write a FTP Client in VB. I gave up when I got to testing it and couldn't download more than one file and do stuff in the program simultaneously even with doevents pasted everywhere! I knew multithreading was what I needed and at the time the only way I knew of to do it was unreliable.

hmmm now to find that old code and restart that project! =)

Hey Woka, I have two questions for you.

The first is just to make sure I'm right about something... the MyThread.exe is where I would change to my forms and functions for whatever I need multi-threaded and the thread proxy I would just have to change to transfer the approriate variables and stuff correct?

And also I noticed in the vbtools2 a memory thing, If I'm not mistaken couldn't I use this to accomplish what I asked in my other post about reading memory?

Steven

Errr...Yes. U will also need to update the UDT's in the MyThread project as well as the ThreadProxy project.

What was your memory question? What memory are you trying to read?

The code was lurking around as a concept in my drug fueled brain...sorry :D

Well the thing is, I'm a total n00b when it comes to tampering with the memory. I've never tried to tackle it yet. But I want to be able to take a running application and get everything it has in the memory if that is even possible?

I havn't looked at your memory code much but it seems that it might in fact be able to do this?

I think your best bet here is to chat to Merrion, he's the god of all that type of programming :D

Woka

In thiis project how can i get the ThreadUI to destroy the thread once the search has finished?

many thanks

Woka

Nice work.

Hey a while back in the this thread you said that you don't like to use GOTO statments. If that is the case how do you make a jump over a chunk code if you want to skip it for one reason or another? This would be in a situation where if conditions are met you want to skip some code but not exit the sub or for etc...

I've been able to arrange if statements so that they do the trick sometimes but some times I just can't do it with ifs without nearly doubling the amount of code needed to get the job done. Is there some other method that you use in these situations?

Thanks

David

Quote:

---

Originally posted by David RH
Woka

Nice work.

Hey a while back in the this thread you said that you don't like to use GOTO statments. If that is the case how do you make a jump over a chunk code if you want to skip it for one reason or another? This would be in a situation where if conditions are met you want to skip some code but not exit the sub or for etc...

I've been able to arrange if statements so that they do the trick sometimes but some times I just can't do it with ifs without nearly doubling the amount of code needed to get the job done. Is there some other method that you use in these situations?

Thanks

David

---

I'm not trying to be sarcastic here but If/Then/Else.

Edit: I see you've tried that. Can you post some code (probably best done in a different thread) where you need help eliminating GoTos?

I am lost. What have Goto's got to do with multithreading?
I don't use goto's...well very slightly in error handling.

Nosh...?! I thought we sorted this problem out last week??? :confused: Zzzzzzzzzzzzzzzz I am tired.
After the search loop has finished just do:

VB Code:

UnLoad Me

And that should do the trick.

Woka

Well ...

Back in the middle of the ton of posts to this thread you told someone no thanks to their code donation because you don't use GOTO statements. So I was wondering if you had some special way to handle a jump when you can't get an If...Then... Else statement to work without writing a whole lot of extra code (sometimes nearly double).

I probably shouldn't be responding to this post this late at night when I'm tired as I might respond in kind But I'm curious about a possible alternative way of doing something more efficiently.

Sorry to have bothered you.

David

U can always get an IF THEN statement to work. I only use Goto's for err handlers...

VB Code:

Dim Sub Woof()
On Error Goto ErrHandler:
   'Code to handle sub
   Exit Sub
ErrHandler:
   'Code to handle error
End Sub

They arn't classes as proper goto's really.

Why can't you get the IF THEN statement to work??? You could split your code into sperate smaller subs so that you don't have to replicate it.

Woka

I have created a new demo project.
Full working 3 tiered app that uses multithreading to monitor DB tables and thus not affecting the performace of the client while the Db is being queried for changes.

http://www.vbforums.com/showthread.p...postid=1606760

Have fun.

Woof

The way I see this is that the post message API is being used to post a message and execution then continues. The thread performs the processing and then sends a message back to the calling process.

What I want to do is to create a system that uses multiple access databases to seach for a record in paralell petween all databases. This means that a single thread would search each database. Question is, how would I return the result? Use property bags?? Is there a way that I can just use the address of a recordset to return the info? Whichever is easiest....

Also, is there a way that this example can done using fewer files???

U return the result in a UDT. That's what I do in my example. I send the file details to the client UI using a UDT. However, you could replace this with a property bag, since it's a byte array and you know it's memory address and length. U could send these details in the Send/PostMessage API.
To reduce the files you could place the class code for the thread procy in the main app. But 2 apps in the min. Client and ActiveX thread...

Does that help?

Woka

So where's the latest and greatest non buggy version?
Someone post it please.

Jon

A new an improved demo is in the pipe line.
Should be done by either tonight, or tomorrow.
The new version will be a winsock demo.

It will allow you to start a session:

VB Code:

Dim objSession As SvrSession
   Set objSession  = New SvrSession
   objSession.Start [Port], [DLL Name], [Class Name], [Method]

This server side DLL handles winsock connects automatically, each of which runs in a different thread.
The reason you can pass in a DLL, Class and Method name is so that if the command set between the client winsock objects and svr winsock objects, is not an internal one then you can pass the data sent onto another DLL, which is relevant to your app.
This allows you to use the same winsock objects in many many different applications without have to code each one individually.

So I could have 2 apps using the same winsock code...One app will have:

VB Code:

Private objSession As SvrSession
 
Private Sub Form_Load()   
   Set objSession  = New SvrSession
   objSession.Start 40000, "MyDLLName", "clsData", "ProcessData"
End Sub

and the other app simply has:

VB Code:

Private objSession As SvrSession
 
Private Sub Form_Load()   
   Set objSession  = New SvrSession
   objSession.Start 40500, "AnotherApp", "clsMyData", "DealWithData"
End Sub

Connects will be able to be viewed and destroyed VIA the client side :D

I am almost there...just jigging my code and trying to get it as neat as possible.

Oh, and the winsock runs syncronosly...this means that when your client sends data it does not get control back UNTIL the server has processed the data and has sent a response back to the client. This is one thing normal winsock control doesn't do.

Any other functionality you may want to see in this?

Woka

Quote:

---

Any other functionality you may want to see in this?

Woka [/B]

---

Yes have it wipe my a**:bigyello:

Here's is the new tool I have been working on :)

http://www.vbforums.com/showthread.p...hreadid=286613

Let me know what you think.

This will aid multithreading applications no end.
Will try and add this tool into the file searching example I wrote earlier. The code will be dramatically reduced due to this new DLL.

Woka

hi woka

Quote:

---

To Woka:
remember me, i'm the fellow who's struggling to deny the very
unacceptable fact of vb's inability to thread and vow to create
a dll that provides threading services?

since the last time i posted here, i did some lil' research on
threading. But then I abandoned it and continue with my p2p
networking and dx raycasting engine projects.

Your method works pretty good, using PostMessage to place
messages on queue, which the thread will retrieve sooner or l8er,
without u waiting for it and continue with ur execution. **I salute
u, Genius!**

Thinking back, i seem to understand somethin'. U mentioned it's
impossible to call subs unless pre-defined, which ultimately
requires u to rewrite the thread proxy althogether from scratch
for each different project, rite? Since u perform things not based
on sub calling, but recognizing messages and do things
accordingly, which is pretty limited really.

---

In the end, I know it's not quite possible to make a dll out of this.
Like i posted earlier, I want to understand how and why it fails.
But how about this?
With some speed trade off, we could use CallByName to make
hell a paradise, how's that? Different Messages for different
functions is too spagetthi.
well u probably have thought about it earlier as well as with its
pros and cons(more cons actually maybe) but letme try it out.
i'm quite n00b in stuffs like this.

Don't quite see what you mean about the CallByName function :(

Here's a newer more uptodate multithreading DLL. This version is SOOOO much simpler than the 1st one I posted here :)

http://www.vbforums.com/showthread.p...hreadid=288289

WOka

Conventionally, if we're to use apartment threading, we've to use
ActiveX exe, rite?
To create a thread, we've to use CreateObject. New keyword
doesn't work here. Unfortunately, another thread including the
parent is created in another memory workspace.

So, when I said I wanted to turn it into a DLL, so that it makes
threading easier since it's managed as an object, u said it might
not be possible.

Well, based on above points, it's either I dont understand ur code
enough(perhaps I need ur further explanation), or it's weird that
ur ThreadProxy is a DLL, whereas the object u are threading is an
ActiveX exe. Confuse me enough. Or probably it's the
MyThread exe that's threading it and ThreadProxy just create
ThreadObject for MyThread to thread it?

My naive idea is like this:
We've a DLL which has a Threader object, of which under it's
hierachy is a ThreadProxy object. ThreadProxy creates a window,
wnd1. Under ThreadProxy is another ThreadObject with a
created window, wnd2. Say, If we want to thread "Wscript.Shell"
object, ThreadProxy will CreateObject out of it, and pass it
to ThreadObject(or ThreadObject create itself?).

From the container which contains this DLL, we issue a command
like 'Wscript.Run', then we pass this along to ThreadProxy.
ThreadProxy creates a UDT containing the command and
parameters, then POST a message to wnd2. Wnd2 gets it and get
the UDT's mem address as well. Then ThreadObject gets the UDT
and through "CallByName', it calls the command as contained in
the UDT.

You are right.
The reason my 1st demo had a thread proxy DLL, was to split this away from the UI.
This means if I wanted to use the file searching in another app, I just referenced the DLL.
The code for this DLL could have easily have been in the UI it'self.

The version you are describing there is an old out of date one.
If you look at the code I posted in the link in my last post you will see how much the code has changed. Easier to undersatand, and more generic.
There are 2 examples with that post.
One allows 2 normal EXE's to communicate together, and the other uses an activeX EXE multithreading file searching example, like the one in my 1st version.

Let me know if you have any questions.

Woka

No, sometimes old things teaches new things.
Your old code has less things to do (Just adding numbers),
therefore the code might not be as clutter as the new one.

Anyhow, i'll look at that one.

Threading is provided to us already by VB through ActiveX exe.

But your method is to allow us to return from a function as soon
as we call it while letting it busy on its own? Which we couldn't
possibly do in VB eventhough threading is provided?

Remember the SetTimer I once said? I said it was from a code of
mine that I unknowingly uses multithreading, delusioning me that
SetTimer making some charms.

Now thinking back, why don't we put a Timer on the new thread?
It might check on a queue data structure to check if there's any
functions need to be called along with their parameters. With
Timer, we don't have to wait for return.

Have you actually looked at my code?
Why on earth would you want a timer in the ActiveX EXE.
I have a subclassed window that looks for messages.

VB does allow you to create threads, but what it doesn't allow you to do is to access the thread while it's processing.

I VERY VERY VERY cheap nasty hack is to use a timer on a form in the active X EXE. You can a function that stores a value to let the app know which function has been called, and then the timer is enabled. The user interface returns from the ActievX EXE and continues running. The ActiveX EXE timer fires and NOW the function is called properly and the ACtiveX EXE starts works. Very crappy way :( The UI and the Active XE exe CANNOT communicate with each other now :(

That's probably how your timer was used. This is the cheap hacked way of doing it, and I would never use that.

My old code IS MORE cluttered. It didn't just ADD 2 numbers together? What? I don't understand? Or are you talking about a VERY VERY VERY old example?! The examples posted here are file search examples where you can start many searches that all run in their own threads. These examples pass large data structures back and forth, and are slightly better than a thing that just adds numbers.

Woka

yea precisely, and I understand ur app well.
And yea, it's an old example, but I did look at that new one, too.

Quote:

---

VB does allow you to create threads, but what it doesn't allow you to do is to access the thread while it's processing.

---

well, does this apply to your method?

U mean, as the thread gets the message from wndproc and
processes it, u can't access it, but in what way u can't access it?
Its members, its props?
In ur example, not even ThreadProxy could access its props if it
wants asynchronousness, which led u to use PostMessage.

And why u can't communicate during that interval? Dont
understand.

I've done one, using ur method, and gosh it worked too well :)

And ur method of changing a datum directly to another type
through udt LSETting is really gr8.

You are still refering to an old example.
The new example doesn't use UDT's :)

There is a link in one of my posts about 5 up from this post. That's the new version. No ThreadProxys, no UDT's, no adding 2 numbers together.

Right OK, added to this post is an example of multi threading, but not a good one. This shows you the problems that my method over comes.

Copy the thread Active X EXE.
Open the UI project, reference the thread active X EXE, and compile.
Now run.
You will notice that when you click on "Get Bagder" button it gets and displays a property from the active X EXE.
Now start the loop in the thread, which uses the timer method.
While this is looping, start the loop in the UI. This demos that they are in fact running in different threads.
Now the problem arrises :(
Start the thread looping again, and now try and click the "Get Badger" button. You UI will hang. if you try and move or click on the UI app you get that stupid "Switch To" error. This function WILL NOT succeed UNTIL the thread has finished looping.
So if the get Badger button was in fact a cancel button then this would not work.

Does that make things clearer?

Woka

From what u say, I guess I know what you're saying.
But this shouldn't be VB's limitation, it's natural to think that we
can't access the thread because it's processing things in tight
loop. Which means other languages behave such as well.

I'll check them out.:)

This IS VB's limitaion :(
Which is why I wrote my multithreading DLL. This gets around this problem by using some complex coding and memory manipulation. You think I wrote that code for a laugh? Not a chance...that code is ALL needed I am afraid.
VB does not handle multithreading. This has to be coded in, like I have done.

Other languages handle things differently. Maybe C++ uses a method like mine, but it's automatically coded into C++ and all you need to do is the following:

Code:

---

Call StartThread(objMyObject)

---

I just don't know.

Woka

But the thread is running in a tight loop! Which means the
instruction pointer is lingering around there. Any other thread that
access it would require the instruction pointer to shift to where it's
needed now by the other thread. Then the loop would halt, albeit
temporarily.

Unless......the other thread jumps into this thread to run the
function it wants, like a thread running into another thread(very
unlikely), or a DoEvents is put in the loop.

Can you show me another multithreading example(that badger
one) which correct this problem? I just need something simple so
we can all see where and how it works.

Or you can point it to me in your existing examples.

Woka, the code you last posted would communicate fine if you put a DoEvents in each loop. Are you unwilling to do that because it's expensive, or some other reason?

You are correct. It would.

But the DoEvents also affects your app in many different ways.

VB Code:

Option Explicit
 
Private Sub Command1_Click()
Dim lngIndex As Long
    For lngIndex = 1 To 30000
        Me.Caption = CStr(lngIndex)
        DoEvents
    Next lngIndex
End Sub

Create a new EXE with a command button on Form1, and add the above code.
While the code is running try closing the app down, or clicking on the button again.
Yea, yea...I know you can code round this by doing:

VB Code:

Option Explicit
 
Private mblnCancel  As Boolean
 
Private Sub Command1_Click()
Dim lngIndex As Long
    For lngIndex = 1 To 30000
        Me.Caption = CStr(lngIndex)
        DoEvents
        If mblnCancel Then
            Exit For
        End If
    Next lngIndex
End Sub
 
Private Sub Form_Unload(Cancel As Integer)
    mblnCancel = True
End Sub

But this is just one tiny problem. What if a user clicks on a menu or something else, you then have to handle that.
I don't like DoEvents in a loop. It causes more problems than it's worth, and is considered a cheap hack.

This means you would have to add DoEvents in your main app too since what if your main app is doing something when the thread tries to contact it? You are now opening a HUGE can or worms :(

Admittedly I am using DoEvents in my file searching demo thread, but this will be replaced with a PeekMessage subroutine, that just allows the MultiThreading DLL window to process it's messages.

With my filesearching app, if It was done how you have mentioned, then when a file was found the thread would call the main app, which in turn would update it's main grid. The searching of files is halted at this point until the code execution is returned to the thread...right? Now if you have many file saerches running then this will dramatically affect the performance of your threads :(
Since my method uses the Postmessage function the code execution returns straight back to the file searching so it can continue searching, even though the main app hasn't processed the msg yet.

Does that make sense?

Woka

Yes, mostly, but

Quote:

---

This means you would have to add DoEvents in your main app too since what if your main app is doing something when the thread tries to contact it?

---

The main app should be responsive to user input anyway, so it will not likely be doing tasks that take a long time (that's what the worker thread(s) are for!).

Obviously the main app does do some things, and if the worker tries to contact the app while it's doing something, the worker will block, as you mention. I'd just point out that the blocking time should be minimal, for the above reason.

I agree about the file search example. Messages and memory access rather than blocking COM method calls is the way to go if you need to transfer data from thread to thread while maintaining performance.

I hate COM.

Oh, brilliant, PeekMessage.
So we could abandon wndproc?

Without COM, things will get unorganised and cannot be reused.
We've to write from scratch for every project that uses threading.

Errr...yes, and no. I would only PeekMessage while I was looping in a long loop since the Msg won't get pushed through until the loop is completed or I use DoEvents.
I did have a thought about using API WaitMessage, but that would hang the thread, which isn't good if yo want to click on a menu or something :(
I feel the WndProc is here to stay. What's the problem with using it anyways?
My code IS reusable. You wouldn't have to write multithreading code over and over again. You would just use the vbGateway2 DLL which I posted a few posts above. Is that the project you are looking at?
The vbGateway2 DLL is a threading go-between for your main app and an activeX EXE.

Luv and hugs.

WOka

Quote:

---

Without COM, things will get unorganised and cannot be reused.

---

COM is not necessary for code reuse, it merely helps. My complaint about COM is it makes things that should be simple, cryptic and over-complicated. VB6 is so closely tied to COM that you can't not use it anyway.