I discovered one minor problem when upgrading from CFMX to CFMX6.1, it looks like GetTickCount() changed and it is now returning a value that is very different from what was returned previously. If you use GetTickCount() to return a value that is to be compared to another GetTickCount() value then you'll not run into this one. But I was using GetTickCount() to seed Randomize() using , and the number now returned by GetTickCount() is so large that Randomize() would not accept it. The quick fix? I changed the code to use and the page is now working again. Not a biggie, but worth noting.
GetTickCount() Changed
3 Comments
B
Ben Forta
If all you are doing is subtracting one GetTickCount() value from another then you'll not notice a difference. The truth is that GetTickCount() is not supposed to return a value that actually means anything apart from being something to compare. Something did change, but as the normal use of this function should not acre what the value is I doubt it'll be documented anywhere at all.
I
Igor Ilyinsky
That is interesting. I must have used getTickCount() hundreds of times, but that was for commented execution time comparisons. Do you know why the change? I did not see anything about this in the release notes or on the beta.
S
Sam
The return type was changed between CFMX 6 and CFMX 6.1. Run this code in both versions and you'll get different results:
<cfoutput>#getTickCount()#</cfoutput>
<br />
<cfoutput>#getTickCount().getClass().getName()#</cfoutput>
In CFMX6 you'll get:
-283703323
java.lang.Integer
And in CFMX 6.1 you'll get:
1060572189240
java.lang.String
So the return type is actually a string, but since CF is loosly typed nobody notices and you can do most calculations. The number is the same as is returned by System.currentTimeMillis() which returns a long. It appears the conversion from Long to Int in CFMX6 was causing unexpected negative numbers. Returning a string fixes that.
I just checked livedocs and they're very vague--unchanged since CFMX6. I remember at one point a more complete description that actually described slightly different behavior--maybe that was decided against or just not implemented. Might change in the future though, so the warning holds--don't rely on getTickCount() for anything other than as a timer.
We actually ran into the same problem you mentioned with Randomize() in CF5. In CF5 getTickCount() returned the number of milliseconds since the computer was started. Once you got to about 90+ days, the number got to be larger than what CF could handle as a number. You could use it for very simple math (add/substract but not multiple/divide) and try to pass it to a function like Randomize() and it produced an error.