Tag: development

Excel Geeking: A Question For Other Excel Geeks

December 20th, 2013

Okay, this one is a bit out on a limb, since I don’t have a lot of followers, and expect most of them follow me for the writing or running posts, but here goes.

I have a question for my fellow Excel geeks and gurus regarding development and design.

Anybody with thoughts or opinions is welcome to jump in with comments.

And who isn’t thinking about Excel programming going into the weekend, amiright?

Here’s the background:

I have a set of workbooks that are basically set up to “act” as databases. There being a restriction on the use of MS Access, Excel became the database of choice. Let’s not publicly debate whether or not Excel is a database, it’s what I inherited and have to work with. We all know it’s “database”, with quotation marks around it. Let’s move on.

I’ve been trying to get the users out of this Excel “database” by using other, separate workbooks for reporting shells, and using SQL to retrieve the data from the Excel “database”. So far, so good.

I’m at a point now, however, where I may have the option to migrate some of this Excel “database” stuff to a real database, while keeping Excel as a front end and user interface. Beautiful, Totally in my wheelhouse.

Here’s where I’m, not stuck exactly, but rather in a bit of a quandary as to how far to take my new approach.

The Excel UI workbooks are going to require support tables to make them run. Those support tables are going to be housed in a database. Upon opening the UI workbook, the SQL statements will fire off, careening over the network via ADO connections, and sucking the data back down the pipe, only to land in the UI workbooks and make everything sunshine and roses.

Which, based on my current programming, it does.

Except I don’t want to hard code five or ten or fifteen or whatever number of SQL queries it will take to load the support tables.

So I came up with what I felt was a nice, tidy, and portable solution. A SQL table range in a worksheet that will house the SQL statements themselves, and as I iterate through it, the SQL (all SELECT–let’s not make life hard with INSERT, UPDATE, and things of that ilk) will be read from the cells, fed into a custom class I built for managing ADO connections to databases (it’s sweet, I’ll share it sometime), and off to the database the SQL will go.

Fantastic so far. No problems. Everything working like a dream.

Until the thought occurred to me, “You’re still hard coding your SQL, you’re just doing it in a worksheet instead of directly in VBA.”

Well, gosh darn it all, that’s true. The SQL would have to be written into the table range prior to the roll-out of the UI workbook, and if it changes, I’d have to recall the workbook and issue a rev’d version.

Unless…

And here’s where I need the help. My next step, which is done by the way, was to create another table in the database, one that houses the SQL statements themselves. So now, when the UI workbook launches, it loads all the SQL statements first, THEN fires them off one by one until all the supporting tables have been loaded.

At this point I took a step back and thought, am I nuts? I mean, behind the regular brand of nuts? Am I building this thing up to much for a workbook application? The idea behind it was to load SQL statements that could be centrally managed in the database by an administrator. If something in the SQL changes, then the SQL statement housed in the database can be changed, and when the UI workbook runs, it will pull down the new SQL and run with that, rather than having to go into the UI workbook and change it manually in a worksheet.

So the question I have for my fellow geeks and gurus is: have I gone too far? Is this overkill? Am I SQL-drunk?

Excel Geeking: Using VBA With Configuration Files

December 3rd, 2013

Nothing like a good old fashioned configuration file to make you feel like you’re programming in 1995. But you know what? Sometimes you just need to do it. And it still amazes me how many off-the-shelf applications still rely on INI files to store their settings (I’m looking at you, LotusNotes!).

Personally, I like INI files. I find them easy to work with and easy to deploy. And, of course, it doesn’t hurt that you can read and write to them using VBA.

If you Google reading or writing to INI files using VBA, you’ll get a bunch of different results, all pointing you in the same basic direction. Specifically, you need to use two different Windows APIs in order to do this “GetPrivateProfileString”, and “WritePrivateProfileString”. One reads from an INI file, the other writes to it. I’m going to assume you can figure out which is which.

Invariably, the examples you uncover on Google show that these routines are always separate. One routine fo reading, one for writing.

I hate that.

I like my code as concise as possible while still being as modular as possible. What do I mean by that? I mean that I want a routine (or function in this case) that I can call from another point in the code and choose whether I’m reading or writing to the configuration file. And I want the routine portable enough so I can drop it into any application I want and not have to worry about customizing it too terribly much.

And so, I give you the code below, commented for your pleasure:


'*******************************************************************************
' Declaration for Reading and Wrting to an INI file.
'*******************************************************************************

