Módulos generales 1C- un objeto de metadatos de configuración 1C 8.3 y 8.2, que almacena el código del programa que a menudo se llama en la configuración. Se puede llamar a una función/procedimiento desde cualquier lugar de la configuración (si se exporta).

Cómo usar el módulo compartido

Es una buena práctica poner un procedimiento o función en un módulo común si se llama en más de un lugar. Primero, si se corrige un procedimiento, solo se debe corregir en un lugar. En segundo lugar, consigue un mayor orden en el código.

Un ejemplo típico de un módulo común es el procesamiento de la publicación de acuerdo con algún registro, obtener el monto de la diferencia en días hábiles, convertir tipos de cambio, volver a calcular la cantidad/precio/importe en la sección tabular y otras funciones.

Propiedades generales del módulo

Una de las principales diferencias entre los módulos compartidos y otros módulos es que no puede declarar variables compartidas.

Obtenga lecciones en video de 267 1C gratis:

Echemos un vistazo más de cerca a la paleta de propiedades del módulo común:

• Global- si se establece la bandera, las funciones y los procedimientos de este módulo estarán disponibles en el contexto global. Aquellas. se pueden llamar en cualquier parte de la configuración sin el nombre del módulo común. Sin embargo, se agrega una condición: los nombres de los procedimientos y funciones en este módulo común deben ser únicos dentro del contexto global.
• Servidor- Los procedimientos y funciones de este módulo común se pueden ejecutar en el servidor.
• Unión exterior- los códigos de programa de este módulo común se pueden ejecutar cuando se conectan mediante una fuente externa (por ejemplo, COM).
• Cliente (aplicación administrada)— Los procedimientos y funciones de este módulo común se pueden usar en un cliente pesado en el modo de aplicación administrada.
• Cliente (aplicación regular)— los códigos de programa de este módulo común se pueden usar en el cliente pesado en el modo de aplicación normal.
• llamada del servidor- una bandera que permite al cliente utilizar los procedimientos y funciones de este módulo común.
• - si se establece en Verdadero, la verificación de derechos de acceso se desactivará en este módulo común.
• Reutilizar— determina la configuración de los valores devueltos, si la opción está habilitada, luego de la primera ejecución, el sistema recordará el valor de estos parámetros de entrada y devolverá un valor preparado. Puede tomar los siguientes valores: no utilizado- apagar, en el momento de la llamada- durante la duración de un determinado procedimiento, durante la sesión- hasta que el usuario haya cerrado la sesión (programa).

