Problem solved in the note
In the 1C platform for, in its client part, the ability to work with HTML pages is implemented using the “HTML Document Field” field type. This functionality is handled by the integrated WebKit browser (1). In 1C, earlier versions used the standard one in Windows IE, in a mode limited by user settings.
The company decided to change the design of the reception protocol, which provides for a header with the output of a specialist’s QR code with a link to a redirect service to the specialist’s personal profile. The placement of the QR code is fixed relative to the bottom of the page on the left and is focused on the size of the print on the A4 format.
As a result of the work carried out, including with the involvement of third-party specialists (2), (3), it turned out that when laying out the template, it is WebKit, which is built into the releases of the 1C 8.3.18 platform, that does not work with placing the footer in the specified positions.
Detailed description of the task
First of all, our database implies the absence of any script in the HTML form prepared for protocol printing, the absence of any interactive interaction. The user has already formed everything in 1C forms, filled in the necessary data.
In terms of HTML page generation, it should be noted that in the database configuration there is a Document object “Reception protocol” and a Directory object “Protocol templates”, in which the developers worked out in sufficient detail the formation of HTML template fields from the protocol data.
The structure of the directory determines the filling of the screen form of the “Reception protocol” document, while the form elements with all handlers are generated from the template modules, and are not elements of the form itself. Figure 1 shows the form in the configurator superimposed on the form of the real reception protocol.
The protocol display form in HTML is implemented by a separate object. Figure 2 shows its markup. Everything is implemented by standard 1C form elements, and CTRL + P is not intercepted and performs a standard call to the “Print” command, but the print link buttons refer to another form command for printing. The “Print” button at the top is always hidden, apparently, it should serve as an interceptor for pressing CTRL + P.
It is impossible to edit the text in the output field, only scrolling and printing. In addition, it is forbidden to use CTRL+P, so the user interface requires at least two extra clicks when outputting:
after clicking on the “print” button of the protocol, there is a transition to the short protocol tab, which is given to the client. The full protocol is not printed, but transferred by means of configuration in an HTML file to the protocol repository of the Electronic Medical Record (EMC);
press the link button to print in the header of the protocol;
In the implemented algorithm, there is no A4 print preview, only a standard 1C printer selection and settings dialog.
I questioned the need for the “PrintProtocol” form in the configuration as an object. In the future, this doubt grew into confidence and made it possible to reduce the number of specialist clicks when printing the reception protocol.
Description of the operation of the protocol generation algorithm
The procedure for generating data filling from the document “Reception protocol” obtains data and settings of the current template that was used when generating the document;
From the template, the generating procedure receives tags for each field, in which it wraps the text of the field;
The output is made starting from the “Header” fields of the template, there may be several of them, then the “Body” fields of the template, then the “Footer” fields, there are also several of them, according to the formats configured in the template.
The HTML string obtained in paragraphs 1-3 is called into a procedure that takes an HTML template and, by replacing strings, inserts a header, body, and footer into the strings configured in the HTML template.
The HTML template has formats for displaying HTML and printing.
Start of implementation. Changing the template filling algorithm
In the logic implemented in the Directory “Templates of Protocols” there is absolutely no possibility to mark one of the headers as the header, as well as to mark one of the footers as the footer. Therefore, it was decided to implement the elements of the new design as follows:
Display the protocol header in theof the HTML template in the form of a table with the replacement of templates of the line like “–NameToReplace–” with the current template data;
Display the generated “Header” and “Body” of the protocol in the HTML template in the table in the;
Display “Footer” in a table in the
Wrap the footer in ausing a print style that will repeat the output of the