Field calculations

[Paul Herber]

and another ...
Insert a field into shape and do some calculations using width and height and the numbers are horrible ...
The field I've added is:
="width = "&Width&" Height = "&Height&" area = "&Width*Height

Width and Height should be 50mm.

[wapperdude]

Hi Paul...
When I tried your custom formula, I didn't get the line feeds.  I had to use this:
"Width = "&Width&CHAR(10)&"Height = "&Height&CHAR(10)&"Area = "&Width*Height

This gave me both correct format (3 lines) and correct values.  However, there's a different method I normally use.  First, I enter three lines, normal text: 
Width =
Height =
Area =

Then, I go back, and at end of each line Field Insert the desired field.  I don't have to remember any of the ASCI hand-jive codes to get a working formula.

[Paul Herber]

Hi Wayne, the line feeds are just where the text wraps, purely fortuitous.
I think it does work correctly in inch formatted shapes but not with mm.

[wapperdude]

I don't work well with "mm" either.

[Thomas Winkel]

Yeah, annoying. Visio calculates internally in inches. Rounding errors occur when processing in metric units. You can use  ShapeSheet formulas ROUND() or FORMAT() to cover this.
I think these days no software should use inches internally. Only for input and output, if required.
We had this problem by calculation xy positions. Barely to see on the shapes, but causing little steps on connections depending on zoom level.

[wapperdude]

While I agree there may be conversion errors due to rounding, an inevitable issue, I don't think it's necessarily the root of the issue here. 

In the example Visio file I provided in response, there are two shapes.  One shape uses technique Paul used, and the other uses technique I described.  I use, what's the term, Imperial , English., units throughout.  So, no conversion errors.  I also have snap to grid enabled with highest priority.  In the first shape, which shows much higher numeric resolution, the values are not what I would expect.  There are some internal errors.  Very, very small.  Not visible to the eye.  Could be graphic resolution, could be bit/numeric resolution, floating point, whatever.  But, if this is the root, best resolution, it implies that results from conversion process cannot be any better.  However, it does also state that the conversion ought to be as accurate, and still not visible.  The greatest issue is probably screen resolution vs zoom level as established by "pixel" limitations.

[wapperdude]

...add info:
In the "Pauline" shape, it is possible by manually entering values, to define width and height more "precisely".  That is, initially the SnP displayed values are rounded versions based upon graphic placement. By manually entering, precision may be imparted to size and placements.  Although, the numeric results will appear visibly unchanged in the SnP Window entries.  But, if you look at the shape, itself, the entries are precisely shown, and the mathematics works out exactly.  This applies to the metric world also.

This seems to support that the error is more zoom/pixel related than a conversion error.  As Visio is numerically/mathematically limited by machine precision, I would think either 32 bit, and certainly 64 bit, machines (and Visio, by extension) are sufficiently precise.


Edit update
...and, Yes, Paul, entering values in SnP window will correct your "error". 

 

[wapperdude]

Not quite done...
A disadvantage of the custom formula approach presented, is the in the Field Text section that gets created, the formula is a single line entry.  This defeats the functionality of specifying the Fieldpicture(xxx) value.  Whereas, the somewhat more painful way that I show, creates a separate line entry for each field insert and preserves that functionality.  For the record, John Marshall tabulated what the various values do, and I present:

0 visFmtNumGenNoUnits
1 visFmtNumGenDefUnits
2 visFmt0PlNoUnits
3 visFmt0PlDefUnits
4 visFmt1PlNoUnits
5 visFmt1PlDefUnits
6 visFmt2PlNoUnits
7 visFmt2PlDefUnits
8 visFmt3PlNoUnits
9 visFmt3PlDefUnits
10 visFmtFeetAndInches
11 visFmtRadians
12 visFmtDegrees
13 visFmtFeetAndInches1Pl
14 visFmtFeetAndInches2Pl
15 visFmtFraction1PlNoUnits
16 visFmtFraction1PlDefUnits
17 visFmtFraction2PlNoUnits
18 visFmtFraction2PlDefUnits
20 visFmtDateShort
21 visFmtDateLong
22 visFmtDateMDYY
23 visFmtDateMMDDYY
24 visFmtDateMmmDYYYY
25 visFmtDateMmmmDYYYY
26 visFmtDateDMYY
27 visFmtDateDDMMYY
28 visFmtDateDMMMYYYY
29 visFmtDateDMMMMYYYY
30 visFmtTimeGen
31 visFmtTimeHMM
32 visFmtTimeHHMM
33 visFmtTimeHMM24
34 visFmtTimeHHMM24
35 visFmtTimeHMMAMPM
36 visFmtTimeHHMMAMPM
37 visFmtStrNormal
38 visFmtStrLower
39 visFmtStrUpper
44 visFmtDateyyyymd
45 visFmtDateyymmdd
46 visFmtTimeAMPMhmm_J
50 visFmtDateTWNfYYYYMMDDD_C
51 visFmtDateTWNsYYYYMMDDD_C
52 visFmtDateTWNfyyyymmddww_C
53 visFmtDateTWNfyyyymmdd_C
54 visFmtDategggemdww_J
55 visFmtDateyyyymdww_J
56 visFmtDategggemd_J
57 visFmtDateyyyymd_J
58 visFmtDateYYYYMMMDDDWWW_C
59 visFmtDateYYYYMMMDDD_C
60 visFmtDategeMMMMddddww_K
61 visFmtDateyyyymdww_K
62 visFmtDategeMMMMddd_K
63 visFmtDateyyyymd_K
64 visFmtDateyyyy_m_d
65 visFmtDateyy_mm_dd
66 visFmtTimeAMPMhmm_C
67 visFmtTimeAMPMhmm_K
68 visFmtTimeAMPM_hmm_J
69 visFmtTimehmm_J
70 visFmtTimeAMPM_hmm_C
71 visFmtTimehmm_C
72 visFmtTimeAMPM_hmm_K
73 visFmtTimehmm_K
74 visFmtTimeHMMAMPM_E
75 visFmtTimeHHMMAMPM_E
76 visFmtDateyyyymd_S
77 visFmtDateyyyymmdd_S
78 visFmtDatewwyyyymmdd_S
79 visFmtDatewwyyyymd_S
80 visFmtTimeAMPMhmm_S
81 visFmtTimeAMPMhhmm_S
200 visFmtMsoDateShort
201 visFmtMsoDateLongDay
202 visFmtMsoDateLong
203 visFmtMsoDateShortAlt
204 visFmtMsoDateISO
205 visFmtMsoDateShortMon
206 visFmtMsoDateShortSlash
207 visFmtMsoDateShortAbb
208 visFmtMsoDateEnglish
209 visFmtMsoDateMonthYr
210 visFmtMsoDateMon_Yr
211 visFmtMsoTimeDatePM
212 visFmtMsoTimeDateSecPM
213 visFmtMsoTimePM
214 visFmtMsoTimeSecPM
215 visFmtMsoTime24
216 visFmtMsoTimeSec24
217 visFmtMsoFEExtra1
218 visFmtMsoFEExtra2
219 visFmtMsoFEExtra3
220 visFmtMsoFEExtra4
221 visFmtMsoFEExtra5
John... Visio MVP