Si estás empezando a aprender programación 1C, te recomendamos nuestro curso gratuito (no olvides

1.1. Se crean módulos comunes para implementar procedimientos y funciones que se combinan según unos criterios. Como regla general, los procedimientos y funciones de un subsistema de configuración (ventas, compras) o procedimientos y funciones de funcionalidad similar (trabajo con cadenas, propósito general) se colocan en un módulo común.

1.2. Al desarrollar módulos compartidos, debe elegir uno de los cuatro contextos de ejecución de código:

2.1. Módulos comunes del servidor están destinados a alojar procedimientos y funciones del servidor que no están disponibles para su uso desde el código del cliente. Implementan toda la lógica de negocio del servidor interno de la aplicación.
Para que la configuración funcione correctamente en conexión externa, los modos de aplicación administrados y regulares, los procedimientos y funciones del servidor deben colocarse en módulos comunes con las siguientes características:

• Servidor(caja llamada del servidor cayó),
• Cliente (aplicación regular),
• Unión exterior.

En este caso, se garantiza que los procedimientos y funciones del servidor se pueden llamar con parámetros de tipo mutable (por ejemplo, DirectoryObject, ObjetoDocumento etc.). Por regla general, esto es:

• manejadores para suscripciones a eventos de documentos, directorios, etc., que toman un valor mutable (objeto) como parámetro.
• procedimientos y funciones del servidor, al que se le pasa un objeto como parámetro desde módulos de directorios, documentos, etc., así como desde módulos con suscripciones a eventos.

Los módulos comunes del servidor se nombran de acuerdo con las reglas generales para nombrar objetos de metadatos.
Por ejemplo: Trabajar con archivos, Propósito general

En algunos casos, se puede agregar un sufijo para evitar conflictos de nombres con las propiedades de contexto global. "Servidor".
Por ejemplo: Servidor de tareas programadas, Servidor de intercambio de datos.

2.2. Módulos comunes del servidor a llamar desde el cliente contienen procedimientos y funciones de servidor disponibles para su uso desde el código del cliente. Constituyen la API de cliente del servidor de aplicaciones.
Dichos procedimientos y funciones se colocan en módulos comunes con el atributo:

• Servidor(caja llamada del servidor colocar)

Los módulos comunes del servidor que se llamarán desde el cliente se nombran de acuerdo con las reglas generales para nombrar objetos de metadatos y deben nombrarse con un sufijo "Llamada al servidor".
Por ejemplo: Trabajar con archivosLlamar al servidor

Tenga en cuenta que los procedimientos y funciones de exportación en dichos módulos comunes no deben contener parámetros de tipo mutable ( DirectoryObject, ObjetoDocumento etc.), ya que su transferencia desde (o hacia) el código de cliente es imposible.

Ver también:Restricción en la configuración del indicador "Llamada del servidor" para módulos comunes

2.3. Módulos compartidos del cliente contener la lógica de negocio del cliente (funcionalidad definida solo para el cliente) y tener las siguientes características:

• Cliente (aplicación administrada)
• Cliente (aplicación regular)

La excepción es cuando los procedimientos y funciones del cliente solo deben estar disponibles en el modo de aplicación administrada (solo en el modo de aplicación normal o solo en el modo de salida). En tales casos, es aceptable otra combinación de estas dos características.

Los módulos comunes del cliente se nombran con un sufijo "Cliente".
Por ejemplo: TrabajoArchivosCliente, Propósito GeneralCliente

Ver también: minimizar el código del lado del cliente

2.4. En algunos casos, es posible crear módulos comunes cliente-servidor con procedimientos y funciones, cuyo contenido es el mismo tanto en el servidor como en el cliente. Dichos procedimientos y funciones se ubican en módulos comunes con características:

• Cliente (aplicación administrada)
• Servidor(caja llamada del servidor cayó)
• Cliente (aplicación regular)
• Unión exterior

Los módulos comunes de este tipo se nombran con un sufijo "Servidor de cliente".
Por ejemplo: TrabajoArchivosCliente, Propósito generalClienteServidor

En general, no se recomienda definir módulos comunes para el servidor y el cliente (aplicación administrada) al mismo tiempo. Se recomienda implementar la funcionalidad definida para el cliente y para el servidor en diferentes módulos comunes - ver pág. 2.1 y 2.3. Esta separación explícita de la lógica comercial del cliente y el servidor está dictada por consideraciones de aumentar la modularidad de la solución aplicada, simplificar el control del desarrollador sobre la interacción cliente-servidor y reducir el riesgo de errores debido a las diferencias fundamentales en los requisitos para desarrollar el cliente y el servidor. código (la necesidad de minimizar el código ejecutado en el cliente, diferente disponibilidad de objetos y tipos de plataforma, etc.). Al mismo tiempo, hay que tener en cuenta el inevitable aumento del número de módulos comunes en la configuración.

Un caso especial de módulos mixtos de cliente-servidor son los módulos de formulario y comando, que están diseñados específicamente para implementar la lógica comercial del servidor y del cliente en un solo módulo.

3.1. Se recomienda construir los nombres de los módulos comunes de acuerdo con las reglas generales para nombrar objetos de metadatos. El nombre de un módulo común debe coincidir con el nombre de un subsistema o un mecanismo separado cuyos procedimientos y funciones implementa. Se recomienda evitar palabras comunes como "Procedimientos", "Funciones", "Manejadores", "Módulo", "Funcionalidad", etc. en los nombres de los módulos comunes. y aplicarlos sólo en casos excepcionales, cuando revelen más plenamente el propósito del módulo.

Para distinguir entre módulos comunes de un subsistema que se crean para implementar procedimientos y funciones realizadas en diferentes contextos, se recomienda darles los sufijos descritos anteriormente en los párrafos. 2.1-2.4.

En las nuevas versiones de las configuraciones del sistema 1C:Enterprise, muchas funciones y procedimientos se han trasladado de módulos de objetos (documentos, directorios, etc.) a módulos de gestión. Echemos un vistazo a las diferencias entre estos dos módulos.

Según la teoría de la programación orientada a objetos, los métodos de los objetos se dividen en dos grupos: estáticos y simples. Los métodos simples solo tienen acceso a una instancia específica de la clase. Los métodos estáticos no tienen acceso a los datos del objeto, pero operan en la clase como un todo.

Si traducimos todo esto en términos del sistema 1C: Enterprise, entonces módulo de objetos contiene métodos simples. Para usarlos, primero debe obtener un objeto específico: un elemento de un directorio, documento, etc. Módulo Administrador contiene métodos estáticos. Para usarlo, no es necesario obtener por separado cada objeto específico, le permite trabajar con toda la colección a la vez.

módulo de objetos puede tener procedimientos y funciones que se pueden utilizar externamente. Para ello, dicho procedimiento o función se denota con la palabra Exportar.

Función NewFunction() Exportar

Para usar una función de este tipo desde un módulo de objeto, primero debe tener una referencia al objeto requerido, obtenerlo usando la función ObtenerObjeto().

Por= Objeto. NuevaFuncion() ;

De manera similar, puede crear nuevas variables que se pueden usar desde varios objetos de configuración.

Exportación de variable nueva variable

DirectoryItem = Directorios. Nomenclatura. BuscarPorCódigo("000000001" );
Objeto = Elemento de directorio. ObtenerObjeto() ;
Un objeto. NuevaVariable= ) ;

