VBA - PPT equivalent of "thisworkbook" in Excel?

[Gregg]

Hello, again.

I have this code below that successfully deletes a certain VBE module
within the file. But, I'd feel more comfortable if I could replace
"activepresentation" with what we use in Excel as "thisworkbook".
That's an object that is the file where the current macro code is
running. "activepresentation" leaves me open to error in the case
another presentation is active when this code is ran. It will misfire,
looking for the module in that file, not the host file. I want it to
look within the file running the code (like "thispresentation") but
don't know the object.

Sub RemoveModule()
Dim vbcompX As VBComponent
Set vbcompX = ActivePresentation.VBProject. _
VBComponents("TempMacros")
ActivePresentation.VBProject.VBComponents.Remove vbcompX
End Sub

Is there such a rascal?

Thanks,
Gregg

 

[Steve Rindsberg]

Hello, again.

I have this code below that successfully deletes a certain VBE module
within the file. But, I'd feel more comfortable if I could replace
"activepresentation" with what we use in Excel as "thisworkbook".
That's an object that is the file where the current macro code is
running. "activepresentation" leaves me open to error in the case
another presentation is active when this code is ran. It will misfire,
looking for the module in that file, not the host file. I want it to
look within the file running the code (like "thispresentation") but
don't know the object.

Sub RemoveModule()
Dim vbcompX As VBComponent
Set vbcompX = ActivePresentation.VBProject. _
VBComponents("TempMacros")
ActivePresentation.VBProject.VBComponents.Remove vbcompX
End Sub

Is there such a rascal?

No, but you can do something like:

Public Const MyName as String = "NameOfYourPresentation.PPT"

Then do whatever you want with
Application.Presentations(MyName).Whatever.Whenever.Whoever

 

[Gregg]

No, but you can do something like:

Public Const MyName as String = "NameOfYourPresentation.PPT"

Then do whatever you want with
Application.Presentations(MyName).Whatever.Whenever.Whoever

Therein lies my challenge. I won't know the name of the presentation.
The routine will be included in a "template" where the user can hit
this macro at any time and after naming thier file anything to
eliminate the macros before sending the prez to a client.

Any other thoughts, or should I stop banging my head? I may have to
resort to good instructions that this must be the ACTIVE file when
running the macro.

Wait. Is there a way to capture the current name of the file running
the macro? I might be able to incorporate that in as a check.

 

[Steve Rindsberg]

Therein lies my challenge. I won't know the name of the presentation.

The routine will be included in a "template" where the user can hit
this macro at any time and after naming thier file anything to
eliminate the macros before sending the prez to a client.

So the user's working in a presentation based on a template containing code.
The presentation they're working in has inherited the code from the template
and that's what you want to get rid of when they trigger a macro?

How will they trigger the macro?

 

[Gregg]

How will they trigger the macro?

 

[Howard Kaikow]

Why?

When you run code, you know the ActiveProject.
So just delete the code in the ActiveProject.

 

[Steve Rindsberg]

The default then would be to run the macro from the active presentation, as I
recall. That might leave you in the interesting situation of having the macro
try to eat its own tail, remove itself while it's running. That'd make me a
bit nervous. <g>

Have you considered giving them an addin with a toolbar or menu item they can
click to work on the active presentation only? Or an add-in that includes the
functions you're currently putting in the template so theres no need for code
in the template?

 

[Austin Myers]

Just food for thought,

I've ran into simular problems before and my *solution* is to force the user
to name and save the file BEFORE allowing the macro to run. Capturing the
name at that point is easy.



Austin Myers
MS PowerPoint MVP Team

Solutions to Multimedia in PowerPoint www.pfcmedia.com

 

[Gregg]

I've ran into simular problems before and my *solution* is to force the user
to name and save the file BEFORE allowing the macro to run. Capturing the
name at that point is easy.

Thanks, Austin. And I think I can run with that, but with a question
maybe.

Can you give me a pointer on what code or object captures the file's
name running the macro? I know I can get it through activepresentation
if it happens to be the active file. But what if the user has two files
open, and he runs the macro while the other file is active? What code
will capture the name of the file actually running the macro?

Ya know, maybe I need to be careful what I wish for. Maybe I should
force them to have the target file be the active file for safety
reasons. See, it could be that the two files open are both built from
the same template and therefore host the same VBE module name that this
macro terminates. It could be confusing to rely on VBA to decide which
file then gets its code nuked.

I think, when the macro runs, I'll let it toast the active
presentation's module. But I'll use activepresentation.name to capture
the active file's name, and then display a user warning showing the
file's name with Yes/No buttons. That way the decision is on him.

How does that sound?

 

[Austin Myers]

Thanks, Austin. And I think I can run with that, but with a question
maybe.

Can you give me a pointer on what code or object captures the file's
name running the macro? I know I can get it through activepresentation
if it happens to be the active file.

