Code

Unit testing Excel VBA – xlUnit demo

Back in February I did a podcast with Mike Woodhouse, based around testing VBA code. Mike has written a unit testing frame work for VBA code, called xlUnit. Over the last few weeks I’ve been using xlUnit to help write a generic validation class for VBA, so I thought I would put together a little video of how the addin can be used to write tests for your code.

Its in 2 parts because you can only upload videos that are 10 minutes long to you tube.  The first part is the basics and in the second part I show some examples from my project.

You can find out more about xlUnit at Mikes blog, grumpy old programer:

Old dates, New VBA

Here’s something i did not know about VBA!

http://www.puremis.net/excel/cgi-bin/yabb/YaBB.pl?num=1166424720/0#8

Cool, now i just have to get a job at the Natural History Museum.

List Box Resizing problems

Ran in to an old friend today, and it took me a while to remember what to do. After adding a list box to your user form, you’ll want to resize it so that it looks nice. At design time you can get all your controls lined up without too much effort. Like this:

DesignTime.JPG

However when the form is run, the list box automatically resizes itself! Like this!

RunTime.JPG

The answer is to change the a default setting, the “IntegralHeight”, and problem solved. The difference is that now your list box will show parts of lines that don’t fill the list box exactly, rather than resizing to accommodate only whole lines.

fixed.JPG

A better way with a Make Table Query?

The situation.  

Back end Access DB, front ended with an Excel Form. Add a new record to a table in the DB and run a Make Table Query to sort the whole table in to alphabetical order. Reload the table into a list box.

I need to make a new table because simply sorting the existing table does not results in a alphabetica import into the list box.

The problem is that when I run the SQL for the update query, if the table name is the same as a table already in the DB then DAO errors. In Access you have to click a message box to allow the deletion of the old table.

From VBA I can use DAO with  “TableDefs.Delete” to remove the old table then the solution works fine.  But I don’t really like this idea, it is clunky and I don’t like deleting table danger!

So what’s a better way?
The workhorse code looks like this:

[vba]Sub SendNewProject(sPro As String, sDes As String)

    Dim i As Integer
    Dim db As Database, rs As Recordset, r As Long
    Dim sSql As String

    Set db = OpenDatabase(gsDataBase)
    Set rs = db.OpenRecordset(“tblProject”, dbOpenTable)

    With rs
        .AddNew
        .Fields(“Project”) = sPro
        .Fields(“Description”) = sDes
        .Update
    End With

    ”’close table we will delete shortly
    rs.Close
    Set rs = Nothing

    ”’run updatequery to update project list
    sSql = ” SELECT tblProject.Project INTO tblProjectS” _
           & ” FROM tblProject” _
           & ” ORDER BY tblProject.Project;”

    ”’delete old projectsS table
    db.TableDefs.Delete “tblProjectS”
    ”’run make new table
    db.Execute sSql

    ”’close DB
    db.Close
    Set db = Nothing

    MsgBox “Project has been added to the projects list” _
           & vbNewLine _
           & vbNewLine _
           , vbOKOnly, gcsMsgboxhead

End Sub [/vba]

Securing VBA code in Office

Most of us know that .dll’s are the only real option if security is a genuine issue, but I think the following might be a possible (bodge) solutions for those who many not have VB, and need better security for their VBA code. Anyway, I was looking at this site:

Tech Net – Office 2000/Visual Basic Programmer’s Guide

Chapter 17 deals with security. My lighting fast brain crawled in to action and I thought I’d try something.

Now according to this info:

In Access, you can save an .mdb or .adp file as a file type that contains only compiled VBA code without the source code.

These files are called .mde file and most of us will have worked with these before, or at least heard of them. I didn’t know the code was compiled though. Doing a little bit of goggling it seems that decompiling is available, but that the VBA code remains compiled, i.e. forms and report are easy to decompile, but the VBA remains compiled good news.

See where we are heading? You can call this .mde code from you Excel/Word etc VBA, and your more sensitive VBA code can be kept in a complied- harder to get at – .mde file. In theory it’s a bit like putting your code in a proper .dll it’s compiled code. Which kinda begs the question, why can you do this with all our VBA?

Here is an example I’ve put it into a UDF, and it runs in such a way as to be dog slow, but it could be implemented better, or if the situations was different the performance hit would be less noticeable I’m sure you’ll get the idea. I’ve inculed the orginal mdb, and you can do all the other passwording etc to this mde before making it a mde. I’ve also chnaged the file extention to change the icon, whcih is of little importance.

So, it’s Heath Robison, it’s far from ideal but it might be useful to someone; oneday! A nice little idea I though”¦Â