Por lo tanto, es posible complementar los procedimientos estándar, funciones y propiedades (variables) de los objetos. Tales variables son dinámicas, no se almacenan en la base de datos y existen solo mientras se trabaja con el objeto recibido.

Módulo Administrador tiene todas las mismas características, la única diferencia es que no necesita obtener un objeto específico para usarlo, el módulo administrador le permite trabajar con toda la colección de objetos de un tipo determinado.

Procedimiento NewProcedure() Exportar

DirectoryItem = Directorios. Nomenclatura. NuevoProcedimiento() ;

O para una variable:

Exportación de variable nueva variable

DirectoryItem = Directorios. Nomenclatura. nuevaVariable;

Considere las diferencias en el uso del módulo de objeto y el módulo de administrador utilizando el procedimiento para crear un documento imprimible como ejemplo.

Al usar el módulo de objeto, el código se vería así:

Función ImprimirDocumento (Enlace) Exportar
//A esta función se le debe pasar un enlace a un documento específico
Devolver TabDoc;
funciones finales

En el formulario del documento, debe crear un procedimiento que pase un enlace al documento a la función de impresión.

&EnCliente
Procedimiento Imprimir (Comando)
TabDoc = ImprimirEnServidor() ;
TabDoc. Show() ;
Procedimiento final
&En el servidor
Función ImprimirEnServidor()
Doc = FormAttributeToValue("Objeto" ) ;
Devolver doc. ImprimirDocumento(Objeto. Enlace) ;
funciones finales

La desventaja de este método es que solo le permite imprimir un objeto. Si necesita imprimir varios documentos a la vez, debe obtener cada uno de ellos y luego llamar a la función desde el módulo de objetos. Esto requiere importantes recursos del sistema, ya que cuando se recibe un objeto, cabe por completo en la memoria RAM.

Desde el punto de vista del rendimiento, es mucho mejor utilizar el módulo de administrador siempre que sea posible. En nuestro ejemplo, la solución al problema se verá así.
Función ImprimirEnServidor()
Documentos de devolución. NuestroDocumento. ImprimirDocumento(ArrayReferences) ;
funciones finales

En el caso de usar el módulo administrador, el procedimiento de impresión se puede llamar tanto desde el formulario del documento como desde el formulario de la lista, pasando enlaces a varios documentos en la matriz. En este caso, el sistema no necesita recibir cada documento de la matriz, lo que ahorra recursos del sistema de manera significativa.

Entonces, ¿cuándo debería usar el módulo de objeto y cuándo debería usar el módulo de administrador?

Todo depende de la tarea. Si una referencia a un objeto es suficiente para su ejecución (por ejemplo, una tarea de impresión), entonces es mejor usar el módulo administrador. Si la tarea es cambiar los datos, por ejemplo, completar un documento, entonces debe obtenerlo y usar el módulo de objetos.

Los módulos del programa contienen código ejecutable en lenguaje 1C, el cual es necesario para responder de cierta manera a las acciones del sistema o del usuario cuando las herramientas de desarrollo visual no son suficientes. También en los módulos del programa podemos describir nuestros propios métodos (procedimientos y funciones).

Por lo general, un módulo de software consta de tres secciones:

• área de declaración de variables;
• área de descripción de procedimientos y funciones;
• texto principal del programa.

Un ejemplo de la estructura de un módulo de programa:

//******************** ÁREA DE DECLARACIÓN DE VARIABLE ************************

Exportación de apellido Rem; / /esta es una variable global
Nombre de Variable, Patronímico; //esta es una variable de módulo
Cambiar nombre; //esta también es una variable de módulo y se puede acceder a ella

//desde cualquier procedimiento y función de nuestro módulo

//*************** ÁREA DE DESCRIPCIÓN DE PROCEDIMIENTOS Y FUNCIONES ****************

Procedimiento Procedimiento1 ()
Total variable; / /Total es una variable local (variable de procedimiento)

Total = Apellido + "" + Nombre + " "+ Patronímico;

Procedimiento final

Función Función1 ()

// sentencias de función

Return(Apellido + " " + Nombre );

