Category Archives: Uncategorized

Lego Mindstorms NXT-G moving from 1.0 to 2.0 – TriBot : Part 1

I discovered after installing Lego Mindstorms 2.0 NXT-G software that no one on the interwebs has captured this information before.

The Lego Mindstorms NXT 1.0 building instructions are found at Mindstorms Support 8527 -TriBot

So, without further ado, here is the Programming Guide for the Lego Mindstorms 1.0 TriBot : Part 1 – Driving Base

FUD all over again… This time with Testing!

Well, Jamie Cansdale has been getting heat over time from M$ over TestDriven.Net, formerly NUnitAddin.

M$ turned up the heat over the last week, and seemingly put it to HIGH yesterday.

Ian Ringrose simplified the discussion :

“Is it safe for me as a developer without a large legal department to work with Microsoft technology? “

FransBouma says : “Nail on the head.”

Yes… Nail on the head.

Happy Coding or Status Quo

… This presentation brought to you by Brains on Trains—The leading supplier of hosed-up thought processes.

Ok. Spent too big of a portion of last year FIGHTING with Micro$oft VS .NET 2003/2005 and trying desperately to show that my dying VB6 apps can be converted to them. Well, conversion doesn’t work, at least on my KLOC applications with major hacks embedded for unit testing and robust error handling.

Found the Rails in Feb 05 and basically “didn’t look back”. It took ‘till Nov 05 to get approval for the first app, and we were desperate. Success rate on that was HIGH as my off-the-cuff estimate “It’ll take 1 to 2 months” was right on target. Deployed critical-features version of app for public consumption at end of Nov. and then deployed final feature-rich (to the level that this rewrite needed) at end of Dec. Managers happy. Uesrs happy. Application admins (tech-support staff) happy. CODER HAPPY

I can’t say I”ve ever felt “Happy” coding in M$ anything. Always a catch, always a missing feature. Always a black box to deal with. Always some reason to spend 2 days googling and searching M$ forums for obscure answers.
Also, no support, unfriendly forum users, unhelpful forum “experts”.

I continue to hash around the balance between the pros and cons of this argument. It seems really clear on paper which is the better choice for continuing development… UNTIL the emotional ties to employer-loyalty, cost conciousness, time conciousness (both calendar time and timecard time) all get in the way. I have also voiced the concern to coworkers that with all the money M$ uses for VS development… how can it NOT be better??!!

In the final analysis, M$ CAN “not be better”. The 800lb Gorilla has lots of hair to shed and leaves a VERY large footprint.

With Ruby and Rails, my experience in learning curve was that the curve was low and short. Peaking the hill of learning these technologies was manageable, doable. Even without learning how to flex the technologies (I still don’t grok the metaclass), I have been able to overcome some serious design hurdles with the convenient flexibility of Ruby and the Rails framework.

Looking up, I notice ONE bolded phrase


The reference… Ruby and Rails.


I have an approved rails app to work on.

coder team alpha Out!

Black Belt TDD in VB6

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

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.

Test Driven in VB 6

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.



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.