Dead Space

I had heard a lot of positive buzz about Dead Space, the new EA SciFi horror shooter, so my expectations were naturally high. When Steam finally had it (funny enough, I’m one of those odd folks who are up in arms against any form of too rigid DRM except when it’s Steam), and in English too (something that’s nigh impossible to get here in Switzerland in retail, but that’s another issue), I bought it.

So yesterday I tried to play it, with those high expectations, and with disastrous results. Those were my first impressions:

• Odd strafing … When a game moves you forward with speed X when you press “W”, and moves you sideways with a speed close to X when you press “A”, you’d expect pressing both “W” and “A” would move you roughly in a 45° angle? Not in this game, here the angle is closer to 4.5°. That’s a common shooter standard that you chose not to implement there, and it is annoying.
• Aim mode … You can only shoot if you enter aim mode first, which displays those nice targeting dots, but which also slows down your mouse a lot. You know, EA, I do have this custom-built gaming rig with an insane-res laser mouse and a huge mouse pad, and I do play with low sensitivity. I can aim perfectly well without you slowing down my mouse – in fact, I can aim way better if you don’t keep changing my input. This is not a console. At least give me an option to change it.
• Mouse smoothing … Turning off VSync helped a bit, but the smoothing isn’t gone (with 50+ FPS). And there’s no option to switch it off. My mouse movements are rather smooth, thank you very much, and having them artificially smoothened further disconnects me from what’s happening on the screen. And I’m not alone (although I wouldn’t use such strong language).
• Save function … There is none. I have no clue if the game is supposed to autosave or if there’s checkpoints and forced save spots or whatnot. And honestly, I don’t care. A PC game without a save function has to explain to me why it doesn’t have one, preferrably within the first minutes of play. And then the reason better be good, too (like the one in PoP: Sands of Time was).
• Program crash … Right after shooting the first monster, my game crashed. Not just the game, the whole system halted. It managed to do something I didn’t know was possible: It put the video card into an error state where a soft reset didn’t help anymore (the BIOS then beeped “video card error”), a hard reset did luckily. I’m sorry, EA … is my run-of-the-mill 8800GT (market share according to Valve: 12%, drivers updated) too exotic for you?

All in all, I can confidently conclude that something is wrong in the EA PC testing department. And I can even point to what it is: The ones testing PC games there are not actually PC gamers, but console gamers who have to test the PC version as well. No way those huge bloopers would have made it into the final obvious console port otherwise.

It’s just another game that alienates PC gamers by screwing with their conventions in favour of a game experience similar to the one on the console. In case you haven’t noticed: The demographics of PC players and console players might overlap, but have distinct histories and premises.

Now if you’ll excuse me, work first, and I’ll need some Quake Live (or possibly Left 4 Dead) this evening to calm down. Maybe I’ll give Dead Space another try afterward, the story seems to be great so far after all.

Sarah Palin

Apart from her being rather incompetent (“cramming a lot of information”, as if, she just doesn’t find her way around the notes others have prepared for her), Sarah Palin apparently really likes fashion. And hairdressers. And makeup.

According to financial disclosure records, the accessorizing began in early September and included bills from Saks Fifth Avenue in St. Louis and New York for a combined $49,425.74.

The records also document a couple of big-time shopping trips to Neiman Marcus in Minneapolis, including one $75,062.63 spree in early September.

The RNC also spent $4,716.49 on hair and makeup through September after reporting no such costs in August.

Ah well. I refrained from posting about the US election so far, it’s just too hyped up even in European media, and the US voters seem to be less informed by the day, start being openly and no longer covertly racist again, but this is just silly.

Although, on second thought, maybe the money is better spent that way.

Via tou.ch (German).

RFID - How It Works

The Swiss government has decided that our passports, like a few before ours, should store data on RFID chips. Meaning, the following data would be stored in that chip:

• fingerprints
• a digital photograph
• all the data that’s also available in printed form (name, gender, date of birth, eye color, and so on)

All this data could then be read out via electrical readers (as pictured in the diagram to the right, labels German).

That in and of itself isn’t necessarily evil! The current proposal concerning regulations and technology lets it be implemented in ways that make it evil though. Let me lay out why that is.

About RFID

