Módulos da plataforma 1C:Enterprise 8.3, 8.2

Módulos comuns

Funções declaradas com o sinalizador "export" nesse módulo podem ser chamadas de qualquer lugar na configuração. A chamada é feita via CommonModuleName.FunctionName().

Esses módulos não possuem uma seção variável.

A execução dos módulos comuns depende das configurações em suas propriedades:

Bandeira "Global"

Se este sinalizador for definido, o contexto desse módulo se tornará global. Ou seja, ao acessar suas funções de exportação, não é necessário especificar o nome do módulo. Mas os nomes das suas funções de exportação devem ser exclusivos dentro do contexto de configuração global.

Bandeira do servidor

As funções desse módulo podem ser executadas no servidor.

Sinalizador "Cliente (aplicativo normal)"

As funções de tal módulo podem ser executadas no cliente no modo normal de aplicação.

Sinalizador "Cliente (aplicativo gerenciado)"

As funções de tal módulo podem ser executadas no cliente no modo de aplicativo gerenciado.

Sinalizador "Chamada do Servidor"

O sinalizador está disponível para módulos com o sinalizador "Servidor" definido. Permite ao cliente chamar as funções de exportação deste módulo (que serão executadas no servidor).

Sinalizador de adesão externa

As funções de exportação de tal módulo podem ser chamadas ao conectar-se a partir de uma fonte externa.

Bandeira "Privilegiado"

Num módulo com este sinalizador, a verificação de direitos será desativada. Adequado para produtividade ou atividades administrativas.

Opção de reutilização

Se você habilitar esta opção, os valores de retorno das funções de exportação serão armazenados em cache imediatamente após a primeira chamada. O armazenamento em cache é possível durante a chamada (o tempo de execução de um procedimento específico) ou durante a sessão do usuário.

Módulo de aplicação

Projetado para lidar com eventos de inicialização e encerramento de aplicativos. Existem dois tipos: para aplicativos regulares e gerenciados.

Você não deve sobrecarregá-lo, pois isso afeta o tempo de inicialização do aplicativo.

Módulo de sessão

Um módulo especial usado para inicializar parâmetros de sessão. É necessário para não duplicar o código nos vários módulos do aplicativo.

Deve ser utilizado com cuidado, pois o módulo pode ser executado diversas vezes, podendo também ser executado sem iniciar novamente o banco de dados. Executado antes dos módulos do aplicativo.

Atenciosamente, (professor e desenvolvedor).

Olá.
Neste post veremos o módulo da aplicação, sua finalidade e local de compilação.

Módulo de aplicação 1C destina-se principalmente a capturar o momento em que o aplicativo é iniciado e o momento em que ele é encerrado.
Também existem manipuladores que permitem interceptar um evento externo do equipamento.

Os eventos do módulo de aplicativo gerenciado são acionados quando o Thin Client, o Web Client e o Thick Client de um aplicativo gerenciado são iniciados.
O módulo de aplicativo gerenciado monitora a inicialização interativa do sistema.

O módulo de aplicativo gerenciado contém:
seção de declaração de variável
seção de descrição de procedimento e função
seção principal do programa
Procedimentos, funções e variáveis ​​de um módulo gerenciado podem ser descritos como exportação (acessíveis fora do módulo determinado). Este módulo também pode conter manipuladores de eventos especiais que ocorrem sob determinadas circunstâncias.

Vejamos a lista de manipuladores que podem ser chamados pressionando ( Ctrl+Alt+P).
Antes do sistema iniciar - a ação ainda não ocorreu (1C Enterprise 8.2 está sendo iniciado, mas o aplicativo em si ainda não apareceu na tela). Se o parâmetro “Failure” estiver definido como “True”, o aplicativo simplesmente não iniciará. Quando o sistema é iniciado - a ação já foi concluída (não há parâmetro “falha”). Antes do desligamento do sistema - o aplicativo ainda não desapareceu (existe um parâmetro “falha”).
No encerramento do sistema, a janela interativa já foi fechada.

