Yes, it does work this way because the Volume function outputs a number. As long as the output of the function is a number adding or multiplying works fine. (eg. Volume, Area, CurveLength)
The drawback of using the Volume function directly is that the lengthy ID code is needed. And when this same quantity shows up in different places it becomes less convenient to deal with the ID code or individually select the object each time I need to refer to it.
Initially, I wanted to have all the area and volume quantities saved in a single place (for example DocumentUserText). Ideally I would retrieve those values, not as strings, but as floats using float(). This way I can add them together to print the sum of the areas or volumes.
If I could substitute the ID code “1138c632-5107-432e-8ea3-9633245317e7” by something more human readable it would be nice too. I would get something like :
Thank you Wim, RH-55283 looks very promising. I do like the idea of graphical editing in text editor but I would be perfectly fine if I could find how to access any values in a python-like language.
The integration in the text editor of some python interpreter is not perfectly clear to me. The python float() function is actually working perfectly fine with strings.
Test : %<str(float(“3.3”)*float(“2.0”))>%
Output : 6.6
But I can’t figure out why DocumentText(“some_key”) fails in being a valid input for the float() function since it seems to evaluate as a string.
Test : %<str(type(DocumentText(“some_key”)))>%
Output : <type ‘str’>
Going back to the original post in this thread, there is a bug with number conversion of AttributeUserText.
Per the R8 documentation quoted, the float function correctly converts a user entered AttributeUserText field with, say, the key “Density” to a number. However it fails to convert an AttributeUserText field where the value is the result of a built in function, such as “Volume”.
p.s. For simplicity I have left out the maths operations that require the conversion, you can of course simply display the UserText string directly if no ops are involved.
In my last post I tried to decompose the sequential steps involved in the conversion from text to number. Finally my exploration was not very successful and I got a little disappointed with the following observations :
the float() function was successfully converting a string (e.g. “3.3”) into a number
the output type of DocumentText() seems to be a string
but when the DocumentText() function is placed as an argument of the float() function I get an unexpected output (“####”), which does not make sense to me since the float() function was able to convert a string and the DocumentText() function apparently output a string.
I think you clarified what was causing the problem I ran into. The Document User Text value that I was trying to insert with the DocumentText() function was itself the result of a built-in function ( e.g. Volume() ).
The conversion of a Document User Text numeric string into a number is possible unless the value comes from a built-in function.