'++++++++++++++++++++++++++++++++++++++++++++++++++++
' API Functions for Reading and Writing to INI File
'++++++++++++++++++++++++++++++++++++++++++++++++++++

' Declare for reading INI files.
Private Declare Function GetPrivateProfileString Lib "kernel32" _
    Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String, _
                                      ByVal lpKeyName As Any, _
                                      ByVal lpDefault As String, _
                                      ByVal lpReturnedString As String, _
                                      ByVal nSize As Long, _
                                      ByVal lpFileName As String)As Long
                                      
' Declare for writing INI files.
Private Declare Function WritePrivateProfileString Lib "kernel32" _
    Alias "WritePrivateProfileStringA" (ByVal lpApplicationName As String, _
                                        ByVal lpKeyName As Any, _
                                        ByVal lpString As Any, _
                                        ByVal lpFileName As String)As Long


'++++++++++++++++++++++++++++++++++++++++++++++++++++
' Enumeration for sManageSectionEntry funtion
'++++++++++++++++++++++++++++++++++++++++++++++++++++

Enum iniAction
    iniRead = 1
    iniWrite = 2
End Enum
'*******************************************************************************
' End INI file declaratin Section.
'*******************************************************************************

Function sManageSectionEntry(inAction As iniAction, _
                             sSection As String, _
                             sKey As String, _
                             sIniFile As String, _
                             Optional sValue As String)As String
'*******************************************************************************
' Description:  This reads an INI file section/key combination and
'               returns the read value as a string.
'
' Author:       Scott Lyerly
' Contact:      scott.c.lyerly@gmail.com
'
' Notes:        Requires "Private Declare Function GetPrivateProfileString" and
'               "WritePrivateProfileString" to be added in the declarations
'               at the top of the module.
'
' Name:                 Date:           Init:   Modification:
' sManageSectionEntry   26-Nov-2013     SCL     Original development
'
' Arguments:    inAction    The action to take in teh funciton, reading or writing to
'                           to the INI file. Uses the enumeration iniAction in the
'                           declarations section.
'               sSection    The seciton of the INI file to search
'               sKey        The key of the INI from which to retrieve a value
'               sIniFile    The name and directory location of the INI file
'               sValue      The value to be written to the INI file (if writing - optional)
'
' Returns:      string      The return string is one of three things:
'                           1) The value being sought from the INI file.
'                           2) The value being written to the INI file (should match
'                              the sValue parameter).
'                           3) The word "Error". This can be changed to whatever makes
'                              the most sense to the programmer using it.
'*******************************************************************************

On Error GoTo Err_ManageSectionEntry

    ' Variable declarations.
    Dim sRetBuf         As String
Dim iLenBuf         As Integer
Dim sFileName       As String
Dim sReturnValue    As String
Dim lRetVal         As Long
    
    ' Based on the inAction parameter, take action.
    If inAction = iniRead Then  ' If reading from the INI file.

        ' Set the return buffer to by 256 spaces. This should be enough to
        ' hold the value being returned from the INI file, but if not,
        ' increase the value.
        sRetBuf = Space(256)

        ' Get the size of the return buffer.
        iLenBuf = Len(sRetBuf)

        ' Read the INI Section/Key value into the return variable.
        sReturnValue = GetPrivateProfileString(sSection, _
                                               sKey, _
                                               "", _
                                               sRetBuf, _
                                               iLenBuf, _
                                               sIniFile)

        ' Trim the excess garbage that comes through with the variable.
        sReturnValue = Trim(Left(sRetBuf, sReturnValue))

        ' If we get a value returned, pass it back as the argument.
        ' Else pass "False".
        If Len(sReturnValue) > 0 Then
            sManageSectionEntry = sReturnValue
        Else
            sManageSectionEntry = "Error"
        End If
ElseIf inAction = iniWrite Then ' If writing to the INI file.

        ' Check to see if a value was passed in the sValue parameter.
        If Len(sValue) = 0 Then
            sManageSectionEntry = "Error"

        Else
            
            ' Write to the INI file and capture the value returned
            ' in the API function.
            lRetVal = WritePrivateProfileString(sSection, _
                                               sKey, _
                                               sValue, _
                                               sIniFile)

            ' Check to see if we had an error wrting to the INI file.
            If lRetVal = 0 Then sManageSectionEntry = "Error"

        End If
End If
    
Exit_Clean:
    Exit Function
    
