Funny how the "integer to string" (ITOS) function has been with us for so many years, but still "no real to string" function in sight.
My guess is that it would take PTC a few hours to program this function into Creo, still we have to create pages of cryptic relations to perform such a simple task.
What a monkey to do?
Lets hope PTC gets there act together and fix this issue once and for all.
And when they are at it, why not provide the entire library java functions related to managing strings and numbers.
Now, that would something!!!
I have just found this thread by looking for something else.
This is how I do it:
/*#####Number to string for given decimal places (up to 9)#####
/*#####ASSIGN DIMENSION BELOW TO A VARIABLE#####
/*#####ENTER DECIMAL PLACES YOU WANT TO SHOW#####
/*CALCULATION (REPLACE “X” WITH NUMBER 1,2,3,…FOR EACH DIMENSION YOU WANT TO MAKE AS STRING)
/*NUMBER AS A STRING "STR_NUMBER" WITH GIVEN DECIMAL PLACES
X_STR_NUMBER=X_STR_NUMBER_INT + "." + X_STR_NUMBER_DEC
This macro also rounds up or down the value for given decimal places.
When nothing else is available from PTC this is the best I can do. It took me 5 minutes to make this script. I do not understand why PTC could not do something like this? They should be better in this, right? If Excell has VAL and STRING functions since forever, I do not understand why Creo does not have it in 21st century?
I am sorry, didn't mean to get started on why PTC couldn't change this and that.
Yes, it is 21st century. Relations could be more robust with more operations and functions available nowadays, but this is what we get.
I think the old programmers of Pro/E has put in too little functionality back when they have been developing relations just because they wanted to save few lines of code, but now each and every user's part has to have this more of an awful code. Luckily we can get good enough comps now that can chew all these stupid relations.
These days when it's all about sales for PTC, they don't give a damn about relations, as long as existing relations functionality is not broken. If there is a possible workaround to a problem, then an enhancement to that problem will not make any more sales.
I've posted here just to let you know I wouldn't be able to figure out how to write that relation you posted above in 5 mins, and maybe not even in 5 hours. So, that's what my hat goes off for.
Well, if PTC cared to make relations more robust this thread wouldn't keep on going, but then we wouldn't know how to literary make a whip from a crap.
Simply adding number format could solve it ?
&MASS:FID_9.1 is the parameter included in the note
Mass: &MASS:FID_9.1: gr -> Mass : 125.326 gr -> print 3 decimal (default)
Mass: &MASS:FID_9:1[.1] gr -> Mass : 125.3 gr only -> print 1 decimal only.
Just a head's up for other's searching the community who may attempt to implement this. There are a couple of use cases that may cause issues if used as written.
Values less than 0.0995 will "break" the logic and only output "."
Values less than 0.9995 will not output the leading zero. 0.9994 outputs ".999"
Similar to the logic above, this one too does not process values correctly.
Values less than 0.0009 output "."
Values with zeros immediately after the decimal point get shifted.
Whole numbers don't have trailing zeros. (Technically not wrong, just not desirable. Should be "10.000".)
You're lurking the forums for threads similar to this one, pointing out the stuff posted here and there is wrong! That's kinda funny
Actually, it's great to see someone taking the time to tell these are all off. To show that we seriously need a rtos() function.
I use similar relations posted in the beginning of this thread, but always with just two dec places. It does the job for me except when the dimension is smaller than 1, then it just outputs 0, but that's propably because of other error in my code.
This is not for drawings, it's for getting the real number converted to a string for use as a model parameter. For example, if you want a DESCRIPTION parameter (in the model!) to include multiple three place dimensions, you have to manually do this conversion before building the parameter text.
/* Real Numbers (map to actual dimensions)
L1 = 1.25
L2 = 2.50
L3 = 3.00
/* String Output - No Leading Zero, Two Decimal Places
L1_STRING = ITOS(FLOOR(L1+.005))+"."+EXTRACT(ITOS(((FLOOR((L1+.005),2))-FLOOR(FLOOR((L1+.005),2))+1)*100),2,2)
L2_STRING = ITOS(FLOOR(L2+.005))+"."+EXTRACT(ITOS(((FLOOR((L2+.005),2))-FLOOR(FLOOR((L2+.005),2))+1)*100),2,2)
L3_STRING = ITOS(FLOOR(L3+.005))+"."+EXTRACT(ITOS(((FLOOR((L3+.005),2))-FLOOR(FLOOR((L3+.005),2))+1)*100),2,2)
/* Generate DESCRIPTION parameter
DESCRIPTION = L1_STRING + " x " + L2_STRING + " x " + L3_STRING