Skip to content
Home » Blog » The lsconst expedient

The lsconst expedient

There are a lot of handy constants included in the LotusScript file lsconst.lss, which you can include in your scripts via the statement:

%Include "lsconst.lss"

It contains many “Const” definitions for symbolic names needed for calling built-in functions, such as this constant useful when calling Messagebox function:

Public Const MB_OK = 0

None of these constants is necessary since you can also hardcode the constant value when you make your call. But it makes your code easier to read and maintain if you use the symbolic names, so this is a best practice. Having the names available for typeahead assistance is also helpful, in case you haven’t memorized the values associated with every option to every function.

The problem

Lsconst.lss is such a handy file that it gets included all over the place. If you follow good coding practice and create a collection/hierarchy of limited-purpose LotusScript libraries, you’re bound to run into a situation where one script needs to use two libraries that both include this file. This results in the error message, “Duplicate PUBLIC name V_EMPTY in USE module <library name>

LotusScript snippet showing compiler error because of duplicate constant.

V_EMPTY is cited because it’s the first constant defined in the LSS file, which is included in both the ZoomList and ZoomQueue libraries in this example. LotusScript doesn’t like to see two definitions of the same constant name within the same scope, even if — as in this case — the value associated with that name is the same as the previous definition.

The solution

The compiler isn’t smart enough to realize that the same file was included twice. However, it is smart enough to notice that the same script library was “Used” twice and not load a second copy of that library. So we can address this problem by having just one “%Include” of lsconst in the whole application, and put that in a library we can refer to via “Use” statement. Here’s the code for the lsconst script library I add to every application:

Option Public
Option Declare
	Library lsconst
	Description: Script library to include "lsconst.lss" and not cause an error if it's included multiple times. Use 'Use "lcconst"' instead of '%include "lsconst"'.

		A few other useful constants are also included.

%Include "lsconst.lss"

'Begin DNT
' Here are other constants needed everywhere.
Const NEWLINE = {
Const TABB = {	}
Const DOTT = {■} ' character we never see in data, use as delimiter

I took the opportunity to throw in a few other constants that are universally helpful, such as NEWLINE, and you might want to add your own depending on your coding habits. So now if a script needs any of these constants, they load them with this statement:

Use "lsconst"

There’s no name conflict when two libraries in the same hierarchy use this statement, because when it runs across the second of these, LotusScript sees the lsconst library is already loaded, and does nothing.


It’s obviously a problem if the same public constant is defined with two different values in different modules. But it seems to me it would be nice if LotusScript noticed if the values were actually different — then we wouldn’t have this problem.

However, this might actually be the more efficient way to do it anyway.

2 thoughts on “The lsconst expedient”

  1. What would be even better if the constants thus included would be autocompleted in the case they were defined in. But no, the Eclipse LotusScript editor, much to my chagrin, just uppercases the first Letter, and is done with it. To add salt to the wound, it treats product object methods and properties the same. Slows me right down, having to correct case for every method and property I use.

Leave a Reply

Your email address will not be published. Required fields are marked *