Doesn't really matter does it? If the macro is being fired in the
presentation then that's the one to act on right?

 

[Gregg]

Doesn't really matter does it? If the macro is being fired in the
presentation then that's the one to act on right?

No, it could be a problem... if I continued with that strategy.

The macro could be fired while the user is in a different presentation.
He has Prez_A open and Prez_B open. Prez_A hosts the macro, but he
inadvertently activated Prez_B. He goes to Tools | Macro | Macros to
see the list of macros. There he changes to All Open Presentations and
sees the NukeMacros macro. He runs it, which obviously ends with a
runtime error because it runs the macro on the active file, not the
host file.

I have changed strategy, where this is no longer an issue. But it
remains a question of technical possibility. In the future I may want
to call (or call back) to the host file of a macro and would like to
know if it can be done as easliy in PPT as we can do in Excel with
"thisworkbook".

It seems from all the comments, there is no equivalent property in PPT.
Instead, the host would have to have a known name or captured by it
being first activated.

 

[Howard Kaikow]

u do not need a name.

when the macro starts, assign the active presentation to a presentation
object and refer to the presentaton via that object.

 

[Howard Kaikow]

the way to habdle that is to use presentation objects to keep track of
things.
if the active presentation changes, you can detect this by comparing the
activepresentation object with the object you are using to work with
whatever presentation. remember user's can rename things on the fly, an
object reference is the only safe way to do the deed.

i've not tried powerpoint's events, but there might be events that can be
used, such as as word's documentbeforecloseevent.

 

[Gregg]

the way to habdle that is to use presentation objects to keep track of
things.
if the active presentation changes, you can detect this by comparing the
activepresentation object with the object you are using to work with
whatever presentation. remember user's can rename things on the fly, an
object reference is the only safe way to do the deed.

i've not tried powerpoint's events, but there might be events that can be
used, such as as word's documentbeforecloseevent.

Yeah, there are several other strategies I could take, but the core
fact remains there is no PPT equivalent to "thisworkbook", which is an
Excel property that returns the object that hosted the called running
macro. It makes programming simpler when such a reference is needed.

 

[Gregg]

u do not need a name.

when the macro starts, assign the active presentation to a presentation
object and refer to the presentaton via that object.

Won't work. In the scenario, the running macro needs the name of the
OTHER file, not the active file. It needs the file object of the file
that is running the macro, not the file that happens to be active.

Again, Excel has a property called, thisworkbook, so that no matter
what file is active or how the macro was triggered, or where in the
running of the macro it was as it opened, closed, and switched files,
it always knew the name of the file it was running from... even if
another file was active when it was triggered. PPT doesn't have such a
property.

 

[Steve Rindsberg]

Won't work. In the scenario, the running macro needs the name of the
OTHER file, not the active file. It needs the file object of the file
that is running the macro, not the file that happens to be active.

Again, Excel has a property called, thisworkbook, so that no matter
what file is active or how the macro was triggered, or where in the
running of the macro it was as it opened, closed, and switched files,
it always knew the name of the file it was running from... even if
another file was active when it was triggered. PPT doesn't have such a
property.

ActivePresentation.VBProject.Filename would appear to be the key.
Alas, the door that it opens leads to a hall of mirrors.
It seems to return the full path to the active presentation, regardless of what
the docs say.

 

[Howard Kaikow]

as soon as the macro is run, you can save the activepresentation in a
presentation object.

 

[Gregg]

as soon as the macro is run, you can save the activepresentation in a
presentation object.

Sorry, man. I don't get what you mean. What help would that be to find
the name of the file running the macro when other files are open and
the active file is not the file running the macro?

 

[Gregg]

ActivePresentation.VBProject.Filename would appear to be the key.
Alas, the door that it opens leads to a hall of mirrors.
It seems to return the full path to the active presentation, regardless of what
the docs say.

You know I had to try it myself even though you warned it plain don't
work. And, yep, I got the same thing. For all that, it just gave me
info on the active file.

Oh, well. You guys have done enough work on this. Thanks. I have my
answer, which tells me to simply strategize without the aid of
thisworkbook mentality.

<Cajun man in background shouting, "You can dew eet!">

-Gregg

 

[Howard Kaikow]

If all you want to do is remove code in the ActiveVBProject, them all you
need to know is the ActiveVBProject.
You can get the filename fron the ActiveVBProject.

Debug.Print Application.VBE.ActiveVBProject.FileName

If you want to know the name of the file that called the macro, then you
need to include code that gets the ActivePresentation object as soon as the
macro starts, and save that info for later use by the macro,

Debug.Print ActivePresentation.FullName

Also, while the macro is running, you can check for the cirrent
ActivePresentation,

However, in no case do you need the actual name to be saved,
You need only to save the objects.
Otherwise, if allowed by your code, the user might rename a presentation on
the fly.