Dê uma olhada no assistente de sintaxe e leia mais sobre eventos gerenciados e regulares de aplicativos.

O módulo do aplicativo é sempre compilado inteiramente no lado do cliente. Aqueles. a partir dele poderemos acessar procedimentos do servidor e funções de módulos comuns e não poderemos acessar objetos de configuração como documentos, diretórios.
Quando o sistema é iniciado, o módulo do aplicativo gerenciado é compilado e quanto mais procedimentos e funções de exportação forem declarados nele, mais tempo demorará a inicialização do sistema.

Módulo de aplicação regular

O módulo de aplicativo normal pode ser visto no mesmo local que o módulo de aplicativo gerenciado, mas se não estiver visível, então nos parâmetros do configurador na aba “Geral”, selecione a opção “Editar configuração para modos de inicialização” para “Gerenciado posição de aplicação e aplicação normal”.
Como fazer isso, veja o artigo:.

Os eventos regulares do módulo do aplicativo são acionados quando o cliente espesso do aplicativo regular é iniciado.
Tudo o que foi dito sobre o módulo de aplicativo gerenciado também se aplica ao módulo de aplicativo regular.

Eventos antes... e durante....

A diferença entre os procedimentos Antes de Iniciar a Operação do Sistema (Falha) e Ao Iniciar a Operação do Sistema ()

Antes do sistema iniciar a operação (recusa) - a ação ainda não foi concluída e podemos recusar realizá-la.
AtSystemStart() - a ação já foi concluída e não podemos nos recusar a iniciar ou sair do aplicativo.

Isso é tudo, obrigado pela atenção.

Por favor, deixe comentários, sua opinião é importante para mim.

Guarda: Registro de atestados médicos em 10 minutos. Para obter um certificado da Inspetoria Estadual de Segurança no Trânsito, você precisa gastar alguns dias, mas existe a opção de comprar um certificado para uma licença. É possível entregar certificado e também incluir cópia das licenças

P.S. E eu gosto de Jamala – You’re Made of Love

Módulo de aplicativo gerenciado

Projetado principalmente para capturar o momento em que o aplicativo é iniciado e o momento em que ele é encerrado. Também existem manipuladores que permitem interceptar um evento externo do equipamento. No módulo de aplicativo gerenciado, é a inicialização interativa do sistema que é monitorada.

Os eventos do módulo de aplicativo gerenciado são acionados quando o thin client, o web client e o Thick Client do aplicativo gerenciado são iniciados. No módulo de controle os aplicativos podem ser acessados ​​a partir da paleta de propriedades do nó de configuração raiz ou do menu de contexto chamado no nó de configuração raiz.

Módulo de aplicação regular

O módulo de aplicativo regular desempenha a mesma função que o módulo de aplicativo gerenciado, apenas os eventos do módulo de aplicativo regular são acionados quando o cliente grosso do aplicativo regular é iniciado.

O módulo de aplicação regular ficará disponível na paleta de propriedades do nó de configuração raiz após definir a opção “Editar configuração para modos de inicialização” nos parâmetros do configurador na guia “Geral” para “Aplicativo gerenciado e normal”.

Módulo de conexão externa

O módulo de conexão externa foi projetado para lidar com eventos de login (não interativo, mas em modo de conexão COM) e logout. Existem manipuladores correspondentes. Com uma conexão COM, uma janela interativa não abre, portanto as funções de diálogo com o usuário não funcionarão. É possível descrever variáveis ​​e métodos de exportação no módulo. O módulo de conexão externa é compilado no servidor. Aqueles. é possível acessar os objetos de configuração correspondentes, por exemplo, diretórios.

Módulo de sessão

Existe um objeto de configuração geral como “Parâmetros de sessão”. O módulo de sessão é criado para inicializar os parâmetros da sessão (existe um evento específico para isso; quando a aplicação inicia, ela inicia primeiro).

