Tag: Microsoft Office

Dealing with Acronyms and Abbreviations

My books are packed with acronyms and abbreviations, and readers complain about them all the time. An acronym is a series of letters that shorten a term and you can say. For example, Language INtegrated Query (LINQ) is pronounced “link” so it counts as an acronym. An abbreviation is a shortened version of a term or phrase. For example, MicroSoft Developer Network (MSDN) is an abbreviation because you can’t say the term and must instead say each letter individually. Whether the term is an acronym or an abbreviation, I usually try to define it once every chapter. However, some truly common terms are only defined once in a book and if a term is considered universally known outside computer circles, such as CPU (for Central Processing Unit), I don’t define it at all.

Unfortunately, making an assumption can be a dangerous thing. I try to err on the side of defining terms too often so that readers can gain maximum benefit from my books with the least amount of effort. However, even making my best efforts, there are times when you might find an acronym or abbreviation that you simply don’t understand in one of my books. When this happens, you can always contact me at [email protected] and I’ll be happy to define it for you. My goal is to ensure you have a great reading experience and that you discover everything possible about the topic at hand.

Some people prefer to do things for themselves. Hands on learning produces the best results for them and I do understand the need to address the learning methods each person uses with greatest ease. In this case, you have other options for finding the term you need defined. These sites will provide you with common terms used in my books (depending on the book, you may need to use more than one site):

Of course, there are many other fine online references, but these references should provide what you need in most cases. The worst case scenario would be to use the acronym or abbreviation without really knowing what it means. I encounter this problem all too often. Readers will contact me with a question that I truly can’t understand because of a misused term. Knowing what terms mean is an essential part of clear communication. Given that most of my communication is through e-mail, clear communication saves time and effort for everyone involved.

The question I get asked relatively often about acronyms and abbreviations is why the computer community uses them at all. After all, they’re confusing. Typing the full term every time you wanted to use it would be cumbersome at the least and error prone as well. Using a shorter term means concise communication. Using the terms correctly means precise communication. Every trade has its jargon and those jargon terms were created in order to ensure that two people communicating about a topic could do so in the most precise manner possible. I’ve discussed the need for jargon in the past in posts such as Power Words.

 

SendKeys for Office 2010 Revisited

Some time ago, I wrote a post entitled, “SendKeys in VBA.” In that post, I described a problem where the SendKeys example in Listing 5-8 of VBA for Dummies isn’t working as expected. It turns out that a lot of people are having this problem and not just with Excel—the problem seems to happen with other Office products as well. I’ve played with the macro in Listing 5-8 quite a lot and while it does work in Office 2007 SP2, it doesn’t work in Office 2010 as written.

Apparently, this problem isn’t unique to Office 2010 either. I’ve found threads online that indicate that the problem also existed in early versions of Office 2007, but was fixed in SP2 after a lot of people complained. Wandering around the Internet has proven interesting because I’ve found other blog posts that try to fix the problem, but didn’t work on my system for whatever reason. The bottom line is that SendKeys is broken and quite a few people know it.

Since my original post, I’ve tried several experiments, none of which resolve the problem, but some of which serve to highlight the true essence of the problem. For example, I tried to break the code in Listing 5-8 apart into room selection and row processing pieces. Here is the room selection piece:

Sub SelectRooms()
    ' Select the first data cell in the worksheet.
    Range("A5").Select
     
    ' Use SendKeys to select all of the cells in the column.
    VBA.SendKeys "+^{DOWN}", True
End Sub

and here’s the row processing piece:

Sub ProcessRows()
    Dim ActiveRows As Integer   ' Number of active rows.
    Dim Counter As Integer      ' Current row in process.
     
    ' Get the number of rows to process.
    ActiveRows = ActiveWindow.RangeSelection.Rows.Count
     
    ' Reset the cell pointer.
    Range("C5").Select
     
    ' Keep processing the cells until complete.
    For Counter = 5 To ActiveRows + 5
     
        ' Call the Sub created to change a single cell.
        MakeChoice3
         
        ' Move to the next cell.
        Range("C" + CStr(Counter)).Select
    Next
End Sub

If you run these pieces one at a time, the example will work just as it did with earlier versions of Office. However, that means running two separate macros instead of one, which does cut down on the usability of the technique. The SendKeys function appears to perform its task at the end of the macro, whenever the end of the macro occurs. Initially, I thought that calling these two macros in succession might do the trick, so I created this piece of code:

Sub ChangeAllRooms2()
    ' Select the rooms.
    SelectRooms
     
    ' Process the selections.
    ProcessRows
End Sub

Unfortunately, the result is the same as before. The SendKeys function really does appear not to output anything until the macro is finished. However, because I’m a glutton for punishment, I tried a few other things. For example, I thought perhaps that the wait part of the SendKeys call was to blame, so I created a manual wait like this:

Sub WaitForSendKeys(Timeout As Integer)
    ' Create a variable to hold the wait interval.
    Dim WaitTime
     
    ' Set the interval.
    WaitTime = TimeSerial(Hour(Now()), _
                          Minute(Now()), _
                          Second(Now()) + Timeout)
     
    ' Wait for the event to happen.
    Application.Wait WaitTime
End Sub

I then modified the original macro to look like this:

Public Sub ChangeAllRooms3()
    Dim ActiveRows As Integer   ' Number of active rows.
    Dim Counter As Integer      ' Current row in process.
     
    ' Select the first data cell in the worksheet.
    Range("A5").Select
     
    ' Use SendKeys to select all of the cells in the column.
    SendKeys "+^{DOWN}"
     
    ' Add a wait interval.
    WaitForSendKeys 5
     
    ' Get the number of rows to process.
    ActiveRows = ActiveWindow.RangeSelection.Rows.Count
     
    ' Reset the cell pointer.
    Range("C5").Select
     
    ' Keep processing the cells until complete.
    For Counter = 5 To ActiveRows + 5
     
        ' Call the Sub created to change a single cell.
        MakeChoice3
         
        ' Move to the next cell.
        Range("C" + CStr(Counter)).Select
    Next
End Sub

The results are that the macro runs a lot slower, but still doesn’t do the job. The only way that SendKeys works is to have it at the end of the macro. In short, you need to execute the code in Listing 5-8 in two parts in order to make it work as originally described in the book. As an alternative, you can still use the code in my previous post. The fix that seems to work best is not to use SendKeys at all.

Microsoft has been quiet about this whole issue. Nowhere have I found any word from Microsoft on the problem with SendKeys and I doubt there is a fix in the offing. If someone has a suggestion for fixing this problem, I’m all ears. Please contact me at [email protected] with full details of your fix. Make sure you’ve tested your code using Office 2010 on a Vista or Windows 7 system. I’ll be sure to give full credit to anyone who does come up with a fix for this problem.