I have a few posts coming up about various coding stuff so I thought I would lay some of the groundwork.

An interface is the bit of something that gets exposed so you can interact with the bit that actually does the work. The classic example is a video recorder, the interface being the play/rewind buttons that we use to control whatever goes on inside, which most of us neither know or care about.

Same with a car, the interface is the driver controls, we don’t care about the engine, just that it wheelspins in 3rd when you hoof it. (must have been an ice patch officer (in July))

From a code point of view the interface is the set of externally accessible functions, variables, properties, methods, subs, or whatever. Some might only be accessible within the same project, some might be accessible from totally separate bits of code.

Same project is easy enough we often do that with public subs in modules in VBA. Making stuff visible from a different component though is a bit more challenging, especially in VBA, but the principle is the same.

Those nice people at Microsoft equipped Excel with several sets of externally accessible functions. One is the C API, this Application Programming Interface follows the C calling convention, and cannot be accessed by VB as VB doesn’t do the C calling convention. In fact this set of functions can only be accessed by real native code components so is out of (direct) reach of .net etc. I am going to cover this stuff in more detail as time goes on.

The other interface Excel exposes is a COM one, COM is much less picky than C so a great many languages can talk to Excel via this interface. VBA is probably the most common, but most languages can do it using something similar to CreateObject(‘Excel.Application’) and then navigating the object model just as we do in VBA. I’m going to cover this later too, which could be fun.

The most useful point about interfaces is that they can stay stable whilst all the stuff in the background gets changed. (This is what that binary compatibility malarky was in VB6 – get that wrong and you eventually crashed your registry – anyone else do that?).

So in rough summary:

interface = bunch of procedures and variables that can be seen from outside.

stable interface = good, frequent interface changes = bad (all clients affected)

Feel free to add or remove or correct in the comments




2 Responses to “Interfaces”

  1. Ross Says:

    I started to look at the XLOPER inter face a while back, it didn’t look to great to me, a bit messy almost – but having said that I know nothing about what a good C interface should look like!

  2. Bryan Schmidt Says:

    RE: Ross’ Comment,
    There really isn’t a rulebook stating what a good interface should look like. I think the most important thing to interface design is knowing the difference between what commands are going to be used the most, and which ones are going to be used once in a blue moon. This will determine size and location of objects. After you know which controls are the most important, I believe the next important thing is to create tooltips, visual cues, and maybe even help dialogs that will steer an end-user in the direction they want to go. I have found many times, that after creating a very intuitive GUI, there were still questions and confusions. How did I conquer that? Many test runs. (That project is still in Beta, haha)

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: