Home > Software engineering >  Why is there XML in the comments of my VBA code?
Why is there XML in the comments of my VBA code?

Time:04-21

I have taken over an old Microsoft Access project which has commented-out XML in several procedures. For example:

'------------------------------------------------------------
' closeManageEmployees_Click
'
'------------------------------------------------------------
Private Sub closeManageEmployees_Click()
On Error GoTo closeManageEmployees_Click_Err

    ' _AXL:<?xml version="1.0" encoding="UTF-16" standalone="no"?>
    ' <UserInterfaceMacro For="OpenNewEmployee" Event="OnClick" xmlns="http://schemas.microsoft.com/office/accessservices/2009/11/application"><Statements><Action Name="OpenForm"><Argument Name="For
    ' _AXL:mName">newEmployee</Argument><Argument Name="DataMode">Add</Argument><Argument Name="WindowMode">Dialog</Argument></Action></Statements></UserInterfaceMacro>
    DoCmd.Close , ""


closeManageEmployees_Click_Exit:
    Exit Sub

closeManageEmployees_Click_Err:
    MsgBox Error$
    Resume closeManageEmployees_Click_Exit

End Sub

Here there are three lines of commented-out XML starting with _AXL. Other than revolving around the same subject of "employees" I don't see any relevance between what the XML is describing and what the routine does. In fact, it looks like this body of code might have even been copy-pasta'd from OpenNewEmployee_Click() which has a similar set of commands and formatting, except it's lacking any XML:

'------------------------------------------------------------
' OpenNewEmployee_Click
'
'------------------------------------------------------------
Private Sub OpenNewEmployee_Click()
On Error GoTo OpenNewEmployee_Click_Err

    DoCmd.OpenForm "newEmployee", acNormal, "", "", acAdd, acDialog


OpenNewEmployee_Click_Exit:
    Exit Sub

OpenNewEmployee_Click_Err:
    MsgBox Error$
    Resume OpenNewEmployee_Click_Exit

End Sub

This kind of formatting is repeated in several forms in this project. Am I correct in guessing the XML is just garbage leftover from a macro that got converted to VBA code?

CodePudding user response:

This is the result of using the the macro conversion to VBA.

Remember, in Access we have two programming languages.

the supposed "easy" to use macro language - designed for non programmers.

then we have VBA (Visual Basic for Applications).

So, when you drop in a button onto a form?

You get two options:

enter image description here

So, if you choose macro builder, then you NOT using VBA anymore, but a macro.

so, you can write rather "simple" operations in that macro language. And it turns out that the macro language is stored as xml. This change occurred in Access 2010 (so, not super old give the 25 year history of access). Prior to Access 2010, macros existed, but they were not stored as xml.

and they added a "nice" if/then block structure to the macro's in 2010, along with a re-vamped macro editor.

so, as a developer, you can (and will) quickly outgrow macros, and thus over time, you want to use and adopt VBA code in place of macros.

So, there is is a option in access to convert these "macros" to VBA, and thus the previous xml code you see was in fact previous macro code. In fact, you can take that xml and cut paste into the macro editor, and you see the code right before your eyes.

You can also in tools setup your button events by default to use VBA - and thus no prompt as per above (to use macro or VBA - it will jump right to VBA code and event).

And one minor downside? The event wizards used to have a option to use VBA, but they always now use XML macro's - even if your event settings are to use VBA.

So, if I cut and paste your xml into the macro editor? You see this:

enter image description here

The built in wizards do now always use macros. But, if you want to extend, or modify say the event code, or button click code? Then use the convert to VBA feature - this one:

enter image description here

Any good reason to use macros?

Well, not really, but ONE big reason?

Access in 2010 received what we call REAL table triggers, and even store procdure code at the table level. That means if you update a table from code, then a data macro (table store code) can run. so, this is at least one reason for learning to use macros. Such table level macro code runs when you update the table - even if you used say vb.net, or FoxPro or any other data source - those table triggers and stored code procedures will run.

But that xml text you see? It is the result of converting from a macro (UI macro in this case) to VBA code.

  • Related