Stack Overflow

If you’re a programmer, you know the problem of solution googlability. It’s particularly prominent in mainstream languages (and one of the things I decried in my What’s Wrong with VBA series, as VBA is particularly bad in that respect); you have a problem, you google for it, unless you’re coding in a good awesome well-designed freak language like Ruby, Python, or Haskell, all you get back is trash and spam.

So, since you’re reading blogs and a programmer (or you’d have stopped reading by now, I guess), you know Joel on Software. Now this guy and his team have done something: They took the Wiki approach of “everybody can edit”, added Digg’s “let’s vote stuff up”, and made the whole thing a generic programming Q&A site.

Behold, and witness, the rise of Stack Overflow.

From his launch post:

Here’s how it’s supposed to work. This is a community project, so I’m being careful to avoid saying this is how it will work… that’s up to the community. But this is roughly what I have in mind.

Every question in Stack Overflow is like the Wikipedia article for some extremely narrow, specific programming question. How do I enlarge a fizzbar without overwriting the user’s snibbit? [...]

Some people propose answers. Others vote on those answers. If you see the right answer, vote it up. If an answer is obviously wrong (or inferior in some way), you vote it down. Very quickly, the best answers bubble to the top. The person who asked the question in the first place also has the ability to designate one answer as the “accepted” answer, but this isn’t required. The accepted answer floats above all the other answers.

Sounds great! It has tags, it’s not restricted to one programming language, it could provide the framework for thousands of programmers collaborating. And the best thing: They plan to “keep it ad-free and open to the public forever”.

You’ll need an OpenID to log in – I got one at myOpenID myself. Too bad it’s not possible to log in without, but whatever – I guess this approach has more promise than the closed one that Microsoft tried to force upon us with that whole Live ID crap, but still shares the same weaknesses (which are, mainly, another party involved and a central point of failure).

Nevertheless, I do think this could be awesome. Let’s see where it goes.

This is the third part of a three-part series, have a look at part 1 and part 2 first.

So let’s go on ahead and jump into the final bits of my troubles with MS Access and VBA as environment for medium and larger IT projects – basically, anything having 2 and up users.

Syntax

There are quite a few things that bother me about the VBA syntax. First of all: it’s inconsistent, even more so than the one of php (where mainly method signatures are inconsistent), in several places. The most prominent of them are functions. Take these lines:

Dim answer As VbMsgBoxResult
MsgBox "Hello World!", vbOKOnly
answer = MsgBox("Hello World?", vbYesNo)

Did you notice anything? Yes, indeed. Take note, the parentheses are forbidden in the first case, and mandatory in the second. Now assume that you have a function call that you suddenly need the answer from, whereas you didn’t need it earlier. Not only do you now have to write the assignment, but you also have to add parentheses to the function call. Way to spend productive time.

The same goes for “Set” and assignments to native data types and Objects: For Objects, it’s mandatory, for native types it’s forbidden. That goes even for Objects stored in a Variant variable – all Variants are not made equal, some will throw runtime errors when you assign stuff to them.

Another annoying syntax bit is this one:

' Won't work!
Dim someNumber As Integer = 5
' Will work :-/
Dim someNumber As Integer
someNumber = 5

Yay, more lines of code, how great. But wait, I have more! What do you think this produces?

Dim firstVar, secondVar As Double
Dim thirdVar, fourthVar As Object

Yep, you guessed it. “firstVar” is a Variant, “secondVar” a Double, “thirdVar” a Variant, “fourthVar” an Object. Oh, you got it wrong? Don’t worry, it’s just that silly.

My final pet peeve with the syntax is its capitalization (and thus technically the IDE and not VBA itself). VBA is not per se case sensitive – and it expresses that through simple means: Whenever it encounters a variable, it tries to capitalize it the way it’s supposed to be, to make it clear that it’s the same.

Now, enter scoping, and intuitively named API bits. So you have a local variable called “currentItem” … what happens if you try to access the property “CurrentItem” in, say, an Inspector Object? Right, it’s capitalized “currentItem”. It has nothing at all to do with my local variable, but the IDE is too stupid to notice.

Of course there’s other things amiss or strange, like the lack of a side effect free ternary operator, or the (nearly syntax) VBA developer gospel for the redundant Hungarian notation taken to wrong extremes, but I’ll just stop here.

