Subsystem in 1C 8.3— a metadata tree object that is responsible for building the configuration command interface.

Below in the article we will talk about subsystems starting from version 8.2.

The fact is that version 8.1 (as well as a regular 8.2 application) also had subsystems, but they served completely different purposes, more likely for the developer than for the user. Using subsystems in 8.1, different functionality was usually separated. The subsystems also helped when combining different 1C configurations - it was possible to specify which system to transfer.

1C subsystems and programmer interface

In versions 8.3 and 8.2, subsystems are the main tool for building a command user interface. Subsystems metadata objects have hierarchical structure To configure a “submenu” in the interface, you need to add a subordinate subsystem:

Properties and Settings

Let's look at the settings and properties of the subsystems in the configurator:

Get 267 video lessons on 1C for free:

Include in command interface— if you forgot to set this flag, subsystem will not be displayed in the interface.

The button opens the interface settings panel, where you can configure interfaces depending on the role of the current user:

Picture— the picture assigned to the subsystem is displayed in enterprise mode. You can select a standard image, or you can add your own by first creating it as a configuration object Picture:

On the tab Functional options indicates a list of functional options in which this subsystem is used.

Tab Compound defines a set of metadata objects participating in a given subsystem.

On the tab Other you can describe the help for the subsystem and specify the settings Include in help content— whether to include this help section in the general background information by configuration.

If you don't see a report or processing in the managed interface

This problem very often arises among novice developers - it seems that a report or processing was added to the subsystem, but it is not visible.

The first reason for this may be that the object does not have a controlled form defined.

The second reason is that on the object’s Commands tab, the “Use standard commands” checkbox is selected. This is due to the fact that to open processing, either your own procedure can be described, or a standard one can be used:

The article continues the series “First steps in 1C development.”

In the configuration on the 1C:Enterprise platform, when displaying information, tables are most often used that display various information lists. Working with such lists can occur both in the form of a list and in the form of an element (processing).

In this article, we will get acquainted with these options for customizing lists, and also look at other features of customizing forms from the user's side.

Applicability

The article discusses the Managed Interface in the “Version 8.2” version of the configuration developed on the 1C 8.3.4.482 platform.

If you work with configurations that support this interface, then the information is relevant for you and current versions platforms.

If you are working in the new Taxi interface, then the names of some configuration commands, as well as the general sequence of actions, may be slightly different.

In addition, the current version of the platform has added new search capabilities in lists.

Setting up forms and working with lists

For managed form elements, it is possible to change visibility and some other properties. For these purposes in in a manageable form on the menu All actions serves as item Change form.

After clicking this command, the “Form Settings” window will appear.

In the window that appears, you can use checkboxes to change the visibility of some details. In this case, the form is automatically scaled.

You can change the order of details. Add a new group and place some details (elements) into it, defining the option for their grouping (horizontal, vertical).

Details included in the group will be posted accordingly. In addition, you can configure properties such as width, height, and header data for elements.

You can define attributes that will be activated when the form is opened.

An important feature is the ability to add new fields to the form. This becomes possible through reference type attributes.

For example, having a reference type attribute on the form Counterparty, can add The contact person, If this prop is present in the “Counterparties” directory.

If necessary, additional fields can be removed. Fields created in the configurator cannot be deleted. All settings made by the user are saved.

To return to standard settings in the Form Settings window in the menu All actions you should select the item Install standard settings .

In addition to customizing forms in the managed interface, it is possible to customize lists (directory elements, documents).

In the form of a list in the menu All actions contains a special command Customize the list.

The “List Settings” window will open. In this window you can select, sort, define conditional formatting and grouping.

The figure shows a form for editing the selection.

Selection can be made using several fields. In this case, by default the selection will work according to the AND condition. You can also use the OR and NOT conditions.

To use the OR (NOT) condition, you need to add the appropriate group (OR Group, NOT Group) using the Group Conditions command.

The figure shows a form for defining sort fields.

Grouping can be configured. In the figure, the field for grouping is selected Counterparty.

The next figure shows how grouping will be performed.

You can freely color the list or apply other elements of conditional design (font selection, specific formatting) according to a given condition, as well as select a list of fields to be formatted.

The figure shows the result of conditional design of the field background Sum.
When the amount is > 100,000.

It should be noted that it is possible to view directories in hierarchy mode.

