||Asynchronous Execution - YES!!
I modified Event5_3.vbp, and set up the server side of the project as an ActiveX
EXE. If you run it inside the VB IDE, you should finally see the asynchronous processing.
The trick is to run the client and the server in two separate instances of Visual Basic.
You can also compile the ActiveX EXE for the server side, and force it to register by
double clicking on it. Then compile the EXE file for the client side. When you run the
client EXE outside of Visual Basic, it shows asynchronous processing!
||First load the project Event5_3_Srv.vbp into Visual Basic.
worry if you see an error message "Unable to set version compatible component ...
Event5_3_Srv.Exe." This is because the client project in the ZIP file has a reference
to the GUID for the Event5_3_Srv.Exe file from my PC.
When you run this project, you'll see a dialog box about the project properties. Simply
click on OK. You can't actually see anything happen yet.
||Load a second instance of Visual Basic. Load the client
project Event5_3_Cli.vbp into Visual Basic.
Don't worry if you see an error message
"Could not create reference ... Event5_3_Srv.vbp." This is because the client
project in the ZIP file has a reference to the GUID for the Event5_3_Srv.Exe file from my
When you try to run the program, you may see an error message "Compile error: User
defined type is not defined". This is because you need to set a reference to the
currently executing server project.
From the VB menu, choose Project / References. Scroll down to select the
Event5_3_Srv.Vbp that you just created by running it in the other instance of VB.
|Run inside the VB IDE
||Go ahead and run the program, but don't Click on
the GO button yet. One final important step before you actually run the program: MINIMIZE
both instances of Visual Basic. If you don't do this, the message box from the server side
may not be visible, since it is hidden behind the client project's instance of VB.
hope that you'll see that the asynchronous processing really works. For some reason, when
I tried this originally, it did not work for me. I have also had the program fail with
automation errors at the very beginning. Usually this is fixed by deleteing the server
reference (un-checking the box from Project / References) and then restoring it.
|Run compiled client programs
||If you follow steps similar to what was shown
for the Event5_2 projects, you can compile both the client and server projects as EXE
files. They ran identically to what I saw using two instances of Visual Basic.
||After all that, the concept of multithreading
awaits you. There is some great reading in Visual Basic Books Online that came with VB
5.0, located as follows:
|Component Tools Guide|
|Creating ActiveX Components|
|Building Code Components|
|Scalability and Multithreading|
Everything in there is valuable information. For example, I found these
"The big drawback to the
thread-per-object model is that you have no control over the number of objects (and hence
threads) that clients create. Creating too many threads will bog the operating system down
in thread-maintenance overhead.
Too many active threads that is, threads that are actively executing code
will bog the operating system down even more quickly. Generally speaking, you want
about the same number of active threads as you have processors, to guarantee that
theres never an idle processor. When you have just one processor, thats not
very many active threads."
Sounds like we all need to buy 64 way servers to really get the most use