MS Access

I won’t even go into how I find Access 2007 to be much worse than its predecessors when it comes to usability, with longer mouse paths and more clicks per action, the developer tab not showing by default, and shortcuts no longer easily visible. Just so much: it’s annoying. I guess I still haven’t gotten used to the new, less quick, way of displaying shortcuts, and often, object placements aren’t intuitive for me and I’m looking for things in the wrong tab.

What really bothers though is that Access has stability issues. Access is the only program so far that managed to crash on my development system. Dreamweaver MX 04 is quite an old make and has huge problems with Vista’s UAC, but it doesn’t crash. Nor does any other tool. But Access, which happens to often corrupt databases when it does.

Even crashes aside, occasionally the database just corrupts like that, without any visible reason. Or it keeps code that you deleted, and keeps spitting error messages how that code isn’t valid – without you having any possibility to do anything about it, not even overwriting helps.

I hope you make backups every couple minutes, I certainly learned to. I haven’t found another reliable way to get those databases back into stable conditions.

Then, what’s one of the many responsibilities of a proper DBMS? Housekeeping! What does Access do? Provide you with “compact and repair”, which is user-initiated only. Well, I guess with huge databases that Access couldn’t handle anymore anyway, that would make sense, not having that an automated regular task.

Furthermore, every single user needs MS Access installed on his computer. Potentially a security risk, certainly not something that should be necessary. You don’t go and install an MS SQL Server on everybody’s machine. At least Microsoft consequently follows through, and their Access security FAQ is all about how you can protect your computer from malicious Access macros, and not how you can secure your Access databases.

By the way, Access doesn’t scale – what else is new. Multiple users are a problem, for larger databases (>2GB, but you’re hitting performance bottlenecks way before that) you have to move to a proper backend – essentially, lugging around the whole DBMS part of your GUI windowing toolkit for naught afterwards.

It does at least have proper locking, quite refined permissions, and with Access 2007, database encryption (without which all the permission structures in the world are worth naught) as well.

Other Things

There’s a few other small things that I found incredibly annoying, coming from other languages like Java, Python and my personal favourite, Ruby.

For one, Null comparisons work in odd ways, VBA uses ternary logic (although admittedly, this is consistent with the way SQL handles Nulls).

The next minor thing are silly defaults – there are two lines every halfway serious programmer adds as a very first thing to every single bit of VBA code they write (and this goes so far that there’s option settings to add it automatically to every source bit):

Option Explicit
Option Compare Database

The reason for this is simple: backwards compatibility. While VB6 (maybe earlier?) changed the default to the need for explicit variable declaration, VBA never did, and thus it’s still possible to mistype a simple variable and never find the error later on. And as for Compare Database … yeah sure, let’s compare stuff everywhere a bit differently, to make sure the database behaves completely unforeseeable.

Another one: No external source file support. If you want to use any library or other cool thingy you found on the net or elsewhere, you have to copy-paste the code into Access. Where it’s needed, that is, which of course means that if it’s needed anywhere else, you have to copy-paste it again. The only way around this are Access databases that allow you to copy-paste (oh, look, a pattern) the respective classes or modules as a whole. No, you can’t just link (with very limited exceptions). Hooray?

We’re not done yet: You can’t return an array! If you want a Function that returns an array, you have to define it as returning a Variant. If you do that, you can return arrays (since they’re a subtype of Variant), but will lose all meta information: Data type, size, everything. So if you want to return an array and its size, you have to do it via separate functions, or with a stateful returning object, or with a custom ADT.

Something that was rightfully pointed out to me (thanks Ste!) – why is it that VBA (and VB.NET, for that matter) distinguishes between Functions and Subs? There’s no fundamental difference, one returns something, the other doesn’t (so, essentially returns Nothing), but that’s it. Visual Studio goes so far to automatically change the keyword from Sub to Function when you return something.

Conclusion

I guess it’s apparent by now: I do think that it’s justifiable to say that VBA is outdated and should be dumped right now.

For Microsoft: There are good replacements, there’s no reasonable reason beyond “it was easier” to have Office 2007 use VBA still, and there’s certainly no reason to make the next version of MS Office still have VBA support – particularly if that means that there still won’t be native VB.NET support inside MS Office.