Hierarchical viewing of directories can be configured through the item View Mode on the menu All actions. You can choose one of the options: Hierarchical list, List, Tree.

It is also possible to configure your own grouping of directory elements by certain details.

For example, you can group items by supplier. The example is similar to where we looked at grouping the “Sales of goods and services” documents by counterparties.

A convenient feature is multiple selection in lists and subsequent execution of group actions (posting, canceling, unchecking deletion).

Objects in the list are selected by holding down the key Shift or Ctrl.

Searching for a certain value in a list has its own characteristics. The search operates in selection mode. Only those rows that satisfy the search condition remain.

To search by value in the current column, just position the cursor on the desired column and click on the button Find in the command panel. A window will appear in which you should also click on the button Find.

To make your search more specific, you can use the checkbox Search in found.

When searching for a row of data of a reference type (for example, units of measure), you should select the appropriate search option ...(by line).

This concludes with lists and ways to configure them. In the next article, we will continue to get acquainted with the interface and look at a convenient tool for informing the user, which we have not talked about before. What kind of instrument is this? :)

I believe there is no need to tell you what an access control system is, a settings compositor and, in general, the entire set of objects designed to work with an access control system. The main areas of use, not counting tricky actions in the code, are dynamic lists and reports, and in both cases, very significant functionality remains behind the scenes. We often don’t even think about the logic of the behavior and relationships of all participants in the process, because We usually solve fairly simple problems or rely on the platform’s defaults. But where there are silences, there is also an internal logic, a kind of “disservice” of 1C, the fruits of which are sometimes difficult and unobvious to overcome in order to achieve the desired effect, and at the same time it is enough just to use the tools correctly.

Those interested can skip parts 1-4 and go straight to the examples.

I’ll try to dwell in a little more detail on the operation of ACS selections for the case of their use in reports. I think the behavior in dynamic lists, with a number of reservations, will be close. So, selections in reports, a little theory and then specific examples.

SP 8.3.6 and higher, sections of ITS (clause 10.3.7.5, etc.), the book “Professional development in the 1C-Enterprise 8 system” (Kazan, 2012, second volume) are used. In E. Khrustaleva’s book there was nothing intelligible on this topic at all.

Part 1

The settings builder, as you know, has collections “Settings”, “Fixed settings” (hereinafter “FN”) and “Custom settings” (hereinafter “CU”). A report can have several options, and the connections between the option, N, PN and FN are very unique. Also, let's not forget about the source available settings, and its “ancestor”, which is usually the circuit itself, which also has its own default settings.

* Settings – settings created in the Configurator mode and changed in the report version editing mode;

* UserSettings – settings that the user changes in the “1C:Enterprise” mode purely through the interface;

* FixedSettings – those settings that are set from the built-in language, incl. are implicitly set by the system. This property contains selection values ​​that are transferred to the form using its parameters (the “Selection” structure).

Settings and FNs are similar in design and have a “Selection” collection of the “Data composition selection” type, available for changing the composition at any time during the report’s existence. At the same time, Settings are available for interface changes through editing a variant, but FNs are not accessible at all. PN, in turn, is a “porridge”, where equal elements can be both the “Selection” itself and individual objects of the type “Data composition selection element” (the so-called nested object). Despite the availability of appropriate methods, it is impossible to programmatically change the composition of a collection of PN elements if these are PNs of the report itself, and not made “from scratch” by the designer - 1C will report that “The collection of user settings cannot change its composition, since it is associated with the layout settings data." The ITS says: “The property is not writable using the built-in language.”, but, as we will see later, it is possible to influence the PN. The “porridge” of objects has internal communications– it is checked for consistency of conditions when generating the report, and when the composition changes. On ITS we read: “Elements that are themselves marked as custom will not be added. For example, a custom selection will not include a selection element that is marked as custom. Elements containing custom elements will not be added. For example, a condition group will not be added if the group contains elements marked as custom. For nested elements, the DisplayMode property is not analyzed. They are added or not added along with parent elements." Thus, the “seniority” of objects operates behind the scenes. In this case, you can get an effect when the interface allows you to specify contradictory selections for a variant and its PN, as well as within the PN.