Executa em modo privilegiado (os direitos de acesso não são verificados ao acessar o banco de dados). O módulo de sessão é compilado no servidor. Não há seção para descrever variáveis ​​e uma seção para os métodos de exportação principais não pode ser descrita; ela é usada apenas para definir parâmetros de sessão. Como você pode ver, o módulo de sessão tem uma finalidade muito restrita.

Módulos comuns

Módulos comuns descrevem alguns algoritmos comuns e contêm funções que podem ser chamadas de vários lugares. Módulos comuns podem ser compilados tanto no cliente quanto no servidor.

Nos módulos gerais, APENAS a seção que descreve procedimentos e funções está disponível. Se precisar usar uma variável global, você poderá usar parâmetros de sessão ou uma variável de exportação de um módulo de aplicativo gerenciado.

No módulo geral, você pode definir alguns parâmetros que afetarão seu comportamento. Se a caixa de seleção “Global” estiver marcada no módulo geral, então suas funções de exportação participarão da formação do contexto global. E podem ser acessados ​​diretamente de outro contexto (sem mencionar o nome do módulo comum): CommonModuleMethod();

Você não deve usar a propriedade “Global” de módulos comuns em todos os lugares, porque tais módulos são compilados na inicialização do sistema e retardam o início do programa

Módulo de objeto

Muitos objetos de configuração (diretórios, documentos, etc.) possuem um módulo de objeto. Você pode inserir eventos padrão nele, como criar um novo item de diretório, registrar um novo objeto, excluir, processar uma postagem de documento, etc. O evento record existe tanto no módulo formulário (ocorre durante o processo de gravação interativa quando o usuário clica no botão “gravar”) quanto no módulo objeto.

Deve ser lembrado que um objeto pode ter vários formatos. Portanto, o evento de gravação deve ser processado no módulo objeto. É aqui que a exatidão dos dados registrados é verificada.

Um módulo de objeto pode ser chamado a partir da paleta de propriedades de um determinado objeto ou do menu de contexto. A estrutura de um módulo de objeto não é diferente de um módulo de formulário. O módulo de objeto é compilado no servidor, portanto, nenhuma diretiva de compilação é necessária.

Módulo de formulário

O módulo de formulário foi projetado para lidar com ações do usuário (lidar com um evento de clique de botão, etc.). Existem também eventos associados diretamente ao próprio formulário (por exemplo, o evento de sua abertura, fechamento). Os módulos de formulário gerenciado e regular diferem principalmente porque o módulo de formulário gerenciado é claramente separado no contexto. Todo procedimento deve ter uma diretiva de compilação. Na forma normal, todo o código é executado no cliente.

A estrutura de um formulário gerenciado contém uma seção para descrever variáveis, uma seção para procedimentos e funções e uma seção para o programa principal (executado no momento em que o formulário é inicializado). Podemos acessar os eventos padrão do formulário através da lista de procedimentos e funções (Ctrl+Alt+P) ou na paleta de propriedades do próprio formulário. Você também pode processar o evento de gravação do elemento de forma gerenciada (este evento está presente apenas para objetos: diretórios, documentos).

Módulo gerenciador de objetos

O módulo gerenciador apareceu apenas em 1C 8.2; existe em muitos objetos de configuração; O objetivo principal do módulo gerenciador de objetos é substituir o evento padrão “Processando Recebendo Dados de Seleção”, e nele também podemos

Módulo gerenciador de valor

O objeto de configuração constante não possui um módulo de objeto, mas existe um módulo muito semelhante - o módulo gerenciador de valor. No módulo gerenciador de valor constante, você pode descrever vários procedimentos (inclusive de exportação), bem como processar 3 eventos: BeforeWrite, OnWrite, ProcessingFillCheck. Este módulo é compilado no servidor.

Módulos de conjunto de registros

O módulo recordset é análogo ao módulo object e é inerente aos registradores. Existem eventos padrão no módulo recordset:

• Antes de gravar
• Ao gravar
• Processando verificação de preenchimento

