Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

Ahh, testing again in VB6. Learning all about the black art of WinAPI programming and control of mouse events.

Here’s what I’ve learned that can be passed on to you, Grasshopper.

• Test a Pop-Up menu… seek your history, Grasshopper, and learn that PopupMenu is a BLOCKING function. Therefore, a out-of-thread timer is required to handle the call. Oh, and when you get ready to SendKeys to the menu… Make NO OTHER CALLS before sending the keys, and send them all at once. The container form of the popup menu will readily take back keyboard focus and you’ll lose your menu control otherwise.
• Testing a TreeView with Mouse Events. Getting the windows handle of the selected TreeView node requires you to go down the rabbit hole of WinAPI. SendMessage with TVM_GETNEXTITEM, TVGN_CARET and TVM_GETNEXTITEM, TVGN_ROOT will be very beneficial.
• A nice dll out-of-thread timer can be found at http://www.vbaccelerator.com/home/VB/Code/Libraries/HiResTimer/article.asp

Oh, how this is fun!

Why no code? Because as a student of the black art the education is in your research, and the joy is in watching your code do what you wanted after long long efforts.

OK. Due to severe scheduling restraints (IE I’m 1 month late on this project), I am forced to run test-driven in VB 6.

With the help of vbUnit3 Framework and vbUnit-Free Add-In, the unit testing bit is setup.

VBMock provides a framework for mocking objects in vb 6. This works well. There are two notes here for VBMocking.

1.) Remember that VB 6 does NOT provide true OOP inheritance… IE “Implements” requires you to “overwrite” the super’s routines. This might be as simple as call-forwarding the super’s call, but it must be manually handled. This provides the “out” for Mocking… the mock object can reference directly the target Class.. no Interface is required. Then the MockingClass can properly mock-override the target Class routines.

2.) EXE/DLL arrangement and Modal Forms. Well, here’s the black-belt approach to VB programming. You will probably want to implement a splash-form. This form must exist on the EXE Project. ControlBox off and no Caption gives you a “windowless” splass screen. It will appear in the task tray UNTIL it is minimized. This gives you the opportunity to hand off control to the main form residing in the DLL. UNLESS you are using MDI. MDI cannot exist inside a DLL, so your EXE will contain the MDI. In this case, if you wish to employ a splash or not is up to customer requirements. In the case of no-MDI, the main form referenced from the EXE to the DLL must have an additional routine Init() to allow you to pass the reference of the splash form into the Main form…. this will prevent the Sub Main() from following the code path after the Form.Show() of your splash and then shutting down the application. Your main form must catch Form_Unload can call Unload fSplash_ in order to allow the entire application to properly exit when the main form is closed.

Whew!

Mocking:

Well, mocking the average form is A-OK, but we don’t have the advantages of .NET Reflection here, so there is no “catching” a call to a modal form or internally handling events when the form is displayed.

The approach :

Create class “ModalForms” (I Resist the name “Dialogs” because sometimes a Modal is not necessarily a dialog but more like a dictatorial command).

Class ModalForms

Public Sub MessageBox() : Wrapper the standard MsgBox call. WHY? You need a way to Mock message boxes to the main application in order to test main-form logic. SOOO, wrappering the MsgBox allows you to send mock responses back to your main-form for TDD logic paths.

Public Sub : Same theory as above.

Oh, and another thing… you’ll notice that you need one more public class “NormalForms” that provides getters to the non-modal form objects. This is because forms are private to the project and must be manually exposed on the DLL interface so that your EXE can get them.

More Later.