Err_ManageSectionEntry:
    MsgBox Err.Number & ": " & Err.Description
    Resume Exit_Clean

End Function

Some thoughts on what’s going on here:

I’ve taken the two APIs that you would call to read and write to a configuration file and put them into a single function. I’m choosing which action to take based on the inbound inAction parameter.

That parameter, inAction, you may have noticed is an enumeration set up at the top of this module. I like the enumeration in this case because it lets me be very specific in my choice of action to take with regard to the INI file. Yes, I could have saved four lines of code by using a boolean instead. I could have set the function to “read” if TRUE and “write” if FALSE. Except I hate that option. I like enumerations for explicitly spelling out what my options are for value for a specific parameter. That way there’s no confusion.

So what does the implementation of this function look like? Glad you asked! I’ve included a sample routine below that you easily use to test this function out.


Sub SampleINIFunctionImplementaion()

    Const sINI_FILE As String = "C:\Users\scott\Desktop\fruits & veggies.ini"

    Dim sReturn As String

    ' Read the ini file
    sReturn = sManageSectionEntry(iniRead, "Produce", "Fruit", sINI_FILE)
    MsgBox sReturn
    sReturn = sManageSectionEntry(iniRead, "Produce", "Vegetable", sINI_FILE)
    MsgBox sReturn

    ' Write to the ini file
    sReturn = sManageSectionEntry(iniWrite, "Produce", "Fruit", sINI_FILE, "banana")
    sReturn = sManageSectionEntry(iniWrite, "Produce", "Vegetable", sINI_FILE, "squash")

 End Sub

That’s about it. Feel free to copy and paste and use for your own Excel applications.

(Fine print: use at your own risk, blah blah blah…)

Excel Geeking: Backdoor Into Your Excel Files

November 21st, 2013

When I’m building a spreadsheet application, invariably I have to have a routine that initializes the application. Often times I have sheets I need to hide from the end user. These are usually sheets full of configuration settings or system tables, things like that. I might also have toolbars that call certain functions or routines. I might have password protection on some of the sheets. You get the idea.

What I usually do is to add a small function that allows me to crack open the full workbook without having to go into the code itself to open everything up.

I start by putting an empty file of some sort in the same directory location as the application workbook. I’ll call it something like “debug.ini” or “password.txt” or “backdoor.ini” or something similar. It can actually be anything really. The file won’t hold anything, it just needs to be present.

Once the file is in place, you can add the code below as a function in a module. If you’re following any of the practices from “Professional Excel Development” by Bullen, Bovey, and Green, then you’d probably stick this in a module called MSystemCode. But it’s totally up to you.

Function bDebugMode() As Boolean ' Description: This checks the whether the application should be opened in debug mode. ' ' Author: Scott Lyerly ' Contact: scott.c.lyerly@gmail.com ' ' Name: Date: Init: Modification: ' bDebugMode 21-Nov-2013 SCL Original development ' ' Arguments: None ' ' Returns: Boolean TRUE = success, FALSE = failure '
' Review the length of the path and file name of the debug file using Dir. If Len(Dir(ThisWorkbook.Path & "\debug.ini")) = 0 Then ' The the lenght is zero (0), the file does not exist and ' we are not in debug mode. bDebugMode = False Else ' If the length is greater than zero (0), we are in debug mode. bDebugMode = True End If
End Function

I’ve got plenty of comments in the code, so I don’t think I need to break it down further here.

Once this function is in place, add the code below to the Workbook_Open event so that it fires whenever the file is opened.

Private Sub Workbook_Open()
' Check if the application is in debug mode. ' If it is not, initialize the application for the user. If Not bDebugMode Then InitializeApplication Else ' If we are in debug mode, open the file up and unprotect the Demand tab. OpenFileForDevelopment End If
End Sub

You can see that I have two branches this application can go down. One is to proceed as normal, with the application not opening in debug mode. I typically call the routine for that branch something like “InitializeApplication”. It’s where I store all the code I want to run before the user can use the file.

The second branch might be called “OpenFileForDeveloment”. This is the branch to go down when I want to unhide everything, unprotect everything, and prevent user interface items like toolbars from being created.

Using this practice, I can open the file in a user mode or a debug/development mode without touching a single line of code.

Tag: development

Excel Geeking: A Question For Other Excel Geeks

Excel Geeking: Using VBA With Configuration Files

Excel Geeking: Backdoor Into Your Excel Files