It would seem that "senior" is an option. But clicking on “More” / “Change option” and confirming changes in the opened form calls the form event handler , in this case, the selection appears in the "Basic" panel on the form called from "Settings...", and appears on the report form, but is NOT shown on the "Selection" tab; Moreover, either it appears immediately both on the main report form and on the “Settings...” form (if there is a flag “Include in user settings”), or neither there nor there. But in any case, it will NOT be on the “Selection” tab of the “Settings...” form. The difference between the "Basic" tab, the "Settings..." form and the main report form is determined by the "Edit mode" field (normal - only in "Settings", fast - also on the report form itself), but I think everyone knows this. By the way, the values ​​of “Selection” and “Fast” are not synchronized in any way and may contradict each other, but “Fast” on the report form and on the settings form are strictly synchronous. So, when you edit a variant, it itself becomes changed (but its ID and name do not change), but the PNs remain NOT modified (i.e., even if we are talking about them, i.e., about the flag for including this or that element in the PN ).

Clicking on “Select option...” and confirming changes in the form that opens triggers events in the following order:

When Uploading OptionOn Server

When Updating the Composition of User Settings on the Server

In this case, neither the option nor the PN changes in any way. From here it is clear that the option and settings, if connected, are by no means directly connected.

Clicking on "Settings..." and confirming changes in the opened form only triggers an event When Updating the Composition of User Settings on the Server(in this case, the PNs become changed, but the views and the key (if they were not there) are not received; if “Fast” is enabled for the elements of the “Selection” object of the PN, then in addition to “Selection”, its actual elements appear as fields, i.e. . behaves similarly to nested elements. These settings are saved when closing and restored the next time you enter the form. It does not touch or change the option.

Clicking on "More"/"Set standard settings" in the settings form (as well as the "Standard settings" item in the option edit) only triggers the event When Updating the Composition of User Settings on the Server. In this case, the option becomes changed, but the PN changes. If the option was changed before, it remains changed (neither the changed flag is reset, nor the actual settings are reset).

Clicking on “Properties of a custom settings element” in the structure tree on the variant editing form adds a “Selection” object, and it turns out empty and is not synchronized in any way with the existing variant selection and existing nested selection elements. The variant does not change in any way.

Hence the recommendation: if you need to set certain selections in the “Configurator” mode, so as not to tinker with the code and so that they are not in the option, but would be in the report interface, you should not manipulate the selection elements of the option, changing their properties, but the selection itself , using the “Element Properties…” and “Custom Settings” buttons.

Adding something that appears in Settings to the PN requires actions in the code or interface, but deleting and clearing Settings affects the PN immediately and without any updates, for example:

Report.SettingsLitter.Settings.Selection.Items.Clear();

Before closing the report form, the system asks only if there have been changes to the variant. If there have been changes to the PN, they will be saved automatically without any questions, and will also automatically try to be applied in the next session of working with the report.

Notes:

In case of a number of errors in the application of settings, a message about the problem is first displayed, and then the composition still occurs, the event is called and report generation. In this case, FNs, even if they existed, are still ignored, and only Settings play a role.

When adding a selection on the “Change option” form, it is done immediately with the “Include in PN” flag set, but, I repeat, from the point of view of the built-in language, PN remain unchanged.

Setting the variation of a variant and setting the variation of the PN are not directly related; these are two different directions of changes.

PN, among other things, has “Additional settings”. I have never been able to understand what and at what moment they are filled. Although the report contains settings “marked in the selection and conditional design” as custom (according to the joint venture), but additional settings in all cases they were empty. There is nothing about this on ITS.

Despite the statement in the joint venture, PNs are perfectly serialized in xml.

If both independent selection elements and the selection itself are included for use, then the report is compiled correctly, but when displayed, it duplicates the information about the established selection in the final layout.

The default form for editing a report version contains many interesting things, but nowhere does it work with FN and PN, and even with the basic settings it works more for reading (except that it clears the selection, order, conventions).

Part 2

Working with Settings and FN through their collection is almost always acceptable, but it is important to remember that the essence of the “third level” is changing. The first level always contains the default settings of the access control system itself; they also appear implicitly in the source of available settings; at the second level – settings of the option used. But here logic allows you to either “overwrite” the underlying instructions or ignore them. But working with PN no longer allows for liberties, and subtle manipulations must be done using special methods, and sometimes temporary auxiliary intermediary objects, for example:

Comp=NewDataCompositionSettingsComposer; // you can also start // comp.Initialize(SomeSettingsComposer.GetSourceofAvailableSettings()); comp.LoadSettings(SomeSettingsComposer.Settings); SomeSettingsComposer.LoadCustomSettings(comp.CustomSettings);

The settings builder has a method (), which loads the user settings values ​​passed as a parameter to the method. Method GetSettings() allows you to get a copy of the current settings (taking into account user settings). Method DownloadSettings() loads the passed settings into the settings builder (user settings are also repopulated based on the passed data, taking into account the presence of keys, see example below).

Applying custom settings to the main settings is done in the method GetSettings() settings builder. The following actions are performed:

* For DataCompositionSelectionElement types, the contents of the elements are copied to the corresponding custom settings elements.

* For Data Layout Selection types, elements located in the main settings and marked as Inaccessible remain unchanged. Elements from the PN are transferred to the main ones. They are added to the end of the collection for Selection.

* For the DataCompositionSelectionElementGroup types, the Usage property is set in the corresponding element of the main settings (based on the sign of the use of the PN element).

Part 3

When forming the final settings, to quote ITS, various settings are combined as follows:

* If any type of settings is entirely marked as custom, then the resulting settings include PN. In this case, if any settings elements are marked as unavailable, then these settings will be placed in the resulting settings from the Settings Composer.Settings property.

* If any type of settings is marked as custom not entirely, but element by element, then the elements marked as custom will be included in the resulting settings from the Settings Composer.CustomSettings property, and the elements marked as unavailable will be taken into the resulting settings from the Settings Composer.Settings property .

* Fixed settings are added to the resulting settings "as is". At the same time, it is unacceptable that the FN and PN have settings of the same name, for example, selection with the same left value in the condition. I note that even the complete coincidence of all the properties of these conditions is prohibited. To be honest, it's a little illogical.

Let me note that if any fragment of the settings falls under the action of a functional option and must be limited, the system works “quietly” - it removes this fragment from everywhere, does not report anything, and during program manipulations regarding such a fragment, it processes “idle” errors. It doesn’t produce any results, but the code has no effect either. However, it is possible that different releases behave differently.

Part 4.

The report form extension provides us with the parameters “FN” and “PN”, but nowhere is it recommended to fill them out directly by passing them to the form. As experiments have shown, without additional dances with a tambourine, the content of these parameters is ignored - it is overwritten when the linker is initialized during the opening process and when previously saved PNs are received. It is recommended to work with PN keys, by which you can retrieve them from the settings storage and then open and use them, and this is done automatically on the side of the report form, and not on the calling form.

The “Source of Available Settings” parameter is automatically translated into the builder information when creating the form on the server and cannot be overridden. Or rather, it can, but this will only have an effect after a complete redefinition of the entire chain of related objects. Wherein GetSourceAvailableSettings() will return Undefined until the end of all form opening events.

Let me note that the form parameters, which are essentially not key parameters, “stretch” their action over several events if the formation flag is set when opening. Yes, in the event ProcessingCheckFillOnServer, called during opening and formation, the “Selection” parameter will be available, but with it, but called simply by the user clicking on the “Generate” button, it will no longer be available. This is due to the fact that all these events are processed in one “visit” to the server, if the formation when opening is enabled, and only at the very end of them control is transferred to the client and called WhenOpening. In this case, non-key parameters are naturally lost.

The general order of executing events when opening a form with a flag to generate a report upon opening (slightly more than described in “Professional Development”):

When CreatedOnServer

Before Uploading Option On Server

When Uploading OptionOn Server

Before Uploading User Settings to the Server

When Loading User Settings on the Server

When Updating the Composition of User Settings on the Server

ProcessingCheckFillOnServer

WhenOpening

In this case, neither the option nor the PN are changed unless special efforts have been made.

Part 5.

Now let's look in more detail at the task of opening a report form with its construction and pre-specified selection. Brief information there is information about this on ITS and in methodological recommendations, but only the principle itself is covered there and the subtleties are not revealed. So, to contextually call a report, you need to pass the “GenerateOnOpen” parameter to its form, equal to True; and the Selection parameter containing the structure. The structure keys are the names of ACS fields or ACS parameters, and the values ​​are their values. Quoting SP, if there is an ACS parameter with a name corresponding to the name of the structure key, then the value will be set to it. If there is no parameter, but there is a field, then a selection will be added to this field. At the same time, if there is a parameter and field of the same name, then the system will simply quietly ignore it and not install anything.

“Professional development” provides an example of changing (i.e. intercepting and reconfiguring) PN “on the fly” in an event Before Uploading User Settings to the Server, where the argument containing the current PN is passed. In fact, this is not always the case - for example, there may be cases where an error in saving the PN in a previous session, or inconsistencies between Settings, FN and PN will lead to the “Settings” argument being empty. And what’s most interesting is that it will not be possible to fully reconfigure it in this event; this can only be done “at the end” of the sequence of events, namely, in the event ProcessingCheckFillOnServer.

Let's see what we have before loading the PN on the server.

For a simple case, when nothing is preset in the ACS and no elements are included in the PN, the situation is as follows: Settings – empty; FN – contain correct selection; Mon contain an empty Selection. The shaping works correctly, but from the user's point of view the interface contradicts the internals and is discouraging - the selection works, but is not visible. Similarly, if you enable Selection in PN in the option structure settings, the report is also built taking into account the selection, but the user also does not see any selections.

Let's set pre-selections (equal to empty values) in the ACS settings in the Configurator and include them in the PN. In theory, the FNs should fill out the Settings, and those should fill in the PN, but in reality we have: in the Settings - Selection with the required element, but an empty right value, the FNs contain the correct selection, and the PNs still do not contain anything. In addition, in this case the report will not be built, because the right selection value is empty, despite the value passed in the Select parameter.

An attempt to work with PN elements also does not produce results. For the PN element, you can only change the “Use” flag and participation in “Quick”. The selection value on the interface will be empty, the system will not generate any errors. Similarly, an attempt to work with PN Selection will also work; in the debugger, the right value will be visible as correctly filled in, but you will not see anything on the interface. Let me remind you that it is impossible to change the composition of the PN. Thus, additional tricks are required. For example:

&On the Server Procedure SetPresetSelections(UserSettings) If not Parameters.Property("Selection") Then Return EndIf; If Parameters.Selection.Quantity()=0 Then Return EndIf; rTypeEO=Type("DataComposition Selection Element"); For each key From Parameters.Selection Loop pField=NewDataCompositionField(key.Key); // If (ValueType(kiz.Value)=Type("Array") orValueType(kiz.Value)=Type("ValueList")) and kiz.Value.Quantity()>1 Then pViewComparison=DataCompositionComparisonType.InList; Otherwise pComparisonType=DataCompositionComparisonType.Equals; endIf; // pNecessarySelection = Undefined; // see if there is Selection in the user settings pNecessaryEO=Undefined; // see if there is a separate DataComposition Selection Element in the user settings For each elnastr From UserSettings.Elements Cycle If TypeValue(elnastr) = Type("DataComposition Selection") and pNecessarySelection=Undefined Then // there can be only one pNecessarySelection=elnastr; // this could be done outside the loop, but it is necessary to sort through the user settings for the sake of elements... Otherwise, If TypeZnch(elnastr) = pTypeEO Then // this is a selection element, there can be many of them, but we are interested in those that are not initialized or with the required field If elstr.LeftValue=pField or elstr.LeftValue=Undefined and rNeedEO=Undefined Then pNeedEO=elstr; endIf; endIf; EndCycle; // If pRequiredSelection<>Undefined Then // it goes as a priority pNecessaryEOFromSelection = Undefined; For each elotb From pNecessarySelection.Elements Cycle If elotb.LeftValue=pField Then pNecessaryEOfromSelection=eloteb; Abort EndIf; EndCycle; If pNecessary EO from Selection = Undefined Then pNecessary EO from Selection = pNecessary Selection.Elements.Add(pType of EO); pNeedEOFromSelection.LeftValue=pField; endIf; pNecessaryEOfromSelection.ComparisonType=pComparisonType; pNecessaryEOFromSelection.RightValue=kiz.Value; pNecessaryEOFromSelection.Use=True; // rNeededEO.Use=False; OtherwiseIf pNecessarySelection=Undefined and pNecessaryEO<>Undefined Then // put on the element pNecessaryEO.LeftValue=pField; pNecessaryEO.ComparisonType=pComparisonType; pNeedEO.RightValue=kiz.Value; pNeedEO.Use=True; endIf; pNeed=Undefined; For each elotb From Report.ComposerSettings.Settings.Selection.Elements Loop // in an amicable way, there should be a recursive search! If TypeValue(elotb)=pTypeEO and elotb.LeftValue=pField Then pNeed=elotb; Abort EndIf; EndCycle; If pNeed = Undefined Then pNeed = Report.Settings Composer.Settings.Selection.Elements.Add(pEOType); pNeed.LeftValue=pMargin; endIf; pNecessary.ComparisonType=pComparisonType; pNeed.RightValue=kiz.Value; pNeed.Use=True; //EndCycle; Report.Settings Composer.FixedSettings.Selection.Items.Clear(); // otherwise it will say that the elements intersect/contradict End of Procedure

The most correct way to call this is:

&On the Server Procedure Processing Filling Checks On the Server (Failure, Checked Details) Set Predefined Selections (Report. Settings Linker. User Settings); End of Procedure

Then, a context call, for example, from a directory form, will look like this:

&OnClient Procedure OpenReport(Command) If ValueFilled(Object.Link) Then ot=New Structure("LinkToDirectory",Object.Link); // this is how the field is named in the SDS report Form Parameters = New Structure ("Selection, GenerateWhen Opening", select, True); OpenForm("Report.Report1.Form.ReportForm",FormParameters,ThisForm); endIf; End of Procedure

Part 6.

If necessary, change the report settings while working with it, incl. both at startup and after opening, the most correct way is to change “from the beginning”, i.e. from the ACS settings. Changing the ACS scheme is performed only with the Report object (or External Report), and not with the form data, and in itself does not change anything - in Settings and in the PN the same remains as it was, and the FN may remain empty. Therefore, depending on our tasks:

After execution

Report.Settings Composer.LoadSettings(SKD.DefaultSettings)

Only the option changes, and nothing more;

After performing the technique given in paragraph 2 (using the “intermediary” and the method LoadCustomSettings()

works only if you reset the current PN using the interface. By themselves, if the option is changed, they will not change. In this case, the Selection changes, but a new Selection Element is not added.

After execution

ThisForm.CreateFormElementsUserSettings(,DisplayModeDataCompositionSettings.All)

the platform just falls silently. Tested on several different releases. And calling the mode for displaying settings only for quick ones makes no sense - we didn’t influence their composition, so nothing will change anyway.

And since we still need to fully change not only the internal selections, but also the display on the report form and in related forms, we either have to change only the Selection, or proceed as follows:

&On the Server Procedure ChangeSKD() pObject = Form AttributesValue("Report"); selection=pObject.DataCompositionScheme.SettingsOptions.Get(0).Settings.Selection; eo = selection.Elements.Add(Type("DataCompositionSelectionElement")); eo.LeftValue=NewDataCompositionField("LinkToDirectory.Field1"); eo.ComparisonType=DataCompositionComparisonType.Equals; eo.RightValue=True; eo.Use=True; ValueВFormAttributes(pObject,"Report"); Report.SettingsLitter.LoadSettings(pObject.DataCompositionSchema.DefaultSettings); Report.SettingsComposer.Restore(); // desirable, although this still does not affect the FN. // in fact, this is exactly what can be called a change in the composition of the PN For each email From Report.ComponentSettings.Settings.Selection.Elements Cycle email.DisplayMode=ElementDisplayModeDataCompositionSettings.QuickAccess; If EmptyString(el.UserSettingsIdentifier) ​​Then // you can use the electronicSetIdentifier method for the PN element, see its help in the SP, everything is quite clear there e.UserSettingsIdentifier="ID123"; // important - the identifier can be ANY, not UUID or GUID! el.ViewUserSettings="Test"; endIf; EndCycle; comp=NewDataCompositionSettingsComposer; comp.LoadSettings(pObject.DataCompositionSchema.DefaultSettings); Report.SettingsComposer.LoadCustomSettings(comp.CustomSettings); For each email From Report.Settings Composer.CustomSettings.Elements Cycle email.DisplayMode=ItemDisplayModeDataLayoutSettings.QuickAccess; // pull EndCycle onto the report form; // and now this will have the effect: ThisForm.CreateFormElementsUserSettings(,DisplayModeDataCompositionSettings.QuickAccess); End of Procedure

Actually, you can study this mechanics for a long time. This publication grew out of studying ways to solve one specific problem, and is therefore quite one-sided; but I suspect that a separate book can be written about the internal logic of settings, especially user ones, no more subtle than Khrstalev’s. Unfortunately, I don’t have the energy or time for this. Whoever finds specific developments useful is already good.

Some things have been clarified experimentally and are therefore controversial. Those who know more are invited to criticize and comment.