funciones finales

//**************************** TEXTO PRINCIPAL DEL PROGRAMA ******************* *

Apellido = "Ivánov";
Nombre = "Iván";
Segundo nombre = "Ivanovich";

//******************************************************************************

En un módulo de programa en particular, puede faltar alguna de las áreas.
Ámbito de declaración de variables se coloca desde el comienzo del texto del módulo hasta la primera declaración del procedimiento o la declaración de función o cualquier declaración ejecutable. Esta sección solo puede contener sentencias de declaración de variables.

Descripción área de procedimientos y funciones se coloca desde la primera declaración de un procedimiento o una declaración de función a cualquier declaración ejecutable fuera del cuerpo de una declaración de procedimiento o función.

Área de texto del programa principal se coloca desde la primera instrucción ejecutable fuera del cuerpo de procedimientos o funciones hasta el final del módulo. Esta sección solo puede contener sentencias ejecutables. El área del texto principal del programa se ejecuta en el momento de la inicialización del módulo. Por lo general, en la sección principal del programa, tiene sentido colocar declaraciones para inicializar variables con algunos valores específicos que deben asignarse antes de la primera llamada a los procedimientos o funciones del módulo.

Los módulos del programa están ubicados en aquellos lugares de la configuración que pueden requerir la descripción de algoritmos de operación específicos. Estos algoritmos deben diseñarse como procedimientos o funciones que serán llamados por el propio sistema en situaciones predeterminadas (por ejemplo, al abrir un formulario de referencia, al hacer clic en un botón en un cuadro de diálogo, al cambiar un objeto, etc.).

Cada módulo de programa separado es percibido por el sistema como un todo, por lo que todos los procedimientos y funciones del módulo de programa se ejecutan en un solo contexto.

El contexto de ejecución de los módulos se divide en contextos de cliente y servidor. Además, algunos módulos de software se pueden compilar tanto del lado del cliente como del lado del servidor.

Módulo de aplicación (administrado o regular)

El módulo de aplicación describe los procedimientos (manejadores) de eventos que se inicializan al principio y al final del sistema. Por ejemplo, cuando inicia una aplicación, puede actualizar algunos datos de configuración y, cuando sale, puede preguntar si debe salir del programa. Además, este módulo intercepta eventos de equipos externos, como equipos comerciales o fiscales. Vale la pena señalar que el módulo de la aplicación se ejecuta solo en el caso de un inicio interactivo de la aplicación, es decir, cuando se inicia la ventana del programa. Esto no sucede si la aplicación se inicia en modo conexiones de comunicación.
Hay dos módulos de aplicación diferentes en la plataforma 1C 8. Estos son el módulo de aplicación común y el módulo de aplicación administrada. Se activan cuando se inician diferentes clientes. Por ejemplo, el módulo de aplicación administrada se activa cuando se inicia el cliente web, cliente ligero y cliente pesado en modo de aplicación administrada. Y el módulo de aplicación regular se activa cuando el cliente grueso se inicia en el modo de aplicación normal. La configuración del modo de inicio de la aplicación se establece en la propiedad de configuración "Modo de inicio principal".

El módulo de aplicación puede contener las 3 secciones: declaraciones de variables, descripciones de procedimientos y funciones, así como el texto principal del programa. El módulo de la aplicación se compila en el lado del cliente, lo que nos restringe severamente de usar muchos tipos de datos. Puede ampliar el contexto de un módulo de aplicación con los métodos de módulos compartidos que tienen establecida la propiedad Call Server. Todas las variables y métodos del módulo del programa de aplicación marcados como exportación estarán disponibles en cualquier módulo de configuración del lado del cliente. Sin embargo, por muy tentador que sea, no debe colocar una gran cantidad de procedimientos y funciones aquí. Cuanto más código haya en un módulo determinado, mayor será el tiempo de compilación y, en consecuencia, el tiempo de inicio de la aplicación.

Como se señaló anteriormente, el módulo de la aplicación maneja los eventos de inicio y fin de la aplicación. Para manejar cada uno de estos eventos en el módulo de la aplicación, hay un par de controladores Antes... y Cuando... Las diferencias entre ellos son las siguientes: cuando se ejecuta el código en el controlador Antes..., la acción tiene aún no ha tenido lugar y podemos negarnos a ejecutarlo. Para esto es la opción de rechazo. En los controladores On, la acción ya ha tenido lugar y no podemos negarnos a iniciar la aplicación o salir de ella.

Módulo de conexión externo

• puede contener las 3 áreas
• ubicado en la sección raíz de la configuración