How delusional of me to think they’ll actually see this, though

For anybody considering Access and VBA for their projects: Well, if you still want to, you can of course. Or get the free Visual Studio Express for VB.NET plus SQL Server Express, and stick to a Microsoft environment with a very similar but much more mature language, and a more performant database, for less money.

I still do work with VBA, when I really have to, but I think I laid out here why it’s a fact that I really only do so when there is no other way.

part 1 – part 2 – part 3

This is the second part of a three-part series, have a look at part 1 first if you haven’t read it yet.

Let’s just jump right in and continue the list of problems I have with VBA as a programming language for medium and larger MS Access projects.

Error Handling

The modern paradigm for error handling is exception handling, but to VBA that doesn’t apply for a simple reason: VBA doesn’t have exceptions. Instead, it has this:

On Error GoTo ErrorHandler

Yes, that’s a GoTo, and we all know those are evil. Even worse than GoTo though is this line:

On Error Resume Next

Basically, “just ignore all the errors that happen now, they’re not important”. Ah, right. We can still check for error codes, so even this evil construct (never ever use this as default!) is occasionally necessary to avoid the spaghetti code that the GoTo alternative would produce, while providing reasonable feedback instead of the techy default Access warnings:

1
2
3
4
5
6
7
8

DoCmd.SetWarnings False
On Error Resume Next
doSomethingUseful
If Not Err.Number = 0 Then
    MsgBox "Descriptive error message", vbCritical, "Error"
End If
On Error GoTo 0
DoCmd.SetWarnings True

What a silly contraption. In VB.NET, it’d look like this, and be way more flexible and expandable:

1
2
3
4
5

Try
    doSomethingUseful()
Catch ex As Exception
    MsgBox("Descriptive error message", MsgBoxStyle.Critical, "Error")
End Try

The current consensus among programmers is that GoTo isn’t necessarily evil, but it has to be used the right way. Myself, I have yet to see a case where I find GoTo to be better than its alternatives, but that’s subjective I guess. Excursus: I couldn’t resist solving the Last Example – Nontrivial Gotos from that last link, with less C code and no GoTo and, in my opinion, clearer:

1
2
3
4
5
6
7
8
9

int parse()
{
    while (Token tok = gettoken() != END) {
        while (!shift(tok)) {
            if (!reduce(tok)) {
                return ERROR;
    }}}
    return ACCEPT;
}

Anyway. VBA provides a GoTo, which is neutral, and it forces that GoTo upon programmers for error handling due to lack of alternatives, which is bad. Only C gets away with that.

The IDE

The Access VBA IDE basically consists of two parts (and thus technically isn’t really integrated, but we’ll let that slide): The in-Access editor (or layouter) for forms and reports, and the code editor for actual programming.

The layouter works quite well really, except that the one even in the free Visual Studio Express (which isn’t even the central part of that IDE, unlike in Access) is lightyears ahead, be it concerning auto-snaps or ease of use or number of clicks for anything. Microsoft doesn’t seem to use its internal synergies all that well.

The same then goes for the code editor, just worse: It hasn’t gotten an update in recent years, the one that shipped in Office 2007 is exactly the same as the one from Office 2003. Grievances are…

• Whenever you have a half-finished line, and switch line to write something somewhere else, you have an error message box pop up that you have to click away first – because it only checks errors when you leave a line, and has no other way to display them.
• Class lookup is shaky, with new custom classes it often it only works after you exit and restart Access.
• Even if it works it’s not completely reliable, working autocompletion is a rare positive surprise.
• Debugging is pretty limited, often when there’s an error the IDE doesn’t even stop at the point where the error actually occurred but at some point further up the call stack.

I can live with those shortcomings of course, but I really don’t see why Microsoft didn’t just use the Visual Studio IDE instead – it would not only have fixed those problems, but also have gained better searching capabilities, snippets, refactoring and wizards to go with it.

Object Orientation

VBA is object oriented! Yeah, to some extent: You can make classes, and there’s even properties. However, yet again there’s a bullet list of things that should be better:

• You can’t have parameters for your class constructors (the Class_Initialize Sub), so initializing a class must be either with default values or through a separate “init” function that’s called after instantiation with “New”.
• No real inheritance, you can just implement interfaces (and thus inherit method signatures, but no content or properties or anything) – considering there’s no compile time type checking anyway, I don’t see much purpose in that.
• No overloading. Yes, you can have optional parameters, but the same function name with different signatures won’t work (the language does support encapsulation though, so you can override functions in narrower namespaces, but that’s not really overloading).
• Objects are handled different from native data types. Not just “they are different”, but they have differing syntax too – an assignment to an object needs “Set”, one to a Variant must not have “Set”. So even though you can store an Object in a Variant, you’ll run into runtime errors if you do. Admittedly, Java shares similar problems, but at least it has autoboxing meanwhile.

Some people also have a problem with VBA having both modules and classes – myself, I see that more pragmatically: There are cases when you’d make just static functions in a class anyway, or work just with a singleton, so why not pack those in a module instead? You can always change to a class structure later if it becomes necessary.

The Community

Now this one is certainly controversial, and even more subjective than the rest of this post series. First off, there are quite a few great community sites full of dedicated and knowledgable authors, like the MS VB forums, databasedev.co.uk, VB Helper, The Access Web, FreeVBCode, the TekTips VBA section and the FMS tips section.

But what I’m talking about is the “Googlability” of problems.

If I don’t find a solution in a site I know (or sometimes while looking in one of those sites, with “site:foobar.com”), I just Google it (of course) – problems do occur, and others must have had the same ones before. Now what happens if I do that for VBA problems?

I find trash.

This is for these three reasons, I guess:

• There isn’t so much a VBA community as 4 VBA communities: ASP VBA, Excel VBA, Word VBA, and finally also Access VBA (about in that order of prominence) – and then there’s the VB6 and VB.NET community too, with solutions that often don’t apply to VBA.
  So the search queries have to get more and more elaborate, adding “-asp” and “-excel” is common if you want to find anything – thus it takes longer until you find your solutions.
• There are plenty of solution providers that might provide reasonable solutions, but cost money. Now, that’s a problem of mine I guess, but I don’t like giving my credit card info to some obscure website for a solution that might or might not work for me. Luckily, CustomizeGoogle filters those out quite reliably, after I tell it to.
• There are plenty of inexperienced users when it comes to VBA, way more so than with most other programming languages and other technologies I used so far (well, Python and Ruby tend to have geeky target audiences anyway, but the same applies to Java). This means two things:
  • Often, questions are answered less than optimal by only slightly more knowledgable users than the ones asking the question, meaning the solution is either just wrong or not generic and thus doesn’t work in a slightly altered context.
  • Even more often, questions aren’t answered at all. The favourites here are the people later writing “nevermind, I found the solution”, without providing what that solution was that I could use now as well…

Keep in mind that I don’t have any problems with inexperienced users whatsoever, I’m regularly a newbie in yet another programming language I’m learning myself. And asking questions is a good thing anyway – it’s just that it seems like more experienced VBA programmers move on to VB.NET or something and thus VBA queries often disappear in the void, because there’s nobody experienced around to answer them.

That’s all for now, stay tuned for part 3 with syntax, MS Access, other things and a conclusion.

part 1 – part 2 – part 3

Visual Basic for Applications – the legacy language that Microsoft apparently still won’t drop even in future Office updates, although they’re working on it, and certainly hasn’t dropped in Office 2007. The plague with a lobby. Why is it so bad, is it so bad at all?

This very subject here was, in fact, one of the things that made me think “I have to get a blog again” over those years when I didn’t have one – I so wanted to write it whenever I was forced to work with applications coded inside MS Access, or when I coded them myself from scratch. I decided to make what started as a single post into a three part series, simply because there was so much content that one blog post couldn’t hold it all.

I won’t go into VBA for the rest of the Office suite too much, for tiny macro things it might even fit, what I’m talking about is medium (and larger) applications. And I will use the term “database” for the course of this article series for something it technically doesn’t strictly apply to, which is a MS Access application and actually an entire DBMS, plus GUI stuff and application logic, all mashed together.

So, what are all those things that bug me so much?

Language Updates

That’s possibly the biggest gripe of them all. Quoting the very Microsoft VBA site, at least MS makes their stance towards VBA perfectly clear:

[...] As previously announced, Microsoft does not expect to make significant enhancements to VBA. [...]

