As you probably know, the 1C platform has built-in standard data processors that extend the platform's functionality and can be helpful for both 1C developers and database administrators. These tools are available under menu Functions for technician:
If this menu item is missing, go to Settings -> Options:
In the window that opens, set a flag on Technician mode:
With this option enabled, you can access the built-in objects of the 1C:Enterpise platform:
Let us check what we can find under this menu item.
As you can see, the list of available objects is similar to those in Designer. In this window we can open any available catalogs and document lists and view data contained in accumulation registers. Besides, here we can access objects that are not available in Designer. In the screenshot above, they are highlighted in red. Let us expand this menu item and check what we can find there:
You can see a list of data processors. Their role is to help technical specialists work with the 1C:Enterprise platform with ease and speed. Some of these utilities like Document Posting, Event log, and Active users are really handy. In general, the purpose of these standard utilities is to support the 1C developers or administrators in their daily tasks. Since these are purely technical utilities not intended for ordinary users, they are hidden and cannot be modified.
However, let us assume that for some reason, we need to make changes to any of these standard utilities, say change a form layout or program logic, or, at least, learn about how these utilities work. Is it possible?
The answer is YES. It is possible indeed. This article describes how developers can access data processors built into the 1C:Enterprise platform, modify them or even replace a built-in data processor with a custom one.
The first thing that might surprise you is that all standard data processors built into the 1C:Enterprise platform are written in the 1C:Enterprise language. It means that if we somehow get access to these data processor files, we can modify them using the platform’s Designer.
But how do we access a standard data processor file? Here is the second surprise: since standard data processors are part of the platform (it treats them as resources), developers can access standard data processor files if they know their internal addresses. For instance, the internal address for utility Active users
looks like this:
v8res://mngbase/StandardActiveUsers.epf
So, why not try accessing this built-in data processor? Let us create a command to open this utility.
Take a new empty 1C configuration, add a common form to it, and place this form on the main page so that it opens when the application starts:
Then, with the common form, create a command:
And add the following code for this command:
|
&AtClient Procedure cmdOpenActiveUsers(Command) cmdOpenActiveUsersAtServer(); OpenForm("ExternalDataProcessor.StandardActiveUsers.Form"); EndProcedure
&AtServer Procedure cmdOpenActiveUsersAtServer() ExternalDataProcessors.Connect("v8res://mngbase/StandardActiveUsers.epf", "StandardActiveUsers", False); EndProcedure |
What does this code do?
First, within server procedure cmdOpenActiveUsersAtServer we connect to the utility built into the 1C:Enterprise platform (this is where the utility’s internal address comes in handy). Then, as the second parameter, we pass the name StandardActiveUsers that can be used for calling this utility in the future.
And at step two, within client procedure cmdOpenActiveUsers, we get the form of this previously connected utility opened.
Let us check now how it works. Launch the platform in dialog mode and run the test:
As you see, form Active users opens without any problem. So we have proven that we can access the platform's built-in utility if we know its address.
Great. We have learned to open standard 1C data processors anywhere in our application. But, if you remember, our initial intention was to learn about modifying such standard utilities. Let us see how we can do it.
I already mentioned that our benefit is that all utilities built into the platform are written in the 1C:Enterprise language. So when we want to modify any of them, we simply save a data processor as a file and then open it for editing in Designer as with any other data processor.
How do we save the built-in data processor to a hard drive? It's very simple. Just use the 1C:Enerprise platform command:
FileCopy(<SourceFileName>, <ReceiverFileName>)
The path to the desired file is the first parameter we pass with this command. Note that it can be the path to the file on disk or the file’s address inside the 1C:Enterprise platform. In other words, to save Active users as a standard data processor, we need to run the following command:
FileCopy("v8res://mngbase/StandardActiveUsers.epf", "C:\Temp\StandardActiveUsers.epf")
Let us add this command and attribute Utility name to our app:
The code for this command looks like this:
|
&AtClient Procedure cmdFileCopy(Command) cmdFileCopyAtServer(); EndProcedure
&AtServer Procedure cmdFileCopyAtServer() FileCopy("v8res://mngbase/" + UtilityName + ".epf", "C:\Temp\" + UtilityName + ".epf"); EndProcedure |
By default, the utility gets saved to the Temp folder on the C drive, but you can always choose the path you need.
So, let us check out how it all works. Launch the platform in dialog mode, specify the name of the desired utility, and click button File copy:
Let us see what we have got:
Congratulations! We have managed to save the built-in data processor as a file. Now we can go back to Designer, open this data processor here, and take a look at its content:
Cool! We got access to the utility code built into the 1C platform. Now we can figure out how it works or modify this data processor if necessary.
For a test, let us change the name displayed on the data processor form and try to open it in the dialog mode on the platform:
Everything works as expected.
Still, should we try to open the built-in standard data processor now, the old, original version of the utility opens again (it happens when you close the 1C:Enterprise platform session and start a new one):
How do we always get the new, modified version of our utility, regardless of how we attempt to open it: through File -> Open or Functions for technician menu? And is it possible at all?
Sure, it is easy as pie. We can replace the standard utility with any with command ExternalDataProcessors.Connect(). This way, the platform always calls this modified utility instead of the standard one.
Let us try to implement it. Go back to Designer and click Open application module:
In this module, we create a predefined procedure OnStart:
Note that the code we want to create should run on the server. As the application module cannot directly access server calls, we additionally create two more software modules, one for the client and the other for the server:
Next, we add the following program code to the software modules:
Application module:
|
Procedure OnStart() CommonModule_Client.ReplacingStandardUtilities_Client(); EndProcedure |
CommonModule_Client:
|
Procedure ReplacingStandardUtilities_Client() Export CommonModule_Server.ReplacingStandardUtilities_Server(); EndProcedure |
CommonModule_Server:
|
Procedure ReplacingStandardUtilities_Server() Export
BinaryData = New BinaryData("C:\Temp\StandardActiveUsers.epf"); addressInStorage = PutToTempStorage(BinaryData); ExternalDataProcessors.Connect(addressInStorage, "StandardActiveUsers", false);
EndProcedure |
The logic here is simple: when we launch the application, the platform reads the content of the data processor from the file on the C drive, then puts acquired data into data storage, and then, using a specified address, replaces the standard utility StandardActiveUsers
with the one it has read from the file.
Now, when calling this utility, we always get the modified version instead of the standard file.
Let us see it in action. Start the platform in dialog mode and try opening data processor StandardActiveUsers via menu Functions for technician:
As you noticed, we have the modified utility opened instead of the standard data processor.
This way, we can quickly modify the built-in standard data processors as needed.
Still, storing data processor files on a computer drive has a drawback. Imagine that someone deletes a data processor. Naturally, it results in an error message on application start:
Another risk is that a current user might lose access to the folder with a data processor file and so on. As a result, we lose the ability to use our application as designed. Is there a workaround here?
Sure. Put the data processor files directly in the 1C configuration. Here is how you do it.
Go back to Designer and create a standard external data processor there:
We are not going to place any code in this data processor. Instead, we intend to do something unusual. I believe you guessed it. It is about how we store our modified data processor files.
Go to tab Templates
and add a new template:
Set the template type to Binary data:
And in the next dialog box, select the file with the previously modified data processor from your drive:
Then click OK.
And our file gets uploaded inside the template as binary data. Now there is no need to read the file from the disk every time the application starts since the data processor is a part of the application. All that remains is to modify procedure ReplacingStandardUtilities_Server:
|
Procedure ReplacingStandardUtilities_Server() Export
dataProcessor = DataProcessors.ReplacingStandardUtilities.Create(); dataProcessorBinaryData = dataProcessor.GetTemplate("StandardActiveUsers"); addressInStorage = PutToTempStorage(dataProcessorBinaryData);
ExternalDataProcessors.Connect(addressInStorage, "StandardActiveUsers", False);
EndProcedure |
Well. Time to see how it all works. Start the 1C:Enterprise platform in dialog mode, select Functions for technician -> Active users. Perfect. It works as it should.
Should you go back to the beginning of this article, you can recall the fact that there are several standard utilities built into the 1C:Enterprise platform. That is, the list of these utilities is not limited to just data processor StandardActiveUsers. What do we do as developers if we want to modify any other utility?
The answer is straightforward. All we need to access any other standard data processor on the 1C:Enterprise platform is to know the internal name of the respective data processor. Is it possible to find out? Definitely! There are no barriers for inquisitive minds!
Here is what we do! Go back to Designer, select the common form, and add command Get internal name and attribute Internal name:
Here is the code for this command:
|
&AtClient Procedure cmdGetInternalName(Command)
AppWindows = GetWindows(); For Each AppWindow In AppWindows Do If AppWindow.Content.Count() Then objectName = New Structure("MetaPath, FormName"); FillPropertyValues(objectName, AppWindow.Content[0]); If StrStartsWith(objectName.MetaPath, "ExternalDataProcessor.Stand") Then InternalName = StrTemplate("v8res://mngbase/%1.epf", StrSplit(objectName.MetaPath, ".")[1]); Break; ElsIf StrStartsWith(objectName.FormName, "ExternalDataProcessor.Stand") Then InternalName = StrTemplate("v8res://mngbase/%1.epf", StrSplit(objectName.FormName, ".")[1]); Break; EndIf; EndIf; EndDo;
EndProcedure |
Save the configuration, start the 1C:Enterprise platform in dialog mode, and run this code. But before that, pick any standard data processor you like and open it.
So, we start the 1C:Enterprise, open any of the standard data processors, for example, Event log:
Now switch to the main page of the application and click button Get internal name:
Voila! We have received the internal address and name of the utility built into the 1C platform:
Using this approach, you can get the name and address of any other 1C:Enterprise platform built-in utility:
This is basically it. Now you know how to handle the utilities built into the 1C:Enterprise platform, how to save them to a disk, as well as how to modify or even replace the standard 1C:Enterprise platform utilities with the ones you created.
Stay tuned for more secrets to come!
