This project demonstrates that a single VB6 program can be used on several PCs on the same LAN without a separate server program or database in common. This sort of thing is much easier to write and the product is less confusing to maintain if done as two separate client and server programs though.
Pure TCP is used and a UDP discovery technique is implemented so the PCs do not need to be members of the same Workgroup or Domain, no name service is required, and yet no IP addresses need to be entered either.
Preparation
Multiple PCs on a LAN together will need the compiled program installed. You could create a formal installer - the P&D Wizard is good enough. Or an XCopy deployment package could be created using Reg-Free COM tools like the popular MMM ("Make My Manifest") though this requires experience most VB6 programmers don't have.
Nothing stops you from testing by running two copies of Quizzer.exe on your development PC for testing though.
Both MSHFLXGD.OCX and MSWINSCK.OCX (in addition to ADO 2.5, already in Windows) are used by this demo program.
Operation
Some user must play "proctor" and administer the quiz. This person puts his Quizzer.exe into "proctor mode" which opens an extra Form, and from there chooses a quiz file for the quiz to run. After that the proctor starts the quiz and fires each question and then "calls time" when all submitted answers get scored. The proctor can also end the quiz early.
The proctor can also take the quiz himself or just act as an observer/administrator.
Other users won't get the second admin Form, and once someone has taken on the proctor role the "Become Proctor" button will disappear from their quiz Form.
All participants (including the proctor if he chooses to be a participant) must register with a unique name when they first run Quizzer.exe, which they are prompted for. User can leave out this name and just choose to be an observer as well.
Once the proctor has taken charge and picked a quiz he can wait for participants to register. Then he can start the quiz, and begin sending questions. The proctor sends each question, waits the allotted time, and then "calls time" on the question. This scores the submitted answers and reports back to everyone's scoreboard.
Participants wait for questions which are presented along with a multiple-choice list of answers. The pick an answer and click Submit to send their answer to the proctor. Once the proctor calls time, score updates are reported back and the correct answer is pointed out to all particpants and observers.
Once the quiz is finished everyone is left with the scores and rankings to look at until they close Quizzer. The proctor can also optionally save the scores to a CSV file before quitting Quizzer.
![Name: sshot.png
Views: 32
Size: 35.7 KB]()
Here "Mr. Bill" is acting as proctor. He has just clicked the "Call Time" button,
which has become the "Next Question" button.
Just A Demo
Quizzer isn't perfect.
There are many features that might be added. There may be some features that are not needed that could be ripped out.
The question file format is a bit rough (see the comments in Globals.InitProctor). This discovery protocol's UDP port is hard-coded (see Globals.PROCTOR_UDP_PORT). And so on and so on...
And of course there may still be any number of bugs in it yet, as well as plenty of imperfect exception handling. Not everything has been thoroughly tested.
How Quizzer Works
Without going into detail (though I'll admit the code itself can be rough to follow)...
There are two Forms, one called MainForm and the other ProctorForm.
MainForm is basically a user interface for displaying the scoreboard, displaying questions, and accepting answers.
ProctorForm is a sort of "reverse TCP server." It tracks everything, runs the quiz, maintains the "database" in memory using a pair of ADO Recordsets, and manages TCP connections to all of the MainForm instances on the LAN.
ADO Stream objects are heavily used for serializing and deserializing messages sent both ways over the TCP connections.
Discovery is accomplished by having each MainForm send UDP broadcasts out to the LAN containing the registration name of the user, his IP address, and the TCP port he is listening on. Once there is a ProctorForm running and it sees such a broadcast database entries are made and then ProctorForm connects back to the remote MainForm. When MainForm gets the connection established it stops broadcasting its announcements and is ready for the quiz to begin.
Large amounts of code and data used by both Forms is kept in Globals.bas in an attempt to make the code in the two Forms a little less cluttered.
There are also two other Forms: RegisterDlg and ProctorDlg. These are used as simple dialogs for getting information before carrying on with the business of the bigger Forms.
Pure TCP is used and a UDP discovery technique is implemented so the PCs do not need to be members of the same Workgroup or Domain, no name service is required, and yet no IP addresses need to be entered either.
Preparation
Multiple PCs on a LAN together will need the compiled program installed. You could create a formal installer - the P&D Wizard is good enough. Or an XCopy deployment package could be created using Reg-Free COM tools like the popular MMM ("Make My Manifest") though this requires experience most VB6 programmers don't have.
Nothing stops you from testing by running two copies of Quizzer.exe on your development PC for testing though.
Both MSHFLXGD.OCX and MSWINSCK.OCX (in addition to ADO 2.5, already in Windows) are used by this demo program.
Operation
Some user must play "proctor" and administer the quiz. This person puts his Quizzer.exe into "proctor mode" which opens an extra Form, and from there chooses a quiz file for the quiz to run. After that the proctor starts the quiz and fires each question and then "calls time" when all submitted answers get scored. The proctor can also end the quiz early.
The proctor can also take the quiz himself or just act as an observer/administrator.
Other users won't get the second admin Form, and once someone has taken on the proctor role the "Become Proctor" button will disappear from their quiz Form.
All participants (including the proctor if he chooses to be a participant) must register with a unique name when they first run Quizzer.exe, which they are prompted for. User can leave out this name and just choose to be an observer as well.
Once the proctor has taken charge and picked a quiz he can wait for participants to register. Then he can start the quiz, and begin sending questions. The proctor sends each question, waits the allotted time, and then "calls time" on the question. This scores the submitted answers and reports back to everyone's scoreboard.
Participants wait for questions which are presented along with a multiple-choice list of answers. The pick an answer and click Submit to send their answer to the proctor. Once the proctor calls time, score updates are reported back and the correct answer is pointed out to all particpants and observers.
Once the quiz is finished everyone is left with the scores and rankings to look at until they close Quizzer. The proctor can also optionally save the scores to a CSV file before quitting Quizzer.
Here "Mr. Bill" is acting as proctor. He has just clicked the "Call Time" button,
which has become the "Next Question" button.
Just A Demo
Quizzer isn't perfect.
There are many features that might be added. There may be some features that are not needed that could be ripped out.
The question file format is a bit rough (see the comments in Globals.InitProctor). This discovery protocol's UDP port is hard-coded (see Globals.PROCTOR_UDP_PORT). And so on and so on...
And of course there may still be any number of bugs in it yet, as well as plenty of imperfect exception handling. Not everything has been thoroughly tested.
How Quizzer Works
Without going into detail (though I'll admit the code itself can be rough to follow)...
There are two Forms, one called MainForm and the other ProctorForm.
MainForm is basically a user interface for displaying the scoreboard, displaying questions, and accepting answers.
ProctorForm is a sort of "reverse TCP server." It tracks everything, runs the quiz, maintains the "database" in memory using a pair of ADO Recordsets, and manages TCP connections to all of the MainForm instances on the LAN.
ADO Stream objects are heavily used for serializing and deserializing messages sent both ways over the TCP connections.
Discovery is accomplished by having each MainForm send UDP broadcasts out to the LAN containing the registration name of the user, his IP address, and the TCP port he is listening on. Once there is a ProctorForm running and it sees such a broadcast database entries are made and then ProctorForm connects back to the remote MainForm. When MainForm gets the connection established it stops broadcasting its announcements and is ready for the quiz to begin.
Large amounts of code and data used by both Forms is kept in Globals.bas in an attempt to make the code in the two Forms a little less cluttered.
There are also two other Forms: RegisterDlg and ProctorDlg. These are used as simple dialogs for getting information before carrying on with the business of the bigger Forms.