El propósito del módulo es similar al propósito del módulo de aplicación. Maneja los eventos de inicio y finalización de la aplicación. El módulo de conexión externa se activa cuando la aplicación se inicia en el modo de conexión com. El proceso de unión externa en sí mismo no es un proceso interactivo. En este modo, el programa trabaja con base de información y la ventana de la aplicación no se abre, lo que impone ciertas restricciones en el uso de métodos destinados al trabajo interactivo. En este modo, no se pueden utilizar llamadas a formularios de diálogo, avisos y mensajes al usuario, etc. Simplemente no se ejecutarán.

Al igual que en el módulo de la aplicación, las tres áreas están disponibles aquí: declaraciones de variables, descripciones de procedimientos y funciones, así como el texto principal del programa. La principal diferencia con el módulo de la aplicación es que en el modo de conexión com, todo el trabajo con la base de datos ocurre en el lado del servidor, por lo que el módulo de conexión externa se compila en el lado del servidor. En consecuencia, las variables de exportación y los métodos de los módulos de clientes comunes no están disponibles en él.

módulo de sesión

• realizado en el lado del servidor
• ubicado en la sección raíz de la configuración

Este es un módulo altamente especializado diseñado únicamente para inicializar los parámetros de la sesión. ¿Por qué necesitabas hacer tu propio módulo para esto? Su uso se debe al hecho de que la aplicación en sí puede iniciarse en varios modos (lo que conduce a la ejecución de un módulo de aplicación administrada, un módulo de aplicación normal o un módulo de conexión externa), y los parámetros de sesión deben inicializarse independientemente de el modo de lanzamiento. Para no escribir el mismo código de programa en los tres módulos, necesitábamos módulo adicional, que se ejecuta independientemente del modo de inicio de la aplicación.

Hay un solo evento "SetSessionParameters" en el módulo de sesión, que se activa primero, incluso antes del evento PreSystemBegin del módulo de aplicación. No tiene una sección de declaración de variables y una sección de programa principal. Y también es imposible declarar métodos de exportación. El módulo se compila en el lado del servidor.

Módulos generales

• puede contener un área para describir procedimientos y funciones
• ejecutado en el lado del servidor o del cliente (depende de la configuración del módulo)
• ubicado en la rama del árbol de objetos de configuración "General" - "Módulos generales"

Los módulos comunes pretenden describir algunos algoritmos comunes que serán llamados desde otros módulos de configuración. El módulo general no contiene áreas de declaración de variables y el cuerpo del programa. Puede declarar métodos de exportación en él, cuya disponibilidad estará determinada por la configuración del módulo (en qué lado se ejecuta: en el servidor o en el lado del cliente). Debido a que la sección de declaración de variables no está disponible, no es posible definir variables globales en módulos compartidos. Puede usar el módulo de aplicación para esto.

El comportamiento del módulo compartido depende de los parámetros establecidos (globales o no, varios indicadores de compilación, si hay una llamada de servidor disponible, etc.). Estos son algunos consejos para configurar módulos compartidos:

Es una buena práctica no usar la bandera "Global" en todas partes. Esto reducirá el tiempo de inicio de la aplicación y mejorará la legibilidad del código (por supuesto, si el módulo común tiene un nombre completamente significativo);
- No es recomendable utilizar más de un flag de compilación. No hay tantos métodos que deban realizarse en diferentes contextos, y si se requieren tales métodos, entonces se les puede asignar un módulo común separado;
- el indicador "Llamada al servidor" solo tiene sentido si el módulo está compilado "En el servidor". Por lo tanto, todos los demás indicadores de compilación deben eliminarse para evitar varios problemas;
- si en los métodos del módulo hay un procesamiento masivo de datos, lectura y escritura en la base de datos, entonces para aumentar la velocidad de trabajo, es mejor deshabilitar el control de acceso configurando el indicador "Privilegiado". Este modo solo está disponible para módulos compartidos compilados en el servidor.

Módulo de formulario

• puede contener las 3 áreas
• realizado en el lado del servidor y del cliente

El módulo de formulario está diseñado para manejar las acciones del usuario con este formulario (manejar el evento de clic del botón, cambiar el atributo del formulario, etc.). También hay eventos relacionados directamente con el propio formulario (por ejemplo, su apertura o cierre). Los módulos de formas administradas y regulares difieren principalmente en que el módulo formulario administrado claramente separados por el contexto. Cada procedimiento o función debe tener una directiva de compilación. Si no se especifica la directiva de compilación, este procedimiento o función se ejecuta en el lado del servidor. En la forma habitual, todo el código se ejecuta en el lado del cliente.

