Something I wonder about when using a method like ResultInt.
In the VisUnitCodes enumeration: what is the difference between visNumber and visNoCast?
IMHO "No unit conversion" for any results dimension.
Embellishing Surrogate's reply, the noCast takes whatever units are present and keeps them, as he says, no conversion. While there is very little (none) in way of description, I would deduce that visNumber just grabs the numerical value and is dimensionless. That is, it is still numeric and not a string.
Wayne thanks for the clarification.
I could not formulate the explanation in English... ;)
Brilliant!!!
;). Good teamwork.
I think there is no difference ;D
ResultInt(visNoCast, ...) always returns the same thing as ResultInt(visNumber, ...)
Could someone provide an example where they would differ?
Here's simple test case... unexpected results. Have fun playing with it.
Hmm.. So were you able to find a value that would give different result for ResultInt(visNoCast, ...) and ResultInt(visNumber, ...)? I was not :(
@Nikolay: No. I think I duplicated your results.
I was surprised by this. The text shown in the shape is field inserted from User Section. All entries point to a a single Shapedata value that has value with units. So, the left column is the data using different result enumerations. Then, 1 with resultstr, which includes the units, and the last being a direct shapesheet push into the User cell. The right column is a product of the Shapedata times the corresponding User entry. That was a check to see if the units actually squared. Only in the last 2 user cells was that true.
This seems contrary to what I was expecting. Now sure that this was the case for Visio's past.
When in doubt, search, eh? In this case, Visio Guy to rescue. See this old reply: http://visguy.com/vgforum/index.php?topic=1227.msg5286#msg5286 (http://visguy.com/vgforum/index.php?topic=1227.msg5286#msg5286)
So the light went on! Using the enumerations Visio knows how to handle the fetching of the value. It does not provide the actual units, just interprets the value. The units are implied by the fetching process. The resultstr does include the units, which are included in the calculations using the string.
That means the results can be misleading. In my test case, all of the values are identical. If my Shapedata was metric, but drawing is not, I would expect some value variations. The major confusion is in the right column. All the values are correct, but the 1st 3 entries on the left are treated as dimensionless, so the resultant units "appear" to be wrong!
To followup, here's test with shapedata using cm not inches. A bit of variation and consistency at the same time.
Note, in both test files, there is a small macro to place the various enumeration results into user cells
A week ago, I wrote an article for my client: Copy Line Format and Fill Format sections (https://gist-github-com.translate.goog/Surrogate-TM/5732089fb8988a3823dfbad39948874f?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=ru&_x_tr_pto=wapp).
This article contain code, which iterate each cell in sections.
(https://user-images.githubusercontent.com/35092915/261931415-b3b5285b-cb5a-4a92-acde-0167ee51bf36.png)
Values in these cells have different dimensions: pt/mm/%/integer values/RGB-values!
formula = CStr(shS.CellsSRC(visSectionObject, RC, ij).ResultStr(visNoCast))
I use code for get different values from cells.
Using resultstr seems to work well. Using result, as mentioned, actually gives an undimensioned number.
So my drawing is in English units (or whatever they're called => inches). Thus no conversion issue. But, if I make the "source" number, i.e., the shapedata value, to be 3.125cm, and then do all the result translations, they all seem to do a conversion. Resultstr doesn't have issue because it is a "literal" translation. See attached example.
Thank you all for looking in to this, there is actually a lot to how the .Result(Str) methods function.
I have gotten some surprising results including a shape ID of say 21 (stored in a User cell) suddenly being converted to the number 21000! (when using a mix of Result(Str) and .NET conversions from string to integer). Sometimes surprising things happen with these methods.
...all from a seemingly simple question! Definitely learned new things thru this.