The obvious answer would be it is not documentation, but is it?
In any case that is something I have known for many years, though I don’t recall how i learned it…
Not only can you assign one constant to another , but as being able to do that assignment implies, you can also assign a constant expression to a constant.
Try:
Const X as Integer = 3
Const Y as Integer = X + 1
Const Z as Integer = X + Y
MsgBox "Y = " +Str(Y) + " Z = " +Str(Z)
And you get what you would expect
-Karen
I imagine most Assemblers can do similar. Certainly the ones I used, 40 and more years ago, could do such as:
A EQU 27
B EQU 33
C EQU (A+B)/2
I knew that you could define and use constants that way in methods, that’s not uncommon, I didn’t know that you could define constants that way as members of classes or modules. Which is part of why I’m surprised I never tried it.
If you were aware that this could be done, that’s great. Wish you’d told me two decades ago. 
And just to illustrate what we’re talking about, as the code you provided above appears to be from a method, this is the implementation that surprised me:
You can download the project outlined in the article here.
I do believe we’re talking about different things as constants defined via the inspector cannot be evaluated as you say they can in the first post here. For instance:
Results in a Syntax Error:
I may be wrong but I thought one time it did … but I could be misremembering. It’s not something I played with much, but now that you mention it I vaguely recall something along those lines being changed a good while back too…
After 20+ years of using the product it all blends together !
-Karen
There’s an open ticket about this behavior. There’s some interesting bits in the comments of the ticket.
#55502 - Adding a constant to a class cant use an expression while one in code can
Currently, there’s an software design adage that says something like that:
If an attribution can be expressed entirely by constants and literals, it should be done; if not, if it can be expressed using an immutable (like final), it must be done; only after those options exhausted you must think in using mutables (variables).
const > final > var
I would like to know from Xojo if that behavior was planed or it’s a bug. @Paul_Lefebvre, can you explain please.
If that was not planned and it’s fixed, the code will break in many applications.
What behavior? Case #55502? It’s a “current limitation that should not occur”, in case of missing a better label, a bug label could be used to classify it.
It won’t break codes as codes trying to use it today just don’t compile it accusing a syntax error. But being able to compile it, is a desired feature.