La estructura del formulario administrado contiene una sección de declaración de variables, descripciones de procedimientos y funciones, y el cuerpo del programa (que se ejecuta cuando se inicializa el formulario). Podemos acceder a eventos de formulario estándar a través de la lista de procedimientos esperados y funciones del formulario (Ctrl+Alt+P), o a través de la paleta de propiedades del propio formulario.

Si el formulario tiene asignado el atributo principal, las propiedades y los métodos del objeto de aplicación utilizado como atributo principal estarán disponibles en el módulo del formulario.

módulo de objetos

• puede contener las 3 áreas
• realizado en el lado del servidor

Este módulo está disponible para la mayoría de los objetos de configuración y está destinado, en general, al procesamiento de eventos directamente relacionados con el objeto. Por ejemplo, eventos de registro y eliminación de objetos, verificación de que los detalles de un objeto estén completos, publicación de un documento, etc.

Algunos eventos de módulos de objetos duplican eventos de módulos de formularios. Por ejemplo, eventos relacionados con el registro. Sin embargo, debe entenderse que los eventos del módulo de formulario solo se ejecutarán en el formulario específico del objeto, es decir, cuando se abra el formulario específico. Y los eventos del módulo del objeto se llamarán en cualquier caso, incluso en el momento del trabajo del programa con el objeto. Por lo tanto, si necesita métodos asociados con un objeto sin estar vinculado a una forma específica del objeto, entonces es mejor usar el módulo de objeto para esto.

Módulo administrador de objetos

• puede contener las 3 áreas
• realizado en el lado del servidor

El módulo administrador de objetos apareció solo a partir de la versión 1C 8.2. El módulo administrador existe para todos los objetos de aplicación y está diseñado para administrar este objeto como un objeto de configuración. El módulo administrador le permite extender la funcionalidad de un objeto introduciendo (escribiendo) procedimientos y funciones que no se refieren a una instancia específica del objeto de la base de datos, sino al objeto de configuración en sí. El módulo administrador de objetos le permite colocar procedimientos y funciones comunes para un objeto determinado y acceder a ellos desde el exterior, por ejemplo, desde el procesamiento (por supuesto, si este procedimiento o función es con la palabra clave Exportar). ¿Qué nos da esto de nuevo? En general, nada más que organizar los procedimientos por objetos y almacenarlos en lugares separados: Módulos de administración de objetos. También podemos colocar estos procedimientos y funciones en módulos comunes, pero 1C recomienda colocar procedimientos y funciones comunes de objetos en el Módulo Administrador de Objetos. Ejemplos de uso de los procedimientos y funciones del Módulo de Administradores de Objetos: llenado inicial de detalles individuales de un directorio o documento bajo ciertas condiciones, verificación del llenado de detalles de un directorio o documento bajo ciertas condiciones, etc.

Módulo de mando

• puede contener una sección que describe procedimientos y funciones
• ejecutado en el lado del cliente

Los comandos son objetos subordinados a los objetos de la aplicación oa la configuración como un todo. Cada comando tiene un módulo de comando en el que puede describir un procedimiento CommandProcess() predefinido para ejecutar ese comando.

¿Qué son los módulos y para qué están destinados exactamente? El módulo contiene el código del programa. Además, vale la pena señalar que, a diferencia de la plataforma 7.7, donde el código podría ubicarse tanto en las propiedades de los elementos del formulario como en las celdas de las tablas de diseño, en la plataforma 8.x, cualquier línea de código debe ubicarse. en algún módulo. Por lo general, un módulo consta de tres secciones: una sección para describir variables, una sección para describir procedimientos y funciones y una sección para el programa principal. Esta estructura es típica para casi todos los módulos de la plataforma, con algunas excepciones. Algunos módulos no tienen una sección de declaración de variables y una sección de programa principal. Por ejemplo, Módulo de Sesión y cualquier Módulo General.

El contexto de ejecución de los módulos generalmente se divide en contextos de cliente y servidor. Además, algunos módulos se pueden compilar tanto del lado del cliente como del lado del servidor. Y algunos son puramente del lado del servidor o del lado del cliente. Asi que:

Módulo de aplicación

El módulo está diseñado para captar los momentos de lanzamiento de la aplicación (carga de configuración) y su finalización. Y en los eventos correspondientes, podrá concertar los trámites de verificación. Por ejemplo, al inicio de la aplicación, actualice cualquier dato de referencia de configuración, al final del trabajo, pregunte si vale la pena dejarlo, tal vez la jornada laboral aún no haya terminado. Además, intercepta eventos de equipos externos, como equipos comerciales o fiscales. Vale la pena señalar que el módulo de la aplicación intercepta los eventos descritos solo en el caso de un lanzamiento interactivo. Aquellas. cuando se crea la propia ventana del programa. Esto no sucede si la aplicación se inicia en modo de conexión com.

