Switches, aplicación regular, formularios gestionados. Switches, aplicación regular, formularios administrados 1c problemas con formularios administrados

La plataforma 1C:Enterprise le permite agregar y cambiar mediante programación elementos de un formulario administrado. Averigüemos por qué podría ser necesario esto.

Es posible que sea necesaria una modificación del software del formulario en varios casos:

• Al finalizar configuraciones estándar para facilitar el procedimiento de actualización posterior. En este caso, sólo se cambiará el módulo del formulario. Los módulos son mucho más fáciles de actualizar que los formularios.
• Al implementar algunos algoritmos comunes. Por ejemplo, en el subsistema "Prohibición de editar detalles de objetos", se puede crear un botón mediante programación para todos los objetos conectados al subsistema para habilitar la capacidad de editar detalles.
• Al implementar algunos algoritmos específicos. Por ejemplo, en el directorio de Nomenclatura, se crean campos para editar detalles adicionales.

En un formulario administrado, puede agregar, cambiar y eliminar mediante programación:

• requisitos;
• equipos locales;
• elementos.

Todas estas operaciones sólo son posibles en el servidor.

La remodelación programática tiene limitaciones:

• Solo puede eliminar detalles/comandos/elementos agregados mediante programación. No puede eliminar mediante programación objetos creados en el configurador.
• No se puede asignar un atributo como principal.

Cambiar comandos de formulario

Para gestionar la composición de comandos de un objeto Formulario administrado hay una colección equipos

Agregar (< ИмяКоманды >)

Cantidad ()

Encontrar (< ИмяКоманды >)

Borrar (< Команда >)

La colección de Teams está disponible tanto en el cliente como en el servidor. Puede cambiar la colección (métodos Add() y Delete()) solo en el servidor. Puede buscar y obtener la cantidad de elementos (los métodos Find () y Count ()) tanto en el cliente como en el servidor.

Como ejemplo de cómo trabajar con comandos de formulario, creemos un nuevo comando ChangeHistory con el encabezado "ChangeHistory...", que llamará al controlador Mostrar historial(). La creación ocurre cuando se abre el formulario.

&En el servidor
Procedimiento WhenCreatingOnServer(Error, procesamiento estándar)
Equipo = Equipos. Agregar( "Historia de cambios");
Equipo . Acción = ;
Equipo . Título = "Historia de cambios...";
Fin del Procedimiento
&EnCliente
Procedimiento Connectable_DisplayHistory (comando)
// acciones de comando
Fin del Procedimiento

El controlador de comandos debe estar ubicado en un formulario y tener una directiva de compilación &OnClient.

Cambiar detalles del formulario

La lectura de la composición de los detalles del formulario se realiza mediante la función. Obtén detalles(< Путь >) que devuelve una matriz de tipo FormAttributes. El parámetro de función especifica la ruta al atributo principal (como una cadena). Si se omite el parámetro o se especifica una cadena vacía, se devuelven los detalles de nivel superior.

El cambio de detalles se realiza mediante el método. Cambiar detalles(<Detalles añadidos>, <Detalles extraíbles>) objeto Formulario administrado. A los parámetros Detalles añadidos Y Detalles extraíbles Se transmiten matrices con elementos del tipo Atributos de formulario.

¡Atención!

El proceso de cambiar la composición de las piezas requiere muchos recursos. En realidad, el formulario se está recreando. En este sentido, el trabajo con los detalles del formulario se realiza por lotes.

Creemos un nuevo atributo de formulario con el nombre Comprador:

AddedDetails = Nueva matriz;
Detalles añadidos. Agregar (nuevos atributos de formulario)(“Comprador”, Descripción del nuevo tipo (“DirectoryLink. Contrapartes”), “Cliente”));

// Cambios en la composición de detalles.
);

Cambiar elementos de formulario

Controlar la composición de los elementos de un objeto. Formulario administrado hay una colección Elementos. La colección tiene varios métodos:

Insertar (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

Agregar (< Имя>, < ТипЭлемента>, < Родитель >)

Cantidad ()

Encontrar (< Имя >)

Mover(< Элемент>, < Родитель>, < МестоРасположения >)

Borrar (< Элемент >)

La colección de elementos está disponible tanto en el cliente como en el servidor. Modificar una colección (Insertar métodos () , Agregar (), Mover () y Eliminar ()) solo están disponibles en el servidor. Puede buscar y obtener la cantidad de elementos (los métodos Find () y Count ()) tanto en el cliente como en el servidor. Los elementos de la colección pueden ser:

• Grupo de formularios;
• Tabla de formularios;
• Campo de formulario;
• Botón de formulario.

Puede asignar mediante programación controladores de eventos a elementos de formulario. El método está destinado a estos fines. Establecer acción (< ИмяСобытия>, < Действие >) .

Veamos algunos de los ejemplos más comunes de trabajo con comandos, detalles y elementos de formulario.

Agregar un comando y su botón asociado:

// Crea un comando
Equipo = Equipos. Agregar( "Historia de cambios");
Equipo . Acción = "Plug-in_DisplayHistory"; // El formulario debe contener un procedimiento con el nombre especificado
Equipo . Título = "Historia de cambios...";
// Crea un botón y lo asocia con un comando
Elemento = Artículos. Agregar( "Historia de cambios", Tipo("FormularioBotón" ));
Elemento.NombreComando = "Historia de cambios";

Agregar un atributo y el campo de entrada asociado:

// Descripción de los detalles agregados
AddedDetails = Nueva matriz;
Detalles añadidos. Agregar(Nuevos accesorios de formulario (“Comprador”, Nueva descripción de tipo ( "DirectoryLink. Contrapartes"), "Cliente" ));
// Cambiando la composición de los detalles.
CambiarDetalles(Detalles agregados);
// Creando un campo de entrada y conectándolo con atributos
Elemento = Artículos. Agregar("Comprador", Tipo("FormField" ));
Elemento . Ver = FormFieldView. Campo de entrada;
Elemento . RutaADatos= "Comprador" ;

Asignar un controlador de eventos a un elemento de formulario:

ArtículoCliente. Establecer acción("Cuando cambia", "Comprador_conectado al cambiar");

&EnCliente
Procedimiento Comprador_conectado al cambiar(Elemento)
// acciones de eventos
Fin del Procedimiento

¡Atención!

Procedimientos que se configuran como controladores de eventos desde el código usando el método Establecer acción(), se recomienda configurar el prefijo Connectable_.

¡Atención!

Puede descargar el procesamiento con ejemplos de búsqueda programática y cambio de detalles, comandos y elementos de un formulario administrado.

Y la transferencia de datos del objeto a la estructuración del código, de forma controlada en el entorno 1C 8.2.

Introducción

Comencemos con una breve descripción del concepto de "formulario administrado" y conceptos relacionados de la plataforma 1C. Es posible que los conocedores de plataformas quieran saltarse esta sección.

En 2008, estuvo disponible una nueva versión de la plataforma 1C: Enterprise 8.2 (en adelante, la Aplicación Administrada), que cambia por completo toda la capa de trabajo con la interfaz. Esto incluye la interfaz de comando, los formularios y el sistema de ventanas. Al mismo tiempo, no sólo cambia el modelo para desarrollar la interfaz de usuario en la configuración, sino que también se propone una nueva arquitectura para separar la funcionalidad entre la aplicación cliente y el servidor.
La aplicación administrada admite los siguientes tipos de clientes:

• Cliente pesado (modo de inicio normal y administrado)
• Cliente ligero
• cliente web

La aplicación administrada utiliza formularios creados con nueva tecnología. Ellos se llaman Formularios administrados. Para facilitar la transición, también se admiten los formularios anteriores (los llamados formularios regulares), pero su funcionalidad no está desarrollada y solo están disponibles en el modo de inicio del cliente pesado.
Las principales diferencias de los formularios administrados para un desarrollador:

• Descripción declarativa, no “píxel por píxel” de la estructura. La ubicación específica de los elementos la realiza automáticamente el sistema cuando se muestra el formulario.
• Toda la funcionalidad del formulario se describe como detalles Y equipos. Los detalles son los datos con los que trabaja el formulario y los comandos son las acciones a realizar.
• El formulario se ejecuta tanto en el servidor como en el cliente.
• En el contexto del cliente, casi todos los tipos de aplicaciones no están disponibles y, por lo tanto, es imposible cambiar los datos en la base de datos.
• Para cada método o variable de formulario, se debe especificar directiva de compilación, definiendo la ubicación de ejecución (cliente o servidor) y el acceso al contexto del formulario.

Enumeremos las directivas para compilar métodos de formulario:

• &EnCliente
• &En el servidor
• &EnServidorSin Contexto
• &OnClientOnServerSin contexto

Ilustremos lo anterior. La captura de pantalla muestra un ejemplo de un formulario administrado y su módulo en modo de desarrollo. Encuentre la descripción declarativa, accesorios, directivas de compilación, etc.

Todas las discusiones posteriores se centrarán en el lado derecho de la ilustración, sobre cómo estructurar el código del módulo y qué principios le permitirán implementar una interacción cliente-servidor eficaz.

Definamos el problema

Han pasado varios años desde que se utiliza activamente la nueva versión de la plataforma 1C y tanto 1C como sus numerosos socios han lanzado muchas soluciones (configuraciones).
Durante este tiempo, ¿los desarrolladores han desarrollado una comprensión común de los principios de la interacción cliente-servidor al crear formularios y ha cambiado el enfoque para implementar módulos de software en las nuevas realidades arquitectónicas?

Veamos la estructura del código (módulo de formulario) en varios formularios de la misma configuración estándar e intentemos encontrar patrones.
Por estructura nos referimos a secciones de código (la mayoría de las veces son bloques de comentarios) asignadas por el desarrollador para agrupar métodos y directivas de compilación para estos métodos.
Ejemplo 1:
Sección de controladores de eventos Método - en el cliente Método - en el servidor Método - en el cliente Sección de procedimientos y funciones de servicio Funciones de control de entradas auxiliares
Ejemplo 2:
Procedimientos y funciones del servicio Documentos de pago Valores Manejadores de eventos
Ejemplo 3:
Procedimientos de servicio en el servidor Procedimientos de servicio en el cliente Procedimientos de servicio en el servidor sin contexto Manejadores de eventos de encabezado Manejadores de eventos de comando
Ejemplo 4:
Procedimientos de propósito general Manejadores de eventos de formulario Procedimientos del subsistema de “información de contacto”
Esencialmente, falta la estructura del código o, para decirlo suavemente, es similar a la que había en Forms 8.1:

• Palabras no informativas “General, Servicio, Auxiliar”.
• Intentos tímidos de separar los métodos de cliente y servidor.
• Los métodos a menudo se agrupan por elementos de la interfaz "Trabajar con la parte tabular Productos, Información de contacto".
• Disposición arbitraria de métodos y grupos de códigos. Por ejemplo, los controladores de eventos pueden estar en la parte superior en un formulario, en la parte inferior en otro, no resaltados en absoluto en un tercero, etc.
• Y no olvidemos que todo esto está dentro de una configuración.
• Sí, hay configuraciones en las que las palabras “General, Servicio, Auxiliar” siempre están en el mismo lugar pero...

¿Por qué necesitas una estructura de código?

• Simplificación del mantenimiento.
• Simplifica el aprendizaje.
• Registrar principios generales/importantes/exitosos.
• ...tu opción

¿Por qué no ayuda el estándar de desarrollo existente de 1C?

Veamos los principios publicados en los discos ITS y en varias "Guías para desarrolladores..." que se recomiendan al escribir un formulario administrado.

• Minimizar el número de llamadas al servidor.
• Computación máxima en el servidor.
• Las llamadas al servidor no contextuales son más rápidas que las contextuales.
• Programa pensando en la comunicación cliente-servidor.
• etcétera.

Son consignas absolutamente ciertas, pero ¿cómo implementarlas? ¿Cómo minimizar el número de llamadas, qué significa programar en modo cliente-servidor?

Patrones de diseño o sabiduría generacional

La interacción cliente-servidor se ha utilizado en diversas tecnologías de software durante décadas. La respuesta a las preguntas planteadas en la sección anterior se conoce desde hace mucho tiempo y se resume en dos principios básicos.

• Fachada Remota(en adelante denominada Interfaz de acceso remoto)
• Objeto de transferencia de datos(en adelante denominado Objeto de transferencia de datos)

Unas palabras de Martin Fowler, su descripción de estos principios:

• … Cada objeto potencialmente destinado al acceso remoto debe tener interfaz de baja granularidad, lo que minimizará el número de llamadas necesarias para realizar un trámite específico. ... En lugar de solicitar una factura y todos sus elementos por separado, debe leer y actualizar todos los elementos de la factura en una sola solicitud. Esto afecta a toda la estructura del objeto...Recuerde: interfaz de acceso remoto no contiene lógica de dominio.
• ...si fuera una madre cariñosa, definitivamente le diría a mi hijo: "¡Nunca escribas objetos de transferencia de datos!" En la mayoría de los casos, los objetos de transferencia de datos no son más que conjunto de campo hinchado... El valor de este repugnante monstruo radica únicamente en la posibilidad transmitir múltiples piezas de información a través de la red en una sola llamada- una técnica que es de gran importancia para los sistemas distribuidos.

Ejemplos de plantillas en la plataforma 1C.

La interfaz de programación de aplicaciones disponible para el desarrollador cuando desarrolla un formulario administrado contiene muchos ejemplos de estos principios.
Por ejemplo, el método OpenForm(), una típica interfaz "aproximada".
Parámetros de apertura = Nueva estructura ("Parámetro1, Parámetro2, Parámetro3", Valor1, Valor2, Valor3); Formulario = OpenForm(Nombre del formulario, Parámetros de apertura);
Compárese con el estilo adoptado en v8.1.
Formulario = GetForm(Nombredelformulario); Formulario.Parámetro1 = Valor1; Formulario.Parámetro2 = Valor2; Formulario.Open();

En el contexto de un formulario administrado, existen muchos "Objetos de transferencia de datos". Puedes elegir sistémico Y definido por el desarrollador.
Los de sistema modelan un objeto de aplicación en el cliente, en forma de uno o más elementos de datos de formulario. Es imposible crearlos sin consultar los detalles del formulario.

• Estructura de formularios de datos
• Colección de formularios de datos
• Estructura de formulario de datos con colección
• DatosFormasÁrbol

La conversión de objetos de transferencia de datos del sistema a tipos de aplicaciones y viceversa se realiza mediante los siguientes métodos:

• ValorEnFormDatos()
• FormularioDatosValor()
• Copiar datos del formulario()
• ValorEnFormAtributos()
• ValorAtributosForm()

A menudo se utiliza la conversión explícita al adaptar una solución existente. Los métodos pueden esperar (usar funciones) parámetros de entrada, como ValueTable en lugar de FormDataCollection, o el método se ha definido en el contexto de un objeto de aplicación y no está disponible para una llamada directa desde el formulario.
Ejemplo 1C v8.1:
// en el cliente en el contexto del formulario FillUserCache(DepartmentLink)
Ejemplo 1C v8.2:
// en el servidor en el contexto del formulario ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Objeto");

Los objetos de transferencia de datos, cuya estructura la determina el desarrollador, son un pequeño subconjunto de los tipos disponibles tanto en el cliente como en el servidor. Muy a menudo, se utilizan los siguientes como parámetros y resultados de los métodos de una interfaz "gruesa":

• Tipos primitivos (cadena, número, booleano)
• Estructura
• Correspondencia
• Formación
• Enlaces a objetos de la aplicación (identificador único y representación de texto)

Ejemplo: el método acepta una lista de pedidos para cambiar de estado y devuelve una descripción de los errores al cliente.
&OnServerWithoutContext Función ServerChangeOrderStatus(Orders, NewStatus) Errores = Nueva coincidencia(); // [pedido][descripción del error] Para cada pedido del ciclo de pedidos StartTransaction(); Pruebe DocOb = Order.GetObject(); …. otras acciones, posibles no sólo con la orden... Excepción CancelTransaction(); Errores.Insert(Orden, ErrorDescription()); intento final; Fin del ciclo; Error de devolución; Función final // ServerChangeOrderStatus()

Estructurando el código

Los principales objetivos que debe reflejar el módulo de formulario administrado y enfoques para la solución.

• Separación clara del código de cliente y servidor. No olvidemos que en el momento de la ejecución se trata de dos procesos que interactúan, cada uno de los cuales tiene una funcionalidad disponible significativamente diferente.
• Identificación clara de la interfaz de acceso remoto, ¿qué métodos de servidor se pueden llamar desde el cliente y cuáles no? Los nombres de los métodos de interfaz remota comienzan con el prefijo "Servidor". Esto le permite ver inmediatamente la transferencia de control al servidor mientras lee el código y simplifica el uso de la ayuda contextual. Tenga en cuenta que la recomendación oficial (ITS) sugiere nombrar métodos con sufijos, por ejemplo, ChangeOrderStatusOnServer(). Sin embargo, repetimos que no todos los métodos del servidor se pueden llamar desde el cliente y, por lo tanto, la accesibilidad lógica es más importante que la ubicación de compilación. Por lo tanto, con el prefijo “Servidor” marcamos sólo los métodos disponibles para el cliente; llamemos al método de ejemplo ServerChangeOrderStatus().
• Legibilidad. Cuestión de gustos, aceptamos el pedido cuando el módulo comienza con los procedimientos de creación de un formulario en el servidor y métodos de acceso remoto.
• Mantenibilidad. Debe haber una ubicación clara para agregar código nuevo. Un punto importante es que las plantillas de métodos creadas automáticamente por el configurador se agregan al final del módulo. Dado que los controladores de eventos para elementos de formulario suelen crearse automáticamente, el bloque correspondiente se ubica en último lugar, para no arrastrar cada controlador a otro lugar del módulo.

A continuación se muestra la estructura básica del módulo que implementa los objetivos enumerados.

• Opción gráfica: muestra claramente el flujo principal de ejecución.
• La opción de texto es un ejemplo de diseño de plantilla para insertar rápidamente una estructura en un nuevo módulo de formulario.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Fecha=""/> // <Описание> // // ///////////////////////////////////////////////// // /////////////////////////// // VARIABLES DEL MÓDULO ///////////////// // /////////////////////////////////////////////// //// ////////// // EN EL SERVIDOR //******* EVENTOS EN EL SERVIDOR ******* &En el procedimiento del servidor cuando se crea en el servidor (fallo, procesamiento estándar) / /Insertar el contenido del handler Fin del Procedimiento //******* INTERFAZ DE ACCESO REMOTO ******* //******* LÓGICA DE NEGOCIO EN EL SERVIDOR ******* ///////// ///////////////////////////////////////// /////// //////////////////// // MÉTODOS COMUNES DE CLIENTE Y SERVIDOR /////////////// /////// //////////////////////////////////////////// ///// //////// // EN EL CLIENTE //******* LÓGICA DE NEGOCIO EN EL CLIENTE ******* //********* EQUIPO * ****** //******* EVENTOS DEL CLIENTE ******* /////////////////////////// ///// ////////////////////////////////////////////// // / / PRINCIPALES OPERADORES DEL PROGRAMA

Preguntas relacionadas

En conclusión, describiremos varias áreas en las que es útil pensar al programar la interacción cliente-servidor.

• Opciones de implementación de la interfaz de acceso remoto. Asincronía, nivel de detalle...
• Almacenamiento en caché. 1C tomó una decisión arquitectónica fallida al introducir el almacenamiento en caché solo en el nivel de llamar a métodos de módulos comunes y no proporcionar capacidades de control (tiempo de relevancia, reinicio bajo demanda).
• Llamadas implícitas al servidor. No se olvide de las características tecnológicas: muchas operaciones "inofensivas" en el cliente provocan que la plataforma contacte al servidor.

Formularios en 1C:Enterprise están destinados a mostrar y editar información contenida en la base de datos. Los formularios pueden pertenecer a objetos de configuración específicos o existir por separado de ellos y son utilizados por toda la solución de la aplicación.

Por ejemplo, un directorio Nomenclatura puede tener varios formularios que se utilizarán para propósitos específicos: editar un elemento del directorio, mostrar una lista, etc.:

Junto con esto, pueden aparecer formularios generales que no pertenecen a objetos de configuración específicos: formularios generales.

Formas básicas

Cada objeto de configuración se puede utilizar para realizar algunas acciones estándar. Por ejemplo, para cualquier directorio es posible que necesite mostrar una lista de sus elementos, mostrar elementos individuales del directorio, mostrar un grupo del directorio, seleccionar elementos y grupos de elementos del directorio. Para cualquier documento, la lista de tales acciones será mucho más pequeña: ver una lista de documentos, seleccionar de una lista de documentos y ver un documento separado.

Para garantizar que dichas acciones estándar se realicen con los datos de los objetos de la solución de la aplicación, para cada uno de ellos existe un conjunto de formularios básicos que se utilizarán al realizar las acciones correspondientes. Cualquiera de las formas subordinadas a este objeto puede asignarse como principal. Por ejemplo, en el directorio Nomenclatura Pueden existir las siguientes formas básicas:

y el documento Recepción de bienes y servicios. la composición de las formas principales será diferente:

Por lo tanto, si el usuario desea ver la lista del directorio Nomenclatura o lista de documentos Recepción de bienes y servicios., el sistema abrirá el formulario correspondiente designado como formulario de lista para estos objetos.

Formularios generados automáticamente

Una característica importante del sistema 1C:Enterprise 8 es el mecanismo de formularios generados automáticamente. Este mecanismo libera al desarrollador de tener que crear todas las formas posibles para cada objeto de configuración. El desarrollador sólo necesita agregar un nuevo objeto de configuración, y el propio sistema generará, en los momentos adecuados del trabajo del usuario, los formularios necesarios para mostrar la información contenida en este objeto.

Por lo tanto, el desarrollador necesita crear sus propios formularios de objetos de solución de aplicación sólo si deben tener diferencias (diseño diferente o comportamiento específico) de los formularios generados automáticamente por el sistema.

Vincular un formulario a datos

Si un formulario pertenece a un objeto de configuración particular no determina la composición de los datos que se muestran en el formulario. El hecho de que el formulario pertenezca, por ejemplo, a un directorio Nomenclatura, le permite asignarlo como uno de los formularios principales para este directorio, pero de ninguna manera determina qué datos mostrará este formulario y cuál será su comportamiento.

Para asociar un formulario con datos, se utilizan los detalles del formulario, que indican la lista de datos que muestra el formulario. Todos los formularios, en sí mismos, tienen el mismo comportamiento, independientemente de los datos que muestren. Sin embargo, uno de los atributos del formulario puede designarse como su atributo principal (está resaltado en negrita), en cuyo caso el comportamiento estándar del formulario y sus propiedades se complementarán dependiendo del tipo que tenga el atributo principal del formulario:

Por ejemplo, si se asigna un documento como atributo de formulario principal Recepción de bienes y servicios., luego al cerrar el formulario, el sistema solicitará confirmación del registro y publicación de este documento. Si asigna, digamos, un directorio como atributo principal del formulario Nomenclatura, entonces dicha solicitud de confirmación no aparecerá al cerrar el formulario.

Estructura del formulario

La característica principal de los formularios es que el desarrollador no los dibuja en detalle, "píxel a píxel". Un formulario en una configuración es una descripción lógica de la composición del formulario. Y la ubicación específica de los elementos la realiza automáticamente el sistema cuando se muestra el formulario.

La parte mostrada del formulario (visible para el usuario) se describe como un árbol que contiene elementos del formulario.

Los elementos pueden ser campos de entrada, casillas de verificación, botones de opción, botones, etc. Además, un elemento puede ser un grupo que incluya otros elementos. Un grupo se puede representar como un panel con un marco, un panel con páginas (marcadores), una página en sí o un panel de comando. Además, el elemento puede ser una tabla, que también incluye elementos (columnas). La estructura del elemento describe cómo se verá el formulario.

Toda la funcionalidad del formulario se describe en forma de detalles y comandos. Los detalles son los datos con los que trabaja el formulario y los comandos son las acciones a realizar. Por lo tanto, el desarrollador en el editor de formularios debe incluir los detalles y comandos necesarios en el formulario, crear elementos de formulario que los muestren y, si es necesario, organizar los elementos en grupos.

Con base en esta descripción lógica, el sistema genera automáticamente la apariencia del formulario para mostrarlo al usuario. En este caso, el sistema tiene en cuenta varias propiedades de los datos mostrados (por ejemplo, tipo) para organizar los elementos del formulario de la forma más cómoda posible para el usuario.

El desarrollador puede influir en la disposición de los elementos con diversos ajustes. Puede determinar el orden de los elementos, especificar el ancho y alto deseados. Sin embargo, esto es sólo información adicional para ayudar al sistema a mostrar el formulario.

En los formularios, el desarrollador puede utilizar no sólo los comandos del propio formulario, sino también comandos globales utilizados en la interfaz de comandos de toda la configuración. Además, es posible crear comandos parametrizables que abrirán otros formularios teniendo en cuenta los datos específicos del formulario actual. Por ejemplo, esto podría ser llamar a un informe sobre los saldos en el almacén actualmente seleccionado en el formulario de factura.

Todos sabemos que la empresa 1C tenía muchas versiones diferentes de la plataforma 1C, ahora nos interesará una de las últimas versiones al momento de escribir este artículo, estas son las versiones 1C 8.2 y 1C 8.3. Si ha tenido que trabajar en ambas versiones, lo más probable es que Noté diferencias en las interfaces de estas versiones., para los usuarios se diferencian sólo en apariencia. Esencialmente una elección aplicación regular o administrada le dice al sistema qué formularios mostrar para ejecutar, regular o controlado, así como qué cliente de aplicación se utilizará de forma predeterminada, grueso o delgado. Para obtener información más detallada sobre los clientes, lea el artículo "¿Qué son los clientes pesados ​​y ligeros en 1C, así como sus diferencias?".

Aplicación 1C normal (formularios normales, interfaz normal, versión 1C 8.2)

En 1C 8.2 solo es posible trabajar con formularios regulares, en modo de aplicación regular. La siguiente imagen muestra la base de datos en el modo de funcionamiento "aplicación 1C normal" (formularios normales).

Aplicación 1C administrada (formularios administrados, interfaz administrada, versión 1C 8.3)

En la plataforma 1C 8.3 podemos trabajar tanto con formularios regulares (en modo de compatibilidad) como administrados. Además Los formularios administrados tienen dos tipos de visualización: estándar y taxi.. A continuación se muestra un ejemplo de una configuración de 1C 8.3 con formularios administrados estándar, y luego se muestra la interfaz "Taxi".

¿Cuál es la diferencia entre una aplicación 1C normal y una administrada?

Como ya hemos descubierto una aplicación normal y una aplicación administrada son estos tipos de inicio de un programa 1C. Además, dependiendo del valor del tipo de lanzamiento 1C ( aplicación regular o administrada), se cargará una interfaz específica de forma predeterminada ( formularios regulares o administrados), de ahí que existan tantos sinónimos para este concepto. Nos gustaría señalar que las diferencias en las interfaces son bastante significativas; la interfaz administrada ha sido completamente rediseñada. En principio, estas son todas las diferencias que ven los usuarios habituales del programa 1C. En cuanto a los programadores, la interfaz administrada requiere escribir código modificado, porque el desarrollo ya se lleva a cabo en 1C 8.3, y no en 1C 8.2, de ahí todas las consecuencias consiguientes. El código también debe dividirse en cliente y servidor, esto se indica mediante las directivas correspondientes en el configurador.

Klyuev V.V.

http://prof1c.kklab.ru

TRABAJANDO CON INTERRUPTORES

Tenga en cuenta a todos los usuarios del servicio del sitio: ¡publico materiales en la sección Principiantes!

8.2 Formularios administrados

Al estudiar el comportamiento de los formularios administrados, los programadores o desarrolladores de interfaces se enfrentan a la pregunta de dónde están los conmutadores en los formularios administrados y cómo agregarlos al formulario. Es una cosa pequeña, pero es desagradable que se dedique tanto tiempo a esas nimiedades, aunque este tiempo podría dedicarse a desarrollar y optimizar el algoritmo, en lugar de diseñar el formulario.

Entonces, creemos una configuración vacía para comprender la pregunta o elijamos una típica.
Vaya al grupo que contiene directorios y agregue un nuevo directorio para experimentar. Me gustaría señalar que la configuración debe tener el modo de inicio principal: Aplicación administrada.

Entonces, creemos un nuevo directorio y agreguemos el atributo "Propiedad1", con el tipo "Booleano".

Ahora vayamos a la pestaña Formularios y agreguemos un nuevo formulario.

Entonces, el formulario controlado ha sido creado, ahora trabajemos con el formulario y busquemos dónde está ubicado el interruptor.
Aquí está nuestro formulario, y en él vemos nuestros accesorios, pero en forma de bandera.

Entonces, ¿qué hicimos mal?
Miremos las propiedades de los accesorios para ver si hay un cambio en el tipo de control.
¡Y vemos que el campo Switch no está aquí! (¿En qué nos equivocamos?

Aparentemente, el tipo de control en el formulario depende del tipo de datos, volvamos a las propiedades del formulario, es decir, la pestaña de detalles, y cambiemos las propiedades de nuestro atributo, es decir, su tipo "Booleano", al tipo "Número". ”.

Ahora volvamos a las propiedades del control y verifiquemos si la Vista del control se ha agregado a sus propiedades - - - Y hurra, vemos la vista allí - Cambiar campo.

Ahora mira el formulario, lo que vemos:

Vemos: 3 valores predeterminados, 3 modificadores, pero necesitamos dos de ellos, vaya nuevamente a las propiedades del atributo y observe las propiedades "Número de columnas" allí.

Para 2, establezca el Número de columnas: 2.

Esto podría detener un poco a un programador cansado)), ¡pero ahora tanto él como nosotros lo sabemos!

8.2 Formas regulares.

Aburrido con interruptores en formas ordinarias.
Hay momentos, y suceden, en los que necesita modificar algún formulario ya preparado, que ya tiene algunos interruptores, y necesita agregar otro interruptor a este formulario. Aquí surge una especie de tedio, que requiere mucho tiempo, y no tiempo para programar el código, sino una pérdida de tiempo para mostrar estos interruptores al usuario.

Así que veamos un ejemplo. Existe un documento de este tipo para ajustar los recibos en 1C UPP; definitivamente existe. Una vez necesitábamos agregarle interruptores para que se generaran asientos contables ligeramente diferentes. ¿Cuál es el problema? Parecería que debemos, debemos, lo haremos. Pero este formulario ya tiene 2 botones de opción.

Así es como se ve el formulario en el que necesitamos agregar más interruptores

En la pestaña Avanzado, nos gustaría colocar dos botones de opción más. Entonces, el primer paso es agregar audazmente un nuevo elemento de control al lugar que necesitamos e insertarlo.

Parecería que todo es sencillo. Creamos un nuevo atributo con el tipo "Número" e insertamos 2 interruptores, uno de los cuales podrá escribir datos en el atributo y el otro no.

Agregue un nuevo elemento de control: Switch, agregue Switch2 en la tabla con el número y descripción de los interruptores, configure Switch1 primero en el grupo y presione OK. Coloque los controles creados en el formulario. Actualizamos la configuración de la base de datos (F7) y la ejecutamos para depurar.

Al ejecutar (al crear un nuevo documento en modo 1C:Enterprise), vemos que por mucho que intentemos hacer clic en Switch2, no pasa nada. Los elementos no funcionan como deberían. Hay un truco aquí.
Volver al configurador. Seleccione el elemento del menú Formulario -> Establecer orden transversal... (es importante que el formulario esté abierto en la pantalla)

Para que nuestros Switches funcionen, debes romper el orden automático y aceptar uno manual. Y póngalo en forma para que nuestros interruptores vayan uno tras otro en orden.

DE ACUERDO. Actualice la configuración e intente ejecutarla.
Excelente. Todo funcionó.

Además, vídeo (sin sonido, para que todo quede claro)