Need VBA Help with AddTextbox

[david.f.jenkins]

I have two "mysterious" problems concerning my use of VBA-generated
textboxes. I don't know if they're connected or not. Here's the nut
of the code I'm using:

dim tBoxsh as shape

Set tBoxSh =
ActiveWindow.View.slide.Shapes.AddTextbox(msoTextOrientationHorizontal,
-16.375, 120.75, 240!, 60.5!)
tBoxSh.Tags.Add "Type", "EditorComment"
tBoxSh.Select
With tBoxSh
.IncrementTop 0.62

' fill parameters
.Fill.Visible = msoTrue
.Fill.Solid
.Fill.ForeColor.RGB = RGB(255, 255, 0)
.Fill.Transparency = 0#

' line parameters
.Line.Weight = 2#
.Line.Visible = msoTrue
.Line.ForeColor.RGB = RGB(255, 0, 0)
.Line.BackColor.RGB = RGB(255, 255, 255)

' textbox scaling for size
' .ScaleWidth 14.8!, msoFalse, msoScaleFromTopLeft
' .ScaleHeight 1.48!, msoFalse, msoScaleFromTopLeft

Question 1: If I leave the scaling instructions in, AND leave the
cursor in one of the generated text boxes, AND generate a second text
box, it comes out wider than the first one. If I put the insertion
point someplace outside of the first textbox, and then generate a
second one, it comes out the same width as the first. By expanding
the widths in the AddTextBox call and commmenting out the ScaleWidth
statements, this behavior went away.

Question 2: My users report (and I have seen this myself, but very
seldom, and not in the last 6 weeks or so) that occasionally when they
generate one of these text boxes, it ends up on the screen extremely
wide and narrow - extending way, way beyond the right side of the
slide. This is not a freely reproducible phenomenon - anybody know
what's going on there?

 

[Bill Dilworth]

A few things jump to mind.

1) Try not to program using the selection functions. It can cause some
issues and is usually not required.
2) Why are you scaling the textbox?
Why are you scaling it by different proportions (vertically @
1.48 and horizontally @ 14.8)?
3) Why the IncrementTop line? You have control over the creation of
this object, so why modify it so soon afer creation? Just create it the way
you want.

By changing the code to avoid the selection (except in determining the slide
the user is editing), you can directly address ...
... the text box size in the add textbox line
... the font size (shown in the code below)
... so why the scaling?

By any chance, were the text boxes that behaved differently in presentations
with default shapes set to a locked aspect ratio?

Sub Jenkins()

With ActivePresentation.Slides _
(ActiveWindow.Selection.SlideRange(1).SlideIndex) _
.Shapes.AddTextbox _
(Orientation:=msoTextOrientationHorizontal, _
Left:=-16.375, Top:=120.75, _
Width:=240, Height:=60.5)

'Add tag
.Tags.Add "Type", "EditorComment"

' fill parameters
.Fill.Visible = msoTrue
.Fill.Solid
.Fill.ForeColor.RGB = RGB(255, 255, 0)
.Fill.Transparency = 0#

' line parameters
.Line.Weight = 2#
.Line.Visible = msoTrue
.Line.ForeColor.RGB = RGB(255, 0, 0)
.Line.BackColor.RGB = RGB(255, 255, 255)

'Text & font size
With .TextFrame.TextRange
.Text = "This is my text box"
.Font.Size = 24
.Font.Italic = True
End With

End With

End Sub

 

[david.f.jenkins]

A few things jump to mind.

1) Try not to program using the selection functions. It can cause some
issues and is usually not required.
2) Why are you scaling the textbox?
Why are you scaling it by different proportions (vertically @
1.48 and horizontally @ 14.8)?
3) Why the IncrementTop line? You have control over the creation of
this object, so why modify it so soon afer creation? Just create it the way
you want.

By changing the code to avoid the selection (except in determining the slide
the user is editing), you can directly address ...
... the text box size in the add textbox line
... the font size (shown in the code below)
... so why the scaling?