No módulo recordset existe uma seção para descrições de variáveis, procedimentos e funções (inclusive de exportação), uma seção para o programa principal.

1.1. Módulos comuns são criados para implementar procedimentos e funções unidos de acordo com alguma característica. Via de regra, procedimentos e funções de um subsistema de configuração (vendas, compras) ou procedimentos e funções de funcionalidade semelhante (trabalho com strings, uso geral) são colocados em um módulo comum.

1.2. Ao desenvolver módulos compartilhados, você deve escolher um dos quatro contextos de execução de código:

2.1. Módulos comuns do servidor destinam-se a hospedar procedimentos e funções do servidor que não estão disponíveis para uso no código do cliente. Eles implementam toda a lógica de negócios do servidor interno do aplicativo.
Para o correto funcionamento da configuração em conexão externa, os modos de aplicação gerenciado e regular, procedimentos e funções do servidor deverão ser colocados em módulos comuns com as seguintes características:

• Servidor(caixa de seleção Chamada de servidor reiniciar),
• Cliente (aplicativo normal),
• Junção externa.

Neste caso, é garantida a capacidade de chamar procedimentos e funções do servidor com parâmetros de tipos mutáveis ​​​​(por exemplo, DiretórioObject, DocumentObject e assim por diante.). Normalmente isso é:

• manipuladores para assinaturas de eventos de documentos, diretórios, etc., que tomam um valor mutável (objeto) como parâmetro.
• procedimentos e funções de servidor, para os quais um objeto é passado como parâmetro de módulos de diretórios, documentos, etc., bem como de módulos com assinaturas de eventos.

Os módulos compartilhados do lado do servidor são nomeados de acordo com regras gerais para nomear objetos de metadados.
Por exemplo: Trabalhando com arquivos, Propósito geral

Em alguns casos, um postfix pode ser adicionado para evitar conflitos de nomes com propriedades de contexto global "Servidor".
Por exemplo: Servidor de tarefas de rotina, Servidor de troca de dados.

2.2. Módulos comuns do servidor para chamadas do cliente contêm procedimentos e funções de servidor que podem ser usados ​​a partir do código do cliente. Eles constituem a interface de programação cliente do servidor de aplicativos.
Tais procedimentos e funções são colocados em módulos comuns com as seguintes características:

• Servidor(caixa de seleção Chamada de servidor instalado)

Os módulos comuns do lado do servidor para chamadas de um cliente são nomeados de acordo com as regras gerais para nomear objetos de metadados e devem ser nomeados com um postfix "CallServer".
Por exemplo: Trabalhando com o servidor FilesCalling

Observe que os procedimentos e funções de exportação em tais módulos compartilhados não devem conter parâmetros de tipos mutáveis ​​( DiretórioObject, DocumentObject etc.), uma vez que a sua transferência de (ou para) o código do cliente é impossível.

Veja também:Restrição na configuração do sinalizador “Server Call” para módulos comuns

2.3. Módulos Comuns do Cliente contêm lógica de negócio do cliente (funcionalidade definida apenas para o cliente) e possuem as seguintes características:

• Cliente (aplicativo gerenciado))
• Cliente (aplicativo normal)

A exceção é quando os procedimentos e funções do cliente devem estar disponíveis apenas no modo de aplicativo gerenciado (somente no modo de aplicativo regular ou apenas no modo de conexão externa). Nesses casos, outra combinação destas duas características é aceitável.

Os módulos comuns do cliente são nomeados com um postfix "Cliente".
Por exemplo: Trabalhando com FilesClient, Cliente de uso geral

Veja também: minimizando o código em execução no cliente

2.4. Em alguns casos, é permitido criar módulos comuns cliente-servidor com procedimentos e funções cujo conteúdo seja o mesmo no servidor e no cliente. Tais procedimentos e funções são colocados em módulos comuns com as seguintes características:

• Cliente (aplicativo gerenciado)
• Servidor(caixa de seleção Chamada de servidor reiniciar)
• Cliente (aplicativo normal)
• Junção externa

