Can't change shape text size

[wapperdude]

Yes.  Confirmed.  But, it's actually worse...

With just TxtHeight:
1) cannot resize, period
2) cannot move text box
3) can use rotation handle to rotate.

If add "/1":  similar bad behavior (no quotes)
If "/2":  still cannot resize, but, can move.

Definitely a BUG.

[rezingg]

textheight just defines a box...nothing to do with text size.

for that, use the fontsize cell in shapesheet.

For kicks...make a box shape...add text....change text size on home menu....text changes box stays the same

@Vojo, this relates to the issue OP has observed, not being able to resize the text block with the text block tool. Has nothing to do with text size (subject line is a bit misleading). See detailed description I added to replicated the issue.

[vojo]

I guess I am missing the ask
- cant even see a text box
- cant even format it.
So all it will do is force wrap

If the goal here is a box that visible and formattable, then use a shape (rectangle?) and do a group and set:
- group shape to 1D
- disable selection box
- set line to intercept the handles
- Protection ==>VTX = 1
- Protection ==> height = 1

Result will be a line or connector with a box attached for text et al that behaves like a 1D connector.

or

make this
- take a connector
- add a connection point where you want to anchor the text box
- make a rectangle
- in rectangle text box
   - pinx = guard(connector pinx + or - some offset)           // E.g pinx = guard(conn.pinx - width *0.35)
   - piny = guard(connector piny + or - some offset)
           or
   - pinx = guard(connector pinx)
   - piny = guard (connector piny)
   - locpinx = width *1.2
   - locpiny = height *0.3

play around as needed

[vojo]

or attached

[rezingg]

@vojo, thanks for your effort to find a solution.
However, I'm not really looking for a solution. I found this thread because the OP had the same issue as I had (a shape with a text block that can't be resized interactively using the text block tool). I found what causes this issue (confirmed by wapperdude to be a BUG) and published my findings, so the next person who comes to this thread has a hint what may be causing the unexpected behavior and how to fix it.
The issue is that Visio somehow parses "SomeVariable" different than "SomeVariable*1". I'm not sure if this is a wider spread phenomenon or if it is limited to this one corner case, i.e. the TxtLocPinY cell.
If you don't edit (need to control) the size or location of a shape's text block you are not going to run into this issue.

[wapperdude]

@Vojo:  just follow the steps in Reply #14.

@Anyone:
It seems the TxtLocPinY cell is unique... 
  >It seems to only accept the TxtHeight cell as a reference entry.
  >It objects to the lack of a numeric multiplier
  >It objects to using division rather than multiplication to "scale" the entry.

Whereas, the TxtLocPinX does not exhibit such behavior.  It accepts
  >Formulas that use either multiplication or division
  >It accepts references to other shapesheet cells, e.g., Width, as part of the formula.

The TxtLocPinY must be treated with extreme care.  This is either by design (WHY?) or a bug. 

Has anyone tried this out with earlier versions of Visio?

[rezingg]

@ wapperdude
I was able to refer to a user cell, as long as it has the format <UserVariable>*<Number>.
Also, a straight number causes the same issue as well.

[Croc]

This is either by design (WHY?) or a bug.

Perhaps this is not a bug, but simply an under-documented property.
The fact is that when a mouse drags a text block, the formulas in the TxtHeight, TxtWidth cells do not take an absolute value, but are converting to the form Width*a, Height*b. That is, the coordinates of the mouse on the go are converted into a multiplier value. Therefore, to avoid the effect of racing or complex calculations, developers could impose a restriction on the formulas TxtLocPinX, TxtLocPinY, so that they too could have a similar form (namely, TxtWidth*a, TxtHeight*b).
This requirement seems reasonable. The only bad thing is that the developers forgot to tell everyone else about it.
Visio 2007 behaves similarly.

[rezingg]

The fact that TxtLocPinX behaves differently seems to point towards BUG rather than FEATURE.
Also, in my limited experience with Visio, I found that an interactive edit of a shape usually replaces whatever content an affected cell has with the default formula with some scale factor. In this case, when the user resizes the text block I would expect Visio to replace the content of TxtLocPinY with TxtHeight*X.
There are some exceptions, such as GUARD() and a class of functions which will not be replaced, but possibly their parameters edited, which is not the case here.

[Machine]

it appears interactive text block resizing only works if the TxtLocPinY cell content has the format <SomeVariable>*<number>. Any other cell content causes issues, including a number by itself or multiplied by another number.

It works exactly as described (in 1907).
Is this an intended behavior?