By any chance, were the text boxes that behaved differently in presentations
with default shapes set to a locked aspect ratio?

SubJenkins()

With ActivePresentation.Slides _
(ActiveWindow.Selection.SlideRange(1).SlideIndex) _
.Shapes.AddTextbox_
(Orientation:=msoTextOrientationHorizontal, _
Left:=-16.375, Top:=120.75, _
Width:=240, Height:=60.5)

'Add tag
.Tags.Add "Type", "EditorComment"

' fill parameters
.Fill.Visible = msoTrue
.Fill.Solid
.Fill.ForeColor.RGB = RGB(255, 255, 0)
.Fill.Transparency = 0#

' line parameters
.Line.Weight = 2#
.Line.Visible = msoTrue
.Line.ForeColor.RGB = RGB(255, 0, 0)
.Line.BackColor.RGB = RGB(255, 255, 255)

'Text & font size
With .TextFrame.TextRange
.Text = "This is my text box"
.Font.Size = 24
.Font.Italic = True
End With

End With

End Sub





- Show quoted text -

Thanks for the tips and help Bill.

I no longer use the scaling, in favor of setting the height and width
when creating the textbox. However, when it *was* there, I noted the
phenomenon of different box widths. Any idea what caused that?

I can't remember now why I selected the textbox. It might have been
because I was having problems showing getting the cursor/insertion
point into the box? But I'll certainly remove the selection, if
that's a possible cause of potential problems.

Likewise, I can't remember why I put in the IncrementTop. It's been
in there since day one, and once things were working I didn't go back
and revise/simplufy the code. I will now, though.

I don't know if anyone is using locked aspect ratios. Isn't that
option set for individual shapes? Where is the global default for
locking aspect ratios set?

Once again, thanks for the pointers!

 

[Steve Rindsberg]

I don't know if anyone is using locked aspect ratios. Isn't that
option set for individual shapes? Where is the global default for
locking aspect ratios set?

It could be set as part of the shape defaults for a given presentation, which
might account for why it appears seldom and unpredictably.

Best bet, I think, would be to set it explicitly to what you want (ie, OFF).
With it on, any change to the height will change the width proportionally, then
changes to the width will change the height. Hair falls out.

 

[david.f.jenkins]

It could be set as part of the shape defaults for a given presentation, which
might account for why it appears seldom and unpredictably.

Best bet, I think, would be to set it explicitly to what you want (ie, OFF).
With it on, any change to the height will change the width proportionally, then
changes to the width will change the height. Hair falls out.

-----------------------------------------
Steve Rindsberg, PPT MVP
PPT FAQ: www.pptfaq.com
PPTools: www.pptools.com
================================================

Hi Steve:

Where does one set the default shape attributes for a given pres?