As of July 1, 2007, Microsoft will no longer offer VBA distribution licenses to new customers. Existing VBA customers can still purchase additional VBA licenses from Summit Software and Microsoft for existing solutions.

In other words, “we’re desparately trying to get rid of this mess”. Well, why wouldn’t they: VBA wasn’t updated for nearly 10 years now – while programming languages evolved around it, some very well-designed behemoths (for the time they were designed at) like C++ still stand their ground, many others have vanished and were replaced.

Yes, of course there’s always a demand for coders for older languages, just look at COBOL. If you like VBA, there’s plenty of legacy Access applications, and places where Access makes sense, so you won’t be out of a job any time soon.

That doesn’t change that the language would be in desparate need of an update, wouldn’t the update already exist in the form of VB.NET and, to a lesser extent, in C#. Why Microsoft hasn’t at least added support for those inside MS Access in the course of introducing .NET is beyond me.

The API

What clearly does belong to the VBA API, particularly in our context of developing MS Access applications, is the windowing framework. While it has its very own problems that I’ll describe in the IDE chapter, it does what it’s supposed to do rather well: Forms, reports and components, with a nice drag-and-drop interface for tinkering interfaces. It doesn’t have the best performance out there, but for database applications that work, who makes that their top priority.

Beyond those widgets and happy drag-and-drop things, for the most part, the Application Programmer Interface of VBA can be described with a few simple words: It doesn’t exist. While VBA does make use of DAO and ADO (not the way better ADO.NET, mind you), and the Office object model (which is actually more comfortable to use in VBA than in C#), everything that goes beyond that is out of bounds.

Let me illustrate by means of a symptomatic example.

Let’s assume you want a dynamically sized array, a Vector or ArrayList, that grows and shrinks as you add and remove items, preferrably useable as a stack or queue too by means of simple procedures. Now, in every other language that’s as simple as importing a bit of the API and then using said dynamic array. Not so in VBA, that bit of the API doesn’t exist (except if you count the Collection that has whooping 4 methods). There are “dynamically sized arrays” through lines like this one:

ReDim Preserve myArray(0 To arraySize)

This does mean though that all the automatic growing and shrinking has to be added by hand, and push and pop don’t work at all. In short, you have to do everything yourself.

Which I did by the way, you can download my classes here.

Mangled Tiers

Every non-trivial application, particularly multi-user applications, is best handled with multiple tiers: A database tier, a client/presentation tier, maybe an application server in between, that’s usually enough but can be extended. Less is bad, more is more complicated but depending on the application, necessary.

In MS Access, everything is “in the database” by default. Now,what does this mean? Basically, it’s a mess, and sorting things out properly is nearly impossible, whenever you update the database you also update the application and extending the user circle beyond, say, 1-2 users inevitably leads to problems (more on this later).

It is worth noting that these tiers can be somewhat simulated by using multiple databases for different purposes: You can easily have an “application” database that just does frontend work, and a “data” database. You can then create links from the “application” database to the “data” database, and have the frontend update independendly of the backend.

That’s common practice and makes sense, and comes close to true multi tier programming, although it still makes a mess of things because those links are hardcoded file paths and aren’t as easy to manage as they should be; the “data” database’s location has to be known on a file share, and every user needs write access to that share, which leads to obvious security inconsistencies and further problems that we’ll explore in the course of part 3.

The problem about paths being hardcoded can of course be solved by writing libraries that update paths, and the tier problem as a whole can to some extent be resolved by having data reside in an MS SQL (or other, through the rather dated ODBC) database.

What’s MVC?

This problem is very similar to the last one concerning mangled tiers. Modern applications often use, for maintenance and development reasons, a Model-View-Controller approach. Some languages and frameworks, like Ruby on Rails, even make it really hard not to (which is good, considering the approach makes sense). Now, if you want to create a program that’s cleanly using that paradigm in VBA, you basically have to ignore all the structure there is and make a new one. The good news is that you can actually do that, of course, and VBA doesn’t stop you from doing it – it just doesn’t help you a bit.

It all starts out so nicely:

• The model is the database, tables and views can be accessed via DAO or ADO
• The view is WYSIWYG-edited and stashed in Reports and Forms
• Every Frame has its own class, akin to its very own controller

Regarding models: Yes, in theory it’s nice like that. However, as soon as we start having things that go beyond tables and views, we’re screwed. That goes for simple things like tree view models (that are stored inside the tree view and not really accessible from the outside). You can make stand-alone recordsets (aka RAM tables), you can even disconnect recordsets from their source, that’s good. But overall, the model is in the view and vice versa, splitting the two is hard and in some places impossible.

The view only in the WYSIWYG editor is a nice thought for simple things, but when you want to start exchanging components on the fly, you have to write your own view classes (or end in chaos, as many VBA projects do) anyway. Or, the alternative many VBA projects take, have invisible components that you make visible or visible depending on the mode the form currently is in – a maintenance nightmare. The best approach here is having subforms and exchanging those, that actually works really well too and is my favourite approach. It’s just not the way VBA and Access make easy, and it can yet again very easily lead to duplicated bits (code or UI components).

Finally, the controller – you can avoid duplicated code and make pretty good controllers if you completely ignore the Frame’s default classes and only use those for proxying your own controller classes that you write in addition to them. Works well, it’s just, again, not the way VBA and Access makes easy.

That’s all for now, we’re warming up. Stay tuned for…

• Part 2 with error handling, IDE, object orientation and the community
• Part 3 with syntax, MS Access, other things and a conclusion

part 1 – part 2 – part 3

Dim primitiveVector As clsVector
Set primitiveVector = New clsVector
Dim myInt As Integer
myInt = 3
 
primitiveVector.AddItem myInt

There are of course other people who have made such a thing, and there’s the VBA Collection, but none of them quite fit what I wanted. I wanted a Vector that had random access, was able to handle LIFO and FIFO (and thus act as stack and queue), addition and insertion and deletion, could check for item existence, and had dynamic resizing. So I went and coded my own. I did this while working at Promino AG and thus the code is technically theirs, so thanks to Paul Moser for the nod for publishing this under the GNU Lesser General Public License.

You can download both classes (two? more below), together with a tiny trivial testing framework, as Access 2002-2003 .mdb.

This here is the vector class for Variants. It goes into a new class module, I called mine “clsVector”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101

Option Compare Database
Option Explicit
 
' Copyright 2007, 2008 by Promino AG
' Author: Guido Gloor
'
' This program is free software: you can redistribute it and/or modify
' it under the terms of the GNU Lesser General Public License as published by
' the Free Software Foundation, either version 3 of the License, or
' (at your option) any later version.
'
' This program is distributed in the hope that it will be useful,
' but WITHOUT ANY WARRANTY; without even the implied warranty of
' MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
' GNU Lesser General Public License for more details.
'
' You should have received a copy of the GNU Lesser General Public License
' along with this program.  If not, see <http://www.gnu.org/licenses/>.

Private itemCount As Integer
Private itemBufferSize As Integer
Private itemBuffer() As Variant
 
Private Sub Class_Initialize()
    itemCount = 0
    itemBufferSize = 100
    NewDimensions
End Sub
 
Private Sub NewDimensions()
    ReDim Preserve itemBuffer(itemBufferSize) As Variant
End Sub
 
Private Sub CheckDimensions()
    If itemCount > itemBufferSize - 2 Then
        itemBufferSize = itemBufferSize * 2
        NewDimensions
    End If
End Sub
 
Public Sub ShrinkDimensions()
    itemCount = itemBufferSize + 10
    NewDimensions
End Sub
 
Public Function GetSize() As Integer
    GetSize = itemCount
End Function
 
Public Sub AddItem(item As Variant)
    CheckDimensions
    itemBuffer(itemCount) = item
    itemCount = itemCount + 1
End Sub
 
Public Function GetItem(index As Integer) As Variant
    GetItem = itemBuffer(index)
End Function
 
Public Function PopItem() As Variant
    PopItem = itemBuffer(itemCount - 1)
    DeleteItem itemCount - 1
End Function
 
Public Function GetNextQueueItem() As Variant
    GetNextQueueItem = itemBuffer(0)
    DeleteItem 0
End Function
 
Public Function ContainsItem(item As Variant) As Boolean
    Dim i As Integer
    ContainsItem = False
 
    For i = 0 To itemCount - 1
        If itemBuffer(i) = item Then ContainsItem = True
    Next i
End Function
 
Public Sub InsertItem(index As Integer, item As Variant)
    Dim i As Integer
 
    CheckDimensions
    For i = itemCount - 1 To index Step -1
        itemBuffer(i + 1) = itemBuffer(i)
    Next i
    itemBuffer(index) = item
    itemCount = itemCount + 1
End Sub
 
Public Sub DeleteItem(index As Integer)
    Dim i As Integer
 
    For i = index + 1 To itemCount - 1
        itemBuffer(i - 1) = itemBuffer(i)
    Next i
    itemCount = itemCount - 1
End Sub
 
Public Function IsEmpty() As Boolean
    IsEmpty = itemCount <= 0
End Function

Now, it would be nice if we would be done. But, we’re not done yet, obviously, after all there’s plenty more code below this break. The reason for that is simple: In VBA, a Variant is not an Object, and an Object is not a Variant, consequently functions that take Objects don’t take Variants and vice versa (although you can technically store an Object in a Variant, this will lead to problems). Objects also happen to have “Set” mandatory in places where it isn’t allowed for Variants.

What this means is that there is no way to have the same Vector class for both your custom ADTs and the primitive data types. So basically, we have another class that has exactly the same functions and exactly the same algorithms, but takes Objects instead of Variants. I called mine “clsObjectVector”. Here is the source for the class module:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102

Option Compare Database
Option Explicit
 
' Copyright 2007, 2008 by Promino AG
' Author: Guido Gloor
'
' This program is free software: you can redistribute it and/or modify
' it under the terms of the GNU Lesser General Public License as published by
' the Free Software Foundation, either version 3 of the License, or
' (at your option) any later version.
'
' This program is distributed in the hope that it will be useful,
' but WITHOUT ANY WARRANTY; without even the implied warranty of
' MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
' GNU Lesser General Public License for more details.
'
' You should have received a copy of the GNU Lesser General Public License
' along with this program.  If not, see <http://www.gnu.org/licenses/>.

Private itemCount As Integer
Private itemBufferSize As Integer
Private itemBuffer() As Object
 
Private Sub Class_Initialize()
    itemCount = 0
    itemBufferSize = 100
    NewDimensions
End Sub
 
Private Sub NewDimensions()
    ReDim Preserve itemBuffer(itemBufferSize) As Object
End Sub
 
Private Sub CheckDimensions()
    If itemCount > itemBufferSize - 2 Then
        itemBufferSize = itemBufferSize * 2
        NewDimensions
    End If
End Sub
 
Public Sub ShrinkDimensions()
    itemCount = itemBufferSize + 10
    NewDimensions
End Sub
 
Public Function GetSize() As Integer
    GetSize = itemCount
End Function
 
Public Sub AddItem(item As Object)
    CheckDimensions
    Set itemBuffer(itemCount) = item
    itemCount = itemCount + 1
End Sub
 
Public Function GetItem(index As Integer) As Object
    Set GetItem = itemBuffer(index)
End Function
 
Public Function PopItem() As Object
    Set PopItem = itemBuffer(itemCount - 1)
    DeleteItem itemCount - 1
End Function
 
Public Function GetNextQueueItem() As Object
    Set GetNextQueueItem = itemBuffer(0)
    DeleteItem 0
End Function
 
Public Function ContainsItem(item As Object) As Boolean
    ' The used ADTs need to have an Equals function for this to work
    Dim i As Integer
    ContainsItem = False
 
    For i = 0 To itemCount - 1
        If itemBuffer(i).Equals(item) Then ContainsItem = True
    Next i
End Function
 
Public Sub InsertItem(index As Integer, item As Object)
    Dim i As Integer
 
    CheckDimensions
    For i = itemCount - 1 To index Step -1
        Set itemBuffer(i + 1) = itemBuffer(i)
    Next i
    Set itemBuffer(index) = item
    itemCount = itemCount + 1
End Sub
 
Public Sub DeleteItem(index As Integer)
    Dim i As Integer
 
    For i = index + 1 To itemCount - 1
        Set itemBuffer(i - 1) = itemBuffer(i)
    Next i
    itemCount = itemCount - 1
End Sub
 
Public Function IsEmpty() As Boolean
    IsEmpty = itemCount <= 0
End Function

This is it, have fun As much as you can have if you’re forced to work with VBA, that is.

Oh, and if you can use it – comments are appreciated