views:

506

answers:

3

Does anyone know what the future holds for VBA/VSTO programming in PowerPoint? I've been working on a Office automation project and find it frustrating to work with PowerPoint in particular since it seems to be one level below VBA support found in Excel or Word.

It feels like MS is trying to phase out support for VBA in PowerPointsince they dropped macro recording in version 2007 and the object model lacks some key features support.

+3  A: 

Powerpoint has never been a popular platform for VBA development. I can understand dropping UI features for VBA in that context. Tt is very easy to include VBA support for Powerpoint on the strength of Excel and Word - which will not go away soon, if at all. My money will be on legacy support in the long term, with poor to nonexistent assistance from Microsoft for problems.

Remember that MS is all about backward compatibility - and they are very careful when they drop it.

caving
+6  A: 

I'm not sure if this is the answer you want to hear, but development in PowerPoint with VBA is actually good. I do quite a bit of it (as well as Word and Excel) and it is robust enough. The PowerPoint OM that can be programmed against with VBA is updated with each of the new versions of PPT. In PPT 2007, you can create Custom XML against any object on a slide - far more powerful than options available in Excel and Word. In contrast, Word 2007 has Content Controls, which, in order for PPT to be some kind Crystal Reports light-weight replacement, it would benefit from. In PPT 2010 (beta), you can programmatically create SmartArt, for example, as you can with Word/Excel 2010. You can also programmatically work with media elements better than before. VSTO, from an OM perspective, doesn't offer a whole lot more than VBA though.

It may just depend on your needs though - do you create standard bullet slides? Do you do extended animation? Do you do reporting? Are you creating eLearning "apps"? If you have specific questions on the OM, we can try to help you here (but maybe the feature just doesn't exist).

Agreed that removing the macro recorder kind of sucked, that was a useful feature. Directly working with the PML/DML is also a pain. There are things that I wish the OM did support as well. But in concurrence with caving, I don't believe VBA is going away any time soon.


NOTE: THIS DOES NOT WORK. IT IS PROVIDED ONLY AS A STARTING POINT IF FOLKS WANT TO TRY TO DEVELOP THIS INTO SOMETHING THAT MAY WORK (if you can get it to work, please feel free to edit this post).

  1. Create a class called "clsPPTEvents"
  2. Paste in the following code.

    Public WithEvents PPTEvent As Application
    Private Declare Function GetCursorPos Lib "user32" (ByVal lpPoint As POINTAPI) As Long
    Private Type POINTAPI
        x As Long
        y As Long
    End Type
    Dim ret As Long
    Dim mousePosition As POINTAPI
    Private Sub PPTEvent_WindowSelectionChange(ByVal Sel As Selection)
        Dim ElementID As Long
        Dim Arg1 As Long
        Dim Arg2 As Long
        With Sel
            If .Type = ppSelectionShapes Then
                Dim sr As ShapeRange
                sr = .ShapeRange
                If sr.Type = msoChart Then
                    Dim sh As Shape
                    Dim slideNumber As Integer
                    slideNumber = ActiveWindow.View.Slide.SlideIndex
                    sh = ActivePresentation.Slides(slideNumber).Shapes(sr.Name)
                    Dim crt As Chart
                    crt = sh.Chart
                    H = ActiveWindow.Height
                    w = ActiveWindow.Width
                    ret = GetCursorPos(mousePosition)
                    x = mousePosition.x
                    y = mousePosition.y
                    crt.GetChartElement(x, y, ElementID, Arg1, Arg2)
                    MsgBox("X: " & x & ", Y: " & y & vbNewLine & _
                    "ElementID: " & ElementID & ", Arg1: " & Arg1 & ", Arg2: " & Arg2)
                End If
            End If
        End With
    End Sub
    
  3. In a regular module, you can start/stop the event handling with this:

    Public newPPTEvents As New clsPPTEvents
    Sub StartEvents()
        Set newPPTEvents.PPTEvent = Application
    End Sub
    Sub EndEvents()
        Set newPPTEvents.PPTEvent = Nothing
    End Sub
    

Note that in the code in #2, it doesn't work because of what GetCursorPos returns, which is the screen X, Y. In looking at event, it appears that what the GetChartElement wants is either the Window or Pane bounding box's coordinates or just the chart's itself.

Otaku
Thanks for the replies Otaku and caving! In our firm we do alot of presentations with embedded Charts and it has been painful development. 2007 SP2 improved the OM (+) and causes more chart crashing (-) but they still left gaps. Example: you can tell that a user clicked on a chart but you cannot tell what chart element is selected. I have not yet tried this in 2010.
Sam Russo
I've done a bit more checking on this. It appears that while the GetChartElement method is available in PPT, it can't (easily?) be accessed due to the lack of any event that would provide the proper (window, not screen) X,Y coordinates. There are plenty of examples that work well for Excel, but the same ones just don't work in PowerPoint. I've tried toying around with the GetCursorPos API call and WindowSelectionChange event to get the X,Y values, but haven't had much luck. This does seem like a complete oversight by Microsoft to make this method available, but rendered useless in PowerPoint.
Otaku
+1  A: 

I agree PPT is well below other vba. Above all it seems buggy see http://stackoverflow.com/questions/2980650/weird-bug-on-powerpoint-vba

Model event is awkward like no auto execution http://stackoverflow.com/questions/2979950/how-to-automatically-trigger-the-app-object-initialization-in-powerpoint

auto_open is possible only in circumvoluted way by creating an addin what about users who receives your ppt and don't know how to install the plugin :(