Alos: when this "streteched" textbox problem occurs, users (and I,
myslef, when I've seen it) will normally execute the same macro again,
and the textbox will show as it should. This is a very sporadic thing
and it's very hard for users to recollect anything they've been doing
out of the ordinary that would trigger it. IN the meantime, I've
cleaned up the code somewhat, following BIll's recommendations, and
we'll see if that makes the problem go away.

But, dammit, I hate mysteries! Even if it goes away, I'd like to know
the real cause ...

 

[Steve Rindsberg]

Hi Steve:

Where does one set the default shape attributes for a given pres?

Draw a shape, format it to taste, then right click and choose Set as Default.
This is where Echo normally pops up to remind you to first set the defaults for
text and THEN do the default shape thing. And she's right.

But rather than rely on the defaults for the presentation or on changing them and
annoying the troops, do it to your shapes as you draw them.

oSh.LockAspectRatio = msoFalse

 

[Echo S]

This is where Echo normally pops up to remind you to first set the
defaults for
text and THEN do the default shape thing. And she's right.

heh. only when I don't skip the VBA threads.

 

[david.f.jenkins]

Draw a shape, format it to taste, then right click and choose Set as Default.
This is where Echo normally pops up to remind you to first set the defaults for
text and THEN do the default shape thing. And she's right.

But rather than rely on the defaults for the presentation or on changing them and
annoying the troops, do it to your shapes as you draw them.

oSh.LockAspectRatio = msoFalse

How does LockAspectRatio play against:

..AutoSize = ppAutoSizeShapeToFitText

?

[snip]

 

[Steve Rindsberg]

[snippidydoodahsnippidiyey]

How does LockAspectRatio play against:

..AutoSize = ppAutoSizeShapeToFitText

Seems that if you're doing things manually, .AutoSize to fit text wins.
That is, even with aspect locked, changing the text makes the shape change ratio.

But if in code you change the size, it turns .AutoSize off.

Is that the world spinning or it it just your head?

 

[david.f.jenkins]

[snippidydoodahsnippidiyey]

How does LockAspectRatio play against:

..AutoSize = ppAutoSizeShapeToFitText

Seems that if you're doing things manually, .AutoSize to fit text wins.
That is, even with aspect locked, changing the text makes the shape change ratio.

But if in code you change the size, it turns .AutoSize off.

Is that the world spinning or it it just your head?

'Tis my head for sure.

Here's something interesting: one of my users who has had this phantom
textbox (infinitely wide, zero height) show up more than once, was
doing some searching on the web and found someone else who was
experiencing the same problem! She's going to try to find that site
again - I'd like to get in touch with that poster and compare notes on
what we're each doing. That might turn up something useful - who
knows. Sure wish I could duplicate the problme at will ...

I'm still very goosy about the fact that two identical calls to
AddTextBox with hardcoded dimensions resulted in different size boxes
depending on whether the insertion bar was in a previous box or not.
That indicates to me that the sizing of added textboxes is whimsical,
at least, under certain undefined circumstances. Doesn't give one
that nice, warm feeling about the steadfastness of the AddTextBox
method operations.

Nitey-nite.

 

[david.f.jenkins]

[snippidydoodahsnippidiyey]

[more snippage]

Getting much closer to the root cause, I think, Steve. Here's what we
found out this AM: when the problem occurs, the text box I've added
has "inherited" ruler first and left margins that appear to come in
from left field. (Actually, they happen to be the level 3 ruler
settings that are in the slide master. ???) I notice that if I insert
a text box from the PowerPoint menus, then the ruler margins are
automatically set at the slide master level 1 values.

Now, here's where it gets gummier: On a "good" file, if I insert a
textbox from the PPT menu, the first and left margins are set to 0 and
0. If I insert a textbox with my code, they also default to 0,0.

I think the nut of this is: on a "bad" file, what's causing it to
default the ruler first and left margins to values other than 0, 0?

Any of this ring any bells?

 

[Steve Rindsberg]

[snippidydoodahsnippidiyey]

[more snippage]

Getting much closer to the root cause, I think, Steve. Here's what we
found out this AM: when the problem occurs, the text box I've added
has "inherited" ruler first and left margins that appear to come in
from left field. (Actually, they happen to be the level 3 ruler
settings that are in the slide master. ???) I notice that if I insert
a text box from the PowerPoint menus, then the ruler margins are
automatically set at the slide master level 1 values.

Now, here's where it gets gummier: On a "good" file, if I insert a
textbox from the PPT menu, the first and left margins are set to 0 and
0. If I insert a textbox with my code, they also default to 0,0.

I think the nut of this is: on a "bad" file, what's causing it to
default the ruler first and left margins to values other than 0, 0?

Any of this ring any bells?

Sometimes files/objects in files can get corrupted; not enough to crash PPT but
enough to induce oddities like this.

Sometimes copying the affected shape to the clipboard then pasting it back
fixes it. In other cases you may have to delete and recreate the slide.

Roundtripping to HTML is another way to attempt repairs.
HTML "Round-tripping" to repair corruption
http://www.pptfaq.com/FAQ00526.htm