Hay dos módulos de aplicación diferentes en la plataforma 8.2. Estos son el módulo de aplicación común y el módulo de aplicación administrada. Se activan cuando se inician diferentes clientes. Así es como se activa el módulo de aplicación administrada cuando el cliente web, el cliente ligero y el cliente pesado se inician en el modo de aplicación administrada. Y el módulo de aplicación regular se activa cuando el cliente grueso se inicia en el modo de aplicación normal.

Todas las secciones se pueden colocar en el módulo de la aplicación: descripciones de variables, procedimientos y funciones, así como descripciones del programa principal. El módulo de la aplicación se compila en el lado del cliente, por lo que esto nos limita severamente en la disponibilidad de muchos tipos de datos. Puede ampliar el contexto de un módulo de aplicación con los métodos de módulos compartidos que tienen establecida la propiedad Call Server. Todas las variables y métodos marcados como exportados estarán disponibles en cualquier módulo de configuración del lado del cliente. Sin embargo, por muy tentador que sea, no ponga demasiados métodos aquí. Cuanto más código contenga, mayor será el tiempo de compilación y, en consecuencia, el tiempo de inicio de la aplicación, lo que resulta muy molesto para los usuarios.

Como se señaló anteriormente, el módulo de la aplicación maneja los eventos de inicio y fin de la aplicación. Para manejar cada uno de estos eventos en el módulo de la aplicación, hay un par de controladores Antes... y Cuando... La diferencia entre ellos es que cuando se ejecuta el código en el controlador Antes..., la acción aún no se ha ejecutado. tenido lugar y podemos negarnos a ejecutarlo. Para esto es la opción de rechazo. En los controladores On, la acción ya ha tenido lugar y no podemos negarnos a iniciar la aplicación o salir de ella.

Módulo de conexión externo

El propósito del módulo es similar al propósito del módulo de aplicación. Maneja los puntos de inicio y finalización de la aplicación. El módulo de conexión externa se activa cuando la aplicación se inicia en el modo de conexión com. El proceso de unión externa en sí mismo no es un proceso interactivo. En este modo, se produce el trabajo programático con la base de datos y la ventana de la aplicación no se abre, lo que impone ciertas restricciones en el uso de métodos destinados al trabajo interactivo. En este modo, no puede usar llamadas de formulario de diálogo, mensajes de advertencia, etc. Simplemente no funcionarán.

Al igual que en el módulo de la aplicación, aquí están disponibles secciones para describir variables, métodos y una sección para el programa principal. También puede declarar variables y métodos de exportación. La diferencia es que en el modo de conexión com, todo el trabajo con la base de datos ocurre en el lado del servidor, por lo que el módulo de conexión externa se compila exclusivamente en el servidor. En consecuencia, las variables de exportación y los métodos de los módulos de clientes comunes no están disponibles en él.

módulo de sesión

Este es un módulo altamente especializado y está destinado únicamente a la inicialización de los parámetros de la sesión. ¿Por qué necesitabas hacer tu propio módulo para esto? Esto se debe a que el proceso de inicialización puede requerir la ejecución de algún código y, además, la aplicación puede iniciarse en diferentes clientes (lo que lleva a la ejecución de varios módulos de aplicación o módulo de conexión externa), y los parámetros de sesión deben ser inicializado en cualquier modo de lanzamiento. Por lo tanto, se requería un módulo adicional, que se ejecuta en cualquier modo de inicio de la aplicación.

Hay un solo evento "SetSessionParameters" en el módulo de sesión, que se activa primero, incluso antes del evento BeforeSystemStart del módulo de la aplicación. No tiene una sección de declaración de variables y una sección de programa principal. Y también es imposible declarar métodos de exportación. El módulo se compila en el lado del servidor.

Evite la tentación de que este módulo se ejecute cada vez que se inicia la aplicación y coloque en él código que no esté directamente relacionado con la inicialización de los parámetros de la sesión. Esto se debe al hecho de que el controlador SetSessionParameters se puede llamar repetidamente durante el funcionamiento del sistema. Por ejemplo, esto sucede cuando accedemos a parámetros no inicializados. Y aunque es posible capturar el momento del primer lanzamiento de este evento (RequiredParameters tiene el tipo Undefined), sin embargo, debe tenerse en cuenta que este módulo está compilado en modo privilegiado, es decir no controla los derechos de acceso. Y el segundo punto, todavía no podemos estar cien por ciento seguros de que el sistema se lanzará. De repente, el módulo de la aplicación fallará y estamos tratando de realizar alguna acción con la base de datos.

Módulos generales

