New month, new topic – for the moment, at least. Forums are such a wonderful source of topics to write about… Today’s comes from a question in the Office 2013 Preview for Developers forum on MSDN.

In Word 2010 the Backstage was introduced with the purpose of providing management functionality for Office documents. The Backstage provides a large, for the developer customizable surface to interact with the user. Another reason for this move was to provide the same “experience” for the users of all the Office applications when using basic file management functionality.

As always, when something is “harmonized”, individuality is lost. We’ve experienced that since the first attempts at giving the Office applications a unified interface and the trend continues.

From the Word perspective, the first loss due to the Backstage was in Word 2010 when the FilePrint command was moved to the new interface. Now, in Word 2013 it’s the FileSaveAs command that’s being affected.

Experienced Word developers know that, since the first version of WinWord, you can name a Public Sub (a macro) with the same name as a that of a built-in command. That macro then takes over the job of the built-in functionality. So FilePrint would supplant Word’s built-in printing; FileSaveAs would supplant the built-in saving to a new file name or format.

With the transfer of control to the Backstage, these macros now only trigger when Ribbon buttons or keyboard shortcuts for the repurposed commands are pressed. They don’t trigger when the user accesses the functionality via the Backstage.

So what’s the answer? Can we control what happens when the user saves a document to a new name, location or file format?

 Yes, there are two possible approaches available:
  1. Create your own Backstage tab in the Ribbon XML and hide/disable the built-in one.
  2. Work with the events for the functionality. In this case, the DocumentBeforePrint and DocumentBeforeSave events.

Since many who work with VBA are still unfamiliar with using events, here’s a small example to illustrate the approach for DocumentBeforeSave.

You should first review the information in the following Help topic: Using Events with the Application Object. More information on the DocumentBeforeSave event can be found here. This will help you follow the construction used in the code that follows.
Private Sub wd_DocumentBeforeSave(ByVal Doc As Document, _
                 SaveAsUI As Boolean, Cancel As Boolean)
    Dim FileName As String, FileFormat As Long
    Dim userChoice
    
    'Should only trigger on the document the user is working with
    'And not, for example, when saving Normal.dotm in the VBA editor
    If Doc Is ActiveDocument Then
        Debug.Print Doc.FullName     'Just to see what the default values
        Debug.Print SaveAsUI, Cancel 'of the event arguments are...
        SaveAsUI = True              'Make sure Save As dialog box is displayed
        Cancel = True                'But don't let Word perform the SaveAs
        Debug.Print SaveAsUI, Cancel 'Just double-checking the settings...

        'Display the FileSaveAs dialog box, but it won't execute
        With Dialogs(wdDialogFileSaveAs)
            userChoice = .Display    'Capture whether user clicks Save button
            FileName = .Name         'Capture the file name
            FileFormat = .Format     'Capture the selected file format
            Debug.Print FileName, FileFormat, userChoice
        End With
        
        If userChoice = -1 Then      'If the user clicked Save, save the file
            Doc.SaveAs2 FileName:=FileName, FileFormat:=FileFormat
        End If
    End If
End Sub


When the user makes a choice in right-hand column of the Save As tab in Backstage, the built-in Save As dialog box is shown. This will mean that the user won’t get the location he is expecting, based on the selection clicked on in Backstage. For instance, if Skydrive is selected, the Save As dialog box will still default to the standard location, usually My Documents.
Backstage Save As tab with the File/Save As dialog box displayed

You can, of course, substitute your own dialog box for the built-in Save As. In this case, make sure SaveAsUI is set to False rather than True. But there is no way for you to read what the user chose in the built-in Backstage tab. This could be very frustrating for the user and, in this event, you have no choice than to create your own Save As tab for the Backstage and hide/disable the built-in one.
6 Responses to “How the Backstage affects repurposing using Word 2013 VBA”
  1. Aldrin Rasdas says:

    in Word 2013, DocumentBeforeSave is getting executive even if Word is AutoSaving it (see AutoRecover)

    So the user would be surprised why it was asking to save the document even if he/she did not click the “Save” or “Save As” command.

  2. wordmeister says:

    Hi Kay
    No question that Microsoft believes the new “apps” are the wave of the future – time (and sales numbers) will tell. But currently the javascript “apps” cannot even come close to replacing the amount of control the traditional “interop” APIs provide – no matter which programming language you prefer. And you can’t deny it: when manipulating the object model, VBA running in-process is faster than any .NET language running out of process.

    When introduced, classic VB was – compared to programming using the classical “C”-languages – “the” RAD tool. No C-language prior to C# had a RAD-environment. Classic VB was never meant for use by secretaries; WordBasic was; VBA is something in-between.

    FWIW I write and run code in German- and English-language environments and have never had any problems as long as I avoid special characters (Umlauts) in method names. The real language-related obstacle in Office programming are literal strings in the Office application, built-in style names in Word or function names in Excel being the crassest examples. But even worse has been the .NET interface with Excel as that is culture-specific, requiring some really fancy footwork to code across the interface – it doesn’t matter which programming language you’re using.

    The big question in my opinion isn’t whether you program in a VB or a C language, it’s whether you believe in COM or .NET. And it appears that things are headed more back towards open standards (javascript) and COM and away from .NET… Whereever we end up, it has to be better than the Fortran I learned at university back in the 70′s!

  3. Kay says:

    Build a custom backstage view. Or take an action even onto existing views.

    It’d be nice if VBA would just go away. We have C# with VSTA and the new javascript winrt apis. VBA and VB are a remnant of the day when MS thought you could turn secretaries into developers. There’s no need for it and no reason it should stick around when better, more readable, more modern and more universal languages are available.

    Pro-tip: when 2/3rds of your code originates in a non-english speaking country, it’s unlikely the code will be readable if it’s delivered in VB. C-based languages are math-centric and as such are effectively universal.

  4.  
Leave a Reply


Network-wide options by YD - Freelance Wordpress Developer