If you haven’t heard of RFID before, it’s high time you read up at Wikipedia – and even if you did, there’s quite intriguing things I haven’t read before in there too. Short version:

An RFID tag is an object that can be applied to or incorporated into a product, animal, or person for the purpose of identification and tracking using radio waves. Some tags can be read from several meters away and beyond the line of sight of the reader.

Additionally, the RFID chip can be passive – meaning, it has no energy source of its own and thus potentially lives forever. And as I’ll explain later more in-depth, you can’t track who obtains information from it. There are also active RFID chips, but since the ones used in passports are passive and there are no other fundamental differences beyond range between active and passive types, I’ll neglect active RFID chips for the rest of this post.

There are places where RFID chips make sense and most privacy concerns don’t apply (like race tracking, inventory systems, some kinds of animal tracking). But passports definitely aren’t one of them.

The Referendum

The referendum (a federal facultative referendum, that is) is carried from a surprisingly (in a very positive way) large number of independent political forces.

The referendum was launched because there is a vast number of unresolved issues that are introduced with biometric RFID passes (details see below).

Here is the RFID referendum website

If you’re Swiss, I strongly urge you to sign it within the next 10 days, if you haven’t already, and spread it among your friends and coworkers. Time is running out, the referendum only runs until September 22th, and apparently, over 30′000 more signatures are needed. Signature sheets are available on their site.

Privacy

It is not a coincidence that the RFID chip started out, originally, as an espionage device. Its passive nature and long life make it perfect for stealth placement and readout.

Accesses to the chip are not trackable, and while the chips in passports are protected by a metal mesh covering them that shields them against malicious scans, this (just like other things when it comes to RFID) doesn’t work as it should. Uncovered at the Blackhat 2006, a proof of concept showed:

The problem, according to Flexilis, is that the shielding does not fully protect passport against remote scans. Kevin Mahaffey from Flexilis says a medium powered scanner could detect a partially opened passport from four to six inches away. The theoretical maximum detection range is more than 10 feet, but Mahaffey said that would require a “huge amount of power.”

So, when you have such a passport, you’re trackable, identifiable, by anyone who has access to that kind of technology. Which is just about anyone who’s determined enough.

Furthermore, even “legitimate” (as per the legal text) kinds of tracking can go way beyond what we’re comfortable with. Airline companies, other companies with special permissions, your own and foreign governments, can and may track your every move. And once enough companies have your data in their databases, it’s bound to be stolen and out in the open eventually – data leaks do happen.

If you’re in the fortunate position to understand German, the StopRFID pages of the FoeBuD e.V. have way more info.

Security

There is a simple fact about RFID chips that no lobbyist will openly admit:

They are not secure.

You may have heard of MythBusters. It’s a Discovery Channel series that … busts myths. Often funny, like “can you surf on a wave created by a dynamite explosion”, but also stuff like “can you hack security fingerprint systems”. They tried to do an episode on RFID, and they were shut down by the industry. You draw the conclusions. References here: tom’s hardware, cnet news, the consumerist, all via Bruce Schneier.

“But”, I hear you say, “they’re meant to be made secure!” Well … yes. Read for yourself, in the federal Swiss decree:

Der Datenchip ist gegen Fälschungen und unberechtigtes Lesen zu schützen. Der Bundesrat bestimmt die entsprechenden technischen Anforderungen.

More or less, the chip is to be protected against malicious readouts, and details are to be determined by the executive.

But, there’s a problem with this: The same thing was meant to happen with the British passes’ RFID chips. And what happened? They were hacked a couple weeks after they were released. Read the details on The Guardian:

“The reader – I bought one for £250 – has to say hello to the chip and tell it that it is authorised to make contact. The key to that is in the date of birth, etc. Once they communicate, the conversation is encrypted, but I wrote some software in about 48 hours that made sense of it.”

More info on TechNewsWorld. Now, this was a white hat hacker. Who tells us that black hats have problems with what he achieved in 48 hours? We already know that it’s easy to access credit card numbers like that, why should full blown identity theft be made as easy as the (too easy) credit card theft?

Teleology

As we know, the main reason for adding those RFID chips in the first place is that the US wants everybody to do so. In their Enhanced Border Security and Visa Reform Act of 2002, we find:

Additionally, by October 26, 2004, in order for a country to remain eligible for participation in the visa waiver program its government must certify that it has a program to issue to its nationals machine-readable passports that are tamper-resistant and which incorporate biometric and authentication identifiers that satisfy the standards of the International Civil Aviation Organization (ICAO).

Why is it that the US government wants everybody to use those RFID chips in the first place then? Bruce Schneier has, yet again, brilliant vista:

The Bush administration is deliberately choosing a less secure technology without justification. If there were a good offsetting reason to choose that technology over a contact chip, then the choice might make sense.

Unfortunately, there is only one possible reason: The administration wants surreptitious access themselves. It wants to be able to identify people in crowds. It wants to surreptitiously pick out the Americans, and pick out the foreigners. It wants to do the very thing that it insists, despite demonstrations to the contrary, can’t be done.

This, of course, is speculation. I haven’t seen another reasonable explanation to date yet though.

The fun thing is that the US government keeps pursuing that course, despite even large independent bodies like the Smart Card Alliance (who actually represents RFID vendors, among others, and thus has it in their best economic interest that RFID chips are used) warning them from privacy and security dangers. If you have a long breath, you might want to read this extensive report from May 2006.

The future

Maybe some time in the future, the technology will be where it needs to be in order to make a private, secure chip that makes international travel easy without exposing its users to unnecessary risks. The proposed RFID chips certainly aren’t that technology.

Of course, even when we eventually do have the technology, other things like better tolerance and education would be more effective in preventing terrorism. But that’s an entirely different discussion.

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

PSP

After only having written about awesome games so far, it’s time there’s some negativity on this blog as well. So I decided to write a list with the worst PSP games I’ve played so far. Keep in mind that as always, the list is subjective, and unordered. And, there are plenty of good PSP games, so this is not a post that says anything like “the PSP sucks”.

Here we go, the worst PSP games I’ve played to date.

• Guilty Gear Judgement: I guess if you’re a fan of the Guilty Gear series, you’ll like this one. I never found a combo, just 4 repetitive attacks, always the same enemies every stage … boring.
• The Simpsons: I’m a huge Simpsons fan. The game has potential, with all the different specials and levels and whatnot. If it weren’t for the horrible, awkward, terrible camera. No go. Please, don’t make me jump to my doom by rotating the camera mid-air.
• Bubble Bobble Evolution: Artificial story (the dragons are no longer dragons but boys), a strange nemesis that helps the heroes get out of his prison, 3D features that weren’t necessary, and strange controls with enemies that I have no idea how to defeat, I tried for 30 minutes … nothing like I remember Bubble Bobble to be.
• Space Invaders Evolution: I thought I’d get Space Invaders Extreme, which got good reviews, silly old me. The Evolution one is just Space Invaders in 3D, more or less … not horribly bad, but played a million times.
• Valkyrie Profile: Lenneth: You like watching confusing 2D ingame graphic cutscenes while you’re pretending to play a game? Occasionally clicking a button (just one, mind you) every 15 minutes, for hours? I don’t. Maybe the game changes after 90 minutes though, who knows.
• Silent Hill: Origins: I liked this one, the setup, the mood, the city, the story. Until the fights started getting a bit harder, and the problem weren’t so much tough enemies as horrible controls and fiddly inventory. Sad, really.
• Mega Man: Maverick Hunter X: Supposedly brings Mega Man into 3D – which it does, to some extent. Too bad the controls are nothing like I remember them to be, and jumping and shooting are tough to coordinate. I have plenty of known good games that are easy to control, no reason to wrestle horrible controls for a potentially good game.
• SSX On Tour: This one actually does many things right – except that the PSP’s screen is much too small to make you feel like you’re actually snowboarding. Which is what bought me when I first played the very first SSX. So, sorry, wrong platform.
• Prince of Persia Revelations and Rival Swords: The problem with these is that they’re pure ports (with very few more levels). Meaning, the graphics aren’t optimized, read blurry, and while the story and levels are great they’re just copies of what you played already, or can have better on a big console or computer.
• Worms: Open Warfare 2: Occasional stuttering and being a game that hasn’t been made for the PSP’s resolution (with too small fonts and irregularly pixelated worms, much unlike the very first Worms that had intentional and controlled pixelation) make this way worse than it could and should have been, too bad.

There you go. Of course, I’ll eventually make the counterpart to this post, with all the games I like.