Los módulos pretenden describir algunos algoritmos comunes que serán llamados desde otros módulos de configuración. El módulo general no contiene una sección de declaración de variables y una sección de programa principal. Puede declarar métodos de exportación en él, cuyo contexto de accesibilidad estará determinado por indicadores de compilación. Debido a que la sección de declaración de variables no está disponible, no es posible definir variables globales en módulos compartidos. Para hacer esto, debe usar las funciones de módulos comunes con almacenamiento en caché de valor de retorno o un módulo de aplicación. Debe tenerse en cuenta que incluso si la propiedad de reutilización del módulo compartido se establece en "Durante la duración de la sesión", en este caso, la vida útil de los valores almacenados en caché no supera los 20 minutos desde el momento en que se accedió por última vez. .
El comportamiento del módulo compartido depende de los parámetros establecidos (globales o no, varios indicadores de compilación, si hay una llamada de servidor disponible, etc.). En este artículo, no consideraremos todos los tipos de configuraciones, así como las características de comportamiento y las trampas que surgen cuando las marcas de propiedad se configuran de manera irrazonable. Este es un tema para un artículo aparte. Detengámonos en algunos puntos que deben seguirse al establecer banderas:

• Es una buena regla general no usar la bandera "Global" en todas partes. Esto reducirá el tiempo de inicio de la aplicación y mejorará la legibilidad del código (por supuesto, si el módulo común tiene un nombre completamente significativo).
• No es recomendable utilizar más de un indicador de compilación. No hay tantos métodos que deban realizarse en diferentes contextos, y si tales métodos son necesarios, entonces se les puede asignar un módulo común separado.
• El indicador "Servidor de llamadas" solo tiene sentido si el módulo está compilado "En el servidor". Por lo tanto, todos los demás indicadores de compilación deben eliminarse para evitar varios problemas.
• Si los métodos del módulo se utilizan para el procesamiento masivo de datos, lectura y escritura en la base de datos, entonces, para aumentar la velocidad del trabajo, es mejor deshabilitar el control de acceso configurando el indicador "Privilegiado". Este modo solo está disponible para módulos compartidos compilados en el servidor.

Módulo de formulario

Está destinado a procesar las acciones del usuario, es decir. varios eventos relacionados con la entrada de datos y el procesamiento de la corrección de su entrada. Módulo forma regular compilado completamente en el cliente. Un módulo de formulario administrado, por otro lado, está claramente delimitado por el contexto de ejecución, por lo que todas las variables y métodos deben tener una directiva de compilación. Si la directiva no se especifica explícitamente, esta variable o método se compilará en el lado del servidor. En el módulo de formulario, se encuentran disponibles secciones para describir variables y métodos, así como una sección para el programa principal.

módulo de objetos

Este módulo es típico para muchos objetos de configuración y está diseñado, en general, para procesar eventos de objetos. Por ejemplo, los eventos de escritura y eliminación de objetos, el evento de publicación de documentos, etc.

Algunos eventos de módulos de objetos duplican eventos de módulos de formularios. Por ejemplo, eventos relacionados con el registro. Sin embargo, debe entenderse que los eventos del módulo de formulario solo se ejecutarán en un objeto de formulario en particular. En general, puede haber varias de estas formas. Y los eventos del módulo del objeto se llamarán en cualquier caso, incluso en el momento del trabajo del programa con el objeto. Por lo tanto, si es necesario ejecutar algún código en todos los casos, entonces es mejor usar un evento de módulo de objeto para esto.

El módulo de objeto se compila exclusivamente en el servidor. En él se pueden definir variables y métodos de exportación que estarán disponibles en otros módulos de configuración. Con la ayuda de estas propiedades y métodos, podemos expandir significativamente la funcionalidad del objeto.

Módulo administrador de objetos

Este módulo existe para muchos objetos de configuración. El objetivo principal de este módulo es redefinir el evento de selección estándar que ocurre en el momento de la entrada por línea y ampliar la funcionalidad del administrador. El módulo se compila en el lado del servidor. Es posible definir propiedades y métodos de exportación. Llamar a los métodos de exportación del administrador no requiere la creación del objeto en sí.

A todo lo anterior, puede agregar una imagen de algunos módulos de configuración y métodos de llamadas de métodos mutuos en el modo de aplicación administrada. La flecha indica la dirección en la que puede ir para llamar al método correspondiente. Como puede verse en el diagrama, el contexto del servidor está completamente cerrado. Pero desde el contexto del cliente, es posible acceder a los métodos del servidor.

Símbolos en el esquema: O.M. Cliente - módulo común del cliente; O. M. Servidor: módulo común del servidor; M. F. Cliente - Procedimientos de cliente del módulo de formulario; M. F. Servidor - Procedimientos del servidor del módulo de formulario.