VBA - Alternate ways to call code in "PowerPoint Objects"?

[Guest]

I have a VBA project where there are some slides with code in them so that
they are listed in the project window under "Microsoft PowerPoint Objects" as
"Slide7" for example.

I would like to be able to call a sub on Slide7, which I am able to do by
making that sub public:
Public Sub MySubroutine()
And I can call it from any module using the following syntax:
Slide7.MySubroutine

To keep things logical and clear in my code, I have named most of my slides
so that I can refer to them in the following fashion:
ActivePresentation.Slides("MySlide")...

Is there any way I can call MySubroutine using a syntax that includes the
slide's name of "MySlide" rather than use "Slide7.MySubroutine"? I want to
make it clear in my code which slide I am calling the routine from, and
"Slide7" just isn't very helpful since it is not the 7th slide in my
presentation.

 

[David M. Marcovitz]

There might be a better way. I hope so because this is rather convoluted
(and if it were me, I would just put comments in my code rather than
using this backwards method).

You can create an object variable and set it to be Slide7:

Dim myFavoriteSlide As Object

and then some piece of code that gets run before everything else:

Set myFavoriateSlide = Slide7

Then whereever you use Slide7, you can use myFavoriteSlide instead. It
seems pretty ugly to me and doesn't use the name for the slide you have
already set (except to use that name as the variable name in place of
myFavoriteSlide), but it will work if you really want to do this.

--David

--
David M. Marcovitz
Microsoft PowerPoint MVP
Director of Graduate Programs in Educational Technology
Loyola College in Maryland
Author of _Powerful PowerPoint for Educators_
http://www.PowerfulPowerPoint.com/

 

[Guest]

Thanks David,

Your solution is probably the route I will have to go.

This situation hits on my biggest gripe about PowerPoint. You can change
the name of any other kind of module, but for some reason, changing the name
of a slide doesn't change it's "object name" which makes it very difficult to
find things in the project window and makes the code very difficult to handle
gracefully.

My biggest concern is that if I copy this slide to another presentation, I
will have to change my code since it probably won't be "Slide7" in the other
presentation.

Oh well, maybe this will get fixed in PowerPoint 12. (A guy can dream
can't he?)

 

[Steve Rindsberg]

My biggest concern is that if I copy this slide to another presentation, I

will have to change my code since it probably won't be "Slide7" in the other
presentation.

I just tested this. It changes when I paste to a different slide presentation.
You get SlideX where X = ActivePresentation.SlideCount (after the paste). In
other words, if there are 20 slides in the presentation and you copy/paste your
Slide1 into it, it becomes Slide21.

Out of curiosity, why store code in slides?

 

[Guest]

The main reason I want to store code in slides is to keep my application as
object oriented as possible. I want to keep the code that initializes a
particular slide with that slide in case I move it to another presentation.
That way, I only need to add a line to my main routine that is run when the
slide show begins to say something like "MySlide.Initialize". Plus, keeping
code that belongs to a slide in the slide itself just makes things seem much
more organized and easy to find.

I'm beginning to think that I am trying to use VBA for PowerPoint in ways
that Microsoft never intended. In a nutshell, I am using VBA to script some
very complex interactive animations that cannot be done using PowerPoint's
native animation capabilities alone. The animations are used to illustrate
the inner workings of a microcontroller by visually simulating instruction
execution and data movement based on a variety of inputs provided by ActiveX
controls on the slides.

To implement this application in a way that is easy to maintain, I have kept
things very modular and have made good use of VBA's object oriented features.
Storing code that belongs to a slide object inside that object, as if it
were a class module just seems like a logical thing to do. Unfortunately,
Microsoft didn't see it that way.

 

[Steve Rindsberg]

The main reason I want to store code in slides is to keep my application as
object oriented as possible. I want to keep the code that initializes a
particular slide with that slide in case I move it to another presentation.
That way, I only need to add a line to my main routine that is run when the
slide show begins to say something like "MySlide.Initialize". Plus, keeping
code that belongs to a slide in the slide itself just makes things seem much
more organized and easy to find.

OK, understood. But I suspect your conclusion is correct; this maybe isn't what MS
had in mind when they added slides as code containers in the IDE.

I *think* it's possible to automate the IDE itself (after adding a reference to VBA
Extensibility), which would allow you to add code to slides or at least to the
current project from external files or possibly from a central code library in PPT or
maybe PPA format. I wonder if that might help with the problem.

I'm beginning to think that I am trying to use VBA for PowerPoint in ways
that Microsoft never intended. In a nutshell, I am using VBA to script some
very complex interactive animations that cannot be done using PowerPoint's
native animation capabilities alone. The animations are used to illustrate
the inner workings of a microcontroller by visually simulating instruction
execution and data movement based on a variety of inputs provided by ActiveX
controls on the slides.

Sounds seriously interesting. If at all possible, can you post some examples on the
web when you get it working? I know a lot of people would like to see this working.

 

[Guest]

Actually, the problem isn't getting code into the slide. All I have to do is
add an ActiveX control and double click on it once, then once the slide shows
up under the project tree, I can delete the control. Though, most of the
slides that I want to put code into already have controls anyway.

The problem was just the ugliness involved in referencing the slide module
since in the project tree it keeps its "Slide7" object name even though the
slide has been renamed and shows the new name in the properties panel. I
can't for the life of me figure out why Microsoft does this. If I rename the
slide, it should show up in the project tree with my new name. This would
make it much easier to find control event handlers as well as any code I
choose to add there. I really wish I could refer to a routine on a slide
like "MySlide.MySub" rather than going through the process of creating an
object variable and assigning the slide to it first, or just referring to it
as "Slide7.MySub". I guess I am wishing that PowerPoint worked more like
Access, where you have code modules as well as "code behind forms", and you
can freely call public routines in either one - at least that is how I
remember doing it years ago when I programmed data bases for a living. That
might have been before Access Basic morphed into VBA.

Once I get it done, I could certainly post some parts of it as examples if I
can find someone willing to host the files.

 

[Steve Rindsberg]

I guess I am wishing that PowerPoint worked more like

Access, where you have code modules as well as "code behind forms", and you
can freely call public routines in either one -

You can do that in PPT with forms and code modules. I suspect the problem with slides is
that they're in the IDE as a side effect of becoming containers for ActiveX controls. I
don't know that I've heard of anyone using them for any other purpose.

Once I get it done, I could certainly post some parts of it as examples if I
can find someone willing to host the files.

If they're not too big, I'd be happy to, especially if you could do a little writeup on
how they work. I'll put it up on the PPT FAQ at http://www.pptfaq.com