Saw this from the 37s guys :

When programming: Start in the Middle – “Forget about the icing, bake the cake.”

I just opened my “birthday present” to myself… a MobiBLU

It’s so cool!

And INCREDIBLY TINY!! 24mm ^ 3

Ok. Well now to a movie and off to bed…
it has to charge for 3 hours before doing anything interesting with it (like um.. playing the music.)

I’m trying to configure a production-mode Win2003 server for rails apps.

I ran down the rabbit hole for all of the following configurations :

• Cygwin/lighttpd SCGI/FastCGI: compiling errors on both my dev machine and vmware test.
• InstantRails / SCGI : well, after figuring out how to run production-mode scgi_server as a windows service (details below), I still have trouble getting InstantRails to run as a “service” itself. This is not the fault of InstantRails, and Curt, you get KUDOS KUDOS KUDOS for the work in gettting InstantRails to work at all! (see below for some details on how to auotmate the scgi-as-a-service installation, when you get InstantRails running as a service itself (or at least the apache/mysql servers).
• IIS / FastCGI : 404 error every time. With no log output, there’s nothign to see and nothing to do.. except look elsewhere for a solution!

Here’s the final solution :

Apache SCGI Configuration

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.

Hello Hello Hello,

It’s been a long time. I’ve had my head buried under several layers of black, gooey, .NET C# UI routines.

Testing UI is NOT a picnic.

I’ve found problems in two categories thus far :

1. Old VB6 tactics result in cross-updating/cross-merging of datasets. Basically MAJOR data collisions. The most common instances of this are a pair of cascading comboboxes where combobox-child has list-data one minute… and no list data the next! The hardest debugging is watching the Step-into pass over a line of code and the dataset has changed… what happened to my internals?!

2. Mocking for UI is scarily complicated. Again here is a bunch of dataset collsions, but also the need to mock the results of data processes (especially updates) for the purpose of the UI. I will note here that coding ADO.NET one-row inserts and updates with specified primary-key values is still 1000% easier than ADO!

OK, If anyone is reading my blather, feel free to comment, suggest.

I especially want to hear of your own experiences or links to other Test-Driven UI 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.