How did he not know it?

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.


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


1 Like

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. :grinning:

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 !


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.