Módulos comuns deste tipo são nomeados com o postfix "Servidor cliente".
Por exemplo: Trabalhando com FilesClient, ClienteServidor de uso geral

Em geral, não é recomendado definir módulos comuns tanto para o servidor quanto para o cliente (aplicação gerenciada). Recomenda-se implementar funcionalidades definidas para o cliente e para o servidor em diferentes módulos comuns - ver parágrafos. 2.1 e 2.3. Esta separação explícita da lógica de negócios cliente e servidor é ditada por considerações de aumento da modularidade da solução de aplicação, simplificando o controle do desenvolvedor sobre a interação cliente-servidor e reduzindo o risco de erros devido a diferenças fundamentais nos requisitos para o desenvolvimento de clientes e servidores. código (necessidade de minimizar o código executado no cliente, diferentes disponibilidades de objetos e tipos de plataformas, etc.). Neste caso, é preciso ter em mente o inevitável aumento do número de módulos comuns na configuração.

Um caso especial de módulos cliente-servidor mistos são os módulos de formulário e comando, que são projetados especificamente para implementar lógica de negócios de servidor e cliente em um módulo.

3.1. Recomenda-se que os nomes dos módulos comuns sigam as regras gerais para nomear objetos de metadados. O nome do módulo geral deve corresponder ao nome do subsistema ou mecanismo separado, cujos procedimentos e funções ele implementa. Recomenda-se evitar palavras genéricas como “Procedimentos”, “Funções”, “Manipuladores”, “Módulo”, “Funcionalidade”, etc. nos nomes dos módulos comuns. e usá-los apenas em casos excepcionais, quando revelam de forma mais completa o propósito do módulo.

Para distinguir entre módulos comuns de um subsistema, que são criados para implementar procedimentos e funções executadas em diferentes contextos, é recomendável fornecer-lhes os pós-fixos descritos anteriormente nos parágrafos. 2.1-2.4.

Os módulos comuns são responsáveis ​​​​por armazenar procedimentos e funções que são chamados de outros locais do sistema 1C. É considerada uma boa prática colocar o código que é chamado diversas vezes em um procedimento em um módulo comum. Esta regra é universal para todas as configurações, portanto, qualquer desenvolvedor 1C deve ser capaz de trabalhar com esses objetos de configuração. Para isso, você precisa entender todas as nuances e saber aproveitar corretamente as oportunidades que a plataforma oferece.

Criando um módulo comum em 1C

Após criar uma função em um dos módulos do objeto, houve a necessidade de utilizar um algoritmo semelhante em outro local. A melhor coisa a fazer aqui é transferir o código para um módulo comum, mas antes disso é necessário criá-lo. Para fazer isso, precisamos ir ao configurador e encontrar a aba “Geral” na árvore de configuração. Em seguida, selecione “Módulos Gerais” e use o botão em forma de sinal de mais branco no círculo verde.

As propriedades do módulo comum adicionado serão abertas à direita e teremos que descobrir o que cada uma delas significa. Eles podem ter direções diferentes, portanto, antes de montar um novo objeto, é aconselhável decidir o que iremos armazenar ali. Na verdade, no futuro será possível alterar as propriedades de acordo com as tarefas:

• "Global". Este sinalizador é definido se o módulo se destina a armazenar procedimentos e funções que devem ser chamados sem especificar o nome do módulo. Naturalmente, devem ser exportáveis ​​e os seus nomes devem ser únicos no contexto de todo o contexto global. Eles não serão diferentes em uso das funções padrão da plataforma;
• "Cliente". Depende das configurações do sistema e regula se os procedimentos do módulo podem ser executados no lado do cliente;
• "Servidor". São marcados módulos gerais, dentro dos quais se planeja colocar algoritmos para execução no servidor;
• "Junção externa". Os procedimentos do módulo com esta propriedade ativada poderão ser executados através da conexão de uma fonte externa;
• "Chamada do Servidor". Responsável por permitir que procedimentos do módulo chamem o servidor enquanto rodam no cliente;
• "Privilegiado". Habilitar esta configuração permitirá que você não verifique os direitos de acesso ao executar o código de procedimento do módulo. Você pode chamar um módulo comum com esta configuração somente no servidor. As configurações de Cliente e Conexão Externa serão redefinidas;
• "Reuso". Pode assumir os seguintes valores: “Não utilizar”, “Durante a sessão”, “Durante a chamada”. Ao chamar um procedimento várias vezes, o sistema pode usar dados previamente calculados dentro do procedimento (chamada) ou a vida de toda a sessão (lançamento 1C). Você deve ter muito cuidado com esta configuração, pois podem ocorrer erros devido ao uso incorreto de tais módulos.

Existem situações em que é necessário criar um módulo comum com chamadas de procedimento no servidor e cliente com diferenças no algoritmo. Diretivas de pré-processador com verificação são usadas para delimitar o código. Como resultado, será um código para a chamada do servidor e outro para a chamada do cliente.
Procedure AlgorithmServerClient() Export #If ThinClient Then // o código é executado se a chamada do procedimento vier do cliente ShowUserAlert("No cliente"); ElseIf Server Then // o código é executado se a chamada do procedimento vier do servidor VariableServer = "Server call"; #TheEndIfTheEndProcedure

Um exemplo de transferência de código para um módulo 1C comum

Vamos considerar uma situação em que temos dois eventos no formulário do documento que envolvem um procedimento de multiplicação de quantidade e preço na seção tabular. Este é um algoritmo bastante comum, visto que é encontrado em muitos documentos de compras e vendas. Vamos transferir o código do procedimento para um módulo comum, que primeiro deve ser criado para poder utilizar este código em outros documentos.

Como para nossa tarefa precisamos apenas de uma chamada do cliente e não precisamos de dados do banco de dados, definimos apenas o flag “Cliente”. Se quiser usar o mesmo módulo no futuro para cálculos mais complexos, marque “Servidor” nas propriedades. A fase preparatória está concluída e podemos prosseguir com a escrita do código.

Vamos criar um procedimento de exportação no módulo e transferir para lá o algoritmo de cálculo do valor do procedimento no módulo de formulário. A string da seção da tabela será usada como parâmetro de procedimento na entrada. No módulo de formulário de documento, alteramos as chamadas de procedimento no mesmo módulo para uma chamada de procedimento do módulo geral.

Fragmento 1

Fragmento 2

Quando o sistema for iniciado, não notaremos a diferença, mas essa estrutura de código é muito mais conveniente de ler e manter. É claro que, neste exemplo, a quantidade de código não pode mostrar todos os benefícios. No caso de um algoritmo complexo para dezenas de objetos de configuração, o ganho na quantidade de código e em sua estrutura também afetará a velocidade do sistema. Além disso, desenvolvedores 1C experientes recomendam não descrever algoritmos em módulos de formulário, mas colocá-los em módulos gerais configurados corretamente.

Ao desenvolver módulos gerais, as regras geralmente aceitas para sua criação devem ser levadas em consideração:

• Coloque procedimentos e funções relacionados a funcionalidades semelhantes em um módulo comum separado;
• O nome do módulo deve refletir sua pertença ao contexto (Cliente, Servidor) e evitar palavras comuns (manipuladores, procedimentos, etc.);
• Separe a lógica interna do servidor da aplicação e a lógica do cliente da interface;
• Tenha cuidado ao criar um módulo compartilhado global. Não ter que se referir a um procedimento através do nome do módulo pode causar confusão, especialmente se o sistema for suportado por múltiplas equipes de desenvolvimento.

Módulos criados corretamente o ajudarão a navegar na estrutura de configuração e a fazer melhorias com muito mais rapidez. Se você vir uma oportunidade de tornar universal uma função útil e colocá-la em um módulo comum, faça-o. No futuro, você e seus colegas ficarão gratos por esta decisão.