Let's say I want to rename my app from Convenience to Davie Corner Store, which is, by the way, the real name of my small imaginary shop. How I do that?
Well, I can just change the Synonym of the application like this.
This does the job, but then one day my buddy Kim comes by, sees the app and wants to use it at his store. And of course, he needs it to be called "Kim's Convenience."
Then more friends of mine and friends of friends of mine start asking for the same until I find myself copying and renaming the app all day long. So, I realized that I need some place to store the name so that users can change it whenever they want.
This is a kind of task that we use constants for, so let me show you how it's done.
So, I'm going to create a constant named CompanyName and then include it into the Other subsystem. Then I run the application and set the constant value to "Kim's Convenience."
OK, great. Now I need to show this constant here in the Main Window title bar.
The company name needs to appear here at the startup, so our event should live somewhere in this module. So, I'm clicking this drop-down events list and here are the BeforeStart and the OnStart events that look promising.
We use the BeforeStart event to check if we can allow the user to run the application at all. There might be many reasons why we want to lock the system. For example, we don't want some users to work with the web client at this time. Or we don't want anyone to mess up with our data while we are in the middle of some maintenance work, etc.
This is why the Cancel parameter is here. We set it to True to cancel the system start.
We don't want to cancel anything at this case, so our choice is the OnStart event.
OK. How do we address the title of the Main Window? Easy. There is a global object called ClientApplication that contains this kind of things. And here is the SetCaption method that looks like what we need.
OK, now we need to pass the CompanyName constant value to this procedure, so I'm going to write this. Let's check the syntax and, oops. Of course. Almost forgot. The Constants aren't accessible on the client side we are now at.
The AtServer compilation directive is not accessible in this module too, so I'm going to create a new server-side common module, allow it to accept calls from the client side (don't worry, the module's properties will be discussed later), name it CommonUseServer and write this code right here.
So, here I'm reading and returning the constant value to the caller.
Now I'm calling this procedure from the application module. Checking the syntax. Looking good. Running the app.
And here is our application title.
So, we use Constants when we need to store the global settings that can be changed by users. What does "global" mean in this context? It means that each Constant stores the single value - same for all users.
Another example of the Constants usage: global default settings for fields autofill. For instance, we store products in several warehouses, but use mostly the main one and want to autofill the Warehouse attribute with this default value.
One more example: global application control settings. For instance, we want to be able to disconnect all the users to perform some maintenance, so we write the code that checks some DisconnectUsers constant value periodically. If the value is set to True, we warn the user and quit the application.
OK. We already saw how to use the Constants in the source code, right? Constants, dot, constant name, then Set if you want to change the Constant value or Get if you're going to read it. As easy as that.
Any real-world application has many Constants doing more or less the same: setting up some global features. It makes not much sense to fill each and every one on its separate form. So, the Platform contains a form template that collects all the Constants you need in one form.
It lives here in common forms and is called Constants form. You select the Constants you want here and boom. The form is here and ready to go.
You've got the idea, so let me clean up this mess.
Now let me tell you something scary. As simple as they are, the Constants can kill your application performance and get it completely paralyzed in no time.
How to do that? Frighteningly easy. Use a Constant for something that changes a lot.
For example, create the DocumentCounter constant and increment it whenever a new document gets posted.
That's it. Run away and never come back. Trust me, users are waiting for you, and you won't like what they have to say.
Why this happens is a topic for the 1C:Architect level. What you need to remember: the Constants are called Constants for a reason. And the reason is: they don't like to be changed a lot. Never ever use a Constant for something that gets changed often.