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

Módulos gerais

As funções que são declaradas com o sinalizador "export" em tal 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 de módulos comuns depende dos parâmetros definidos em suas propriedades:

Bandeira "Global"

Se esse 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 de suas funções de exportação devem ser exclusivos dentro do contexto de configuração global.

Marcar "Servidor"

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

Sinalizar "Cliente (aplicativo regular)"

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

Sinalizar "Cliente (aplicativo gerenciado)"

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

Sinalizador de 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).

Sinalizar "junção externa"

As funções de exportação de tal módulo podem ser chamadas quando conectadas de uma fonte externa.

Sinalizar "Privilegiado"

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

Reutilizar opçã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 cache é possível durante a chamada (duração da execução de um determinado procedimento) ou durante a sessão do usuário.

módulo de aplicativo

Projetado para lidar com eventos de início e fim do aplicativo. 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 que é usado para inicializar os parâmetros da sessão. Necessário para não duplicar o código em diferentes módulos do aplicativo.

Deve ser usado com cuidado, pois o módulo pode ser executado várias vezes, e também pode ser executado sem mais início da base. É executado antes dos módulos do aplicativo.

Atenciosamente, (professor e desenvolvedor).

Os módulos de software contêm código executável na linguagem 1C, necessário para responder de certa forma às ações do sistema ou do usuário quando as ferramentas visuais de desenvolvimento não são suficientes. Também nos módulos do programa podemos descrever nossos próprios métodos (procedimentos e funções).

Normalmente, um módulo de software consiste em três seções:

• área de declaração variável;
• área de descrição de procedimento e função;
• texto principal do programa.

Um exemplo da estrutura de um módulo de programa:

//******** ÁREA DE DECLARAÇÃO DE VARIÁVEIS *************************

Exportação de Sobrenome Rem; / /esta é uma variável global
Nome da variável, patronímico; //esta é uma variável de módulo
Mude o nome; //esta também é uma variável de módulo e pode ser acessada

//de qualquer procedimento e função do nosso módulo

//***************** PROCEDIMENTO E DESCRIÇÃO DAS FUNÇÕES ****

Procedimento Procedimento1 ()
Variável Total ; / /Total é uma variável local (variável de procedimento)

Total = Sobrenome + "" + Nome próprio + " "+ Patronímico;

EndProcedure

Função Função1 ()

// instruções de função

Return(Sobrenome + " " + Nome );

EndFunctions

//************************ TEXTO PRINCIPAL DO PROGRAMA ******** *

Sobrenome = "Ivanov";
Nome = "Ivan";
Nome do meio = "Ivanovich";

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

Em um determinado módulo do programa, qualquer uma das áreas pode estar ausente.
Escopo da declaração da variávelé colocado desde o início do texto do módulo até a primeira instrução do procedimento ou a instrução Function ou qualquer instrução executável. Esta seção pode conter apenas instruções de declaração de variáveis.

Área de descrição de procedimentos e funçõesé colocado da primeira instrução de um procedimento ou uma instrução de função para qualquer instrução executável fora do corpo de um procedimento ou declaração de função.

Área de texto principal do programaé colocado desde a primeira instrução executável fora do corpo de procedimentos ou funções até o final do módulo. Esta seção pode conter apenas instruções executáveis. A área do texto principal do programa é executada no momento da inicialização do módulo. Normalmente, na seção principal do programa, faz sentido colocar instruções para inicializar variáveis ​​com alguns valores específicos que devem ser atribuídos antes da primeira chamada aos procedimentos ou funções do módulo.

Os módulos do programa estão localizados nos locais da configuração que podem exigir a descrição de algoritmos de operação específicos. Esses algoritmos devem ser concebidos como procedimentos ou funções que serão chamadas pelo próprio sistema em situações predeterminadas (por exemplo, ao abrir um formulário de referência, ao clicar em um botão de uma caixa de diálogo, ao alterar um objeto, etc.).

Cada módulo de programa separado é percebido pelo sistema como um todo, então todos os procedimentos e funções do módulo de programa são executados em um único contexto.

O contexto de execução dos módulos é dividido em contextos de cliente e servidor. Além disso, alguns módulos de software podem ser compilados tanto no lado do cliente quanto no lado do servidor.

Módulo aplicativo (gerenciado ou regular)

O módulo aplicativo descreve os procedimentos (manipuladores) de eventos que são inicializados no início e no final do sistema. Por exemplo, ao iniciar um aplicativo, você pode atualizar alguns dados de configuração e, ao sair, pode perguntar se deve sair do programa. Além disso, este módulo intercepta eventos de equipamentos externos, como equipamentos comerciais ou fiscais. Vale ressaltar que o módulo aplicativo é executado apenas no caso de um lançamento interativo do aplicativo, ou seja, quando a janela do programa é iniciada. Isso não acontece se o aplicativo for iniciado no modo de conexão.
Existem dois módulos de aplicativos diferentes na plataforma 1C 8. Estes são o módulo Aplicativo Comum e o módulo Aplicativo Gerenciado. Eles são acionados quando diferentes clientes são iniciados. Por exemplo, o módulo Aplicativo Gerenciado é acionado quando o Web client, thin client e thick client são ativados no modo de aplicativo gerenciado. E o módulo de aplicativo regular é acionado quando o cliente espesso é iniciado no modo de aplicativo normal. A configuração do modo de inicialização do aplicativo é definida na propriedade de configuração "Modo de inicialização principal".

O módulo de aplicativo pode conter todas as 3 seções - declarações de variáveis, descrições de procedimentos e funções, bem como o texto principal do programa. O módulo de aplicação é compilado no lado do cliente, o que nos restringe severamente o uso de muitos tipos de dados. Você pode estender o contexto de um módulo de aplicativo com os métodos de módulos compartilhados que possuem a propriedade Call Server definida. Todas as variáveis ​​e métodos do módulo do programa aplicativo marcados como export estarão disponíveis em qualquer módulo de configuração do lado do cliente. No entanto, por mais tentador que seja, você não deve colocar um grande número de procedimentos e funções aqui. Quanto mais código houver em um determinado módulo, maior será o tempo de compilação e, consequentemente, o tempo de inicialização do aplicativo.

Conforme observado acima, o módulo de aplicativo manipula os eventos de início e fim do aplicativo. Para lidar com cada um desses eventos no módulo de aplicativo, existem alguns manipuladores Before ... e When ... As diferenças entre eles são as seguintes: quando o código no manipulador Before ... é executado, a ação tem ainda não ocorreu e podemos nos recusar a executá-lo. É para isso que serve a opção Recusa. Nos manipuladores On, a ação já ocorreu e não podemos nos recusar a iniciar o aplicativo ou sair dele.

Módulo de conexão externa

• pode conter todas as 3 áreas
• localizado na seção raiz da configuração

A finalidade do módulo é semelhante à finalidade do módulo de aplicativo. Ele manipula os eventos de início e fim do aplicativo. O módulo de conexão externa é acionado quando o aplicativo é iniciado no modo com-conexão. O processo de junção externa em si não é um processo interativo. Nesse modo, ocorre o trabalho programático com a infobase e a janela do aplicativo não abre, o que impõe certas restrições ao uso de métodos destinados ao trabalho interativo. Neste modo, você não pode usar chamadas para formulários de diálogo, avisos e mensagens para o usuário, etc. Eles simplesmente não vão correr.

Assim como no módulo aplicativo, todas as três áreas estão disponíveis aqui: declarações de variáveis, descrições de procedimentos e funções, bem como o texto principal do programa. A principal diferença em relação ao módulo aplicativo é que no modo de conexão com, todo o trabalho com a infobase ocorre no lado do servidor, portanto, o módulo de conexão externa é compilado no lado do servidor. Consequentemente, variáveis ​​de exportação e métodos de módulos clientes comuns não estão disponíveis nele.

módulo de sessão

• executado no lado do servidor
• localizado na seção raiz da configuração

Este é um módulo altamente especializado projetado exclusivamente para inicializar os parâmetros da sessão. Por que você precisou fazer seu próprio módulo para isso? Seu uso se deve ao fato de que o próprio aplicativo pode ser iniciado em vários modos (o que leva à execução de um módulo de aplicativo gerenciado, de um módulo de aplicativo comum ou de um módulo de conexão externa) e os parâmetros de sessão devem ser inicializados independentemente de o modo de lançamento. Para não escrever o mesmo código de programa em todos esses três módulos, precisávamos de um módulo adicional que fosse executado independentemente do modo de inicialização do aplicativo.

Há um único evento "SetSessionParameters" no módulo de sessão, que é disparado primeiro, mesmo antes do evento PreSystemBegin do módulo de aplicativo. Ele não possui uma seção de declaração de variável e uma seção de programa principal. E também é impossível declarar métodos de exportação. O módulo é compilado no lado do servidor.

Módulos gerais

• pode conter uma área para descrever procedimentos e funções
• executado no lado do servidor ou do cliente (depende das configurações do módulo)
• localizado no ramo da árvore de objetos de configuração "Geral" - "Módulos gerais"

Os módulos comuns destinam-se a descrever alguns algoritmos comuns que serão chamados de outros módulos de configuração. O módulo geral não contém áreas de declaração de variáveis ​​e o corpo do programa. Você pode declarar métodos de exportação nele, cuja disponibilidade será determinada pelas configurações do módulo (em que lado é executado: no servidor ou no lado do cliente). Devido ao fato de que a seção de declaração de variável não está disponível, não é possível definir variáveis ​​globais em módulos compartilhados. Você pode usar o módulo de aplicativo para isso.

O comportamento do módulo compartilhado depende dos parâmetros definidos (globais ou não, vários sinalizadores de compilação, se uma chamada do servidor está disponível, etc.). Aqui estão algumas dicas para configurar módulos compartilhados:

É uma boa prática não usar o sinalizador "Global" em todos os lugares. Isso reduzirá o tempo de inicialização do aplicativo, além de melhorar a legibilidade do código (claro, se o módulo comum tiver um nome completamente significativo);
- Não é aconselhável usar mais de um sinalizador de compilação. Não há tantos métodos que precisam ser executados em contextos diferentes e, se tais métodos forem necessários, um módulo comum separado pode ser alocado para eles;
- o sinalizador "Server call" só faz sentido se o módulo for compilado "On the server". Portanto, todos os outros sinalizadores de compilação devem ser removidos para evitar vários problemas;
- se nos métodos do módulo houver processamento em massa de dados, leitura e gravação no banco de dados, para aumentar a velocidade do trabalho, é melhor desativar o controle de acesso definindo o sinalizador "Privilegiado". Este modo está disponível apenas para módulos compartilhados compilados no servidor.

Módulo de formulário

• pode conter todas as 3 áreas
• executado no servidor e no lado do cliente

O módulo de formulário é projetado para lidar com as ações do usuário com este formulário (manipulação do evento de clique do botão, alteração do atributo do formulário, etc.). Existem também eventos relacionados diretamente ao próprio formulário (por exemplo, sua abertura ou fechamento). Os módulos de formulário gerenciado e os módulos de formulário regulares diferem principalmente porque um módulo de formulário gerenciado é claramente separado em um contexto. Todo procedimento ou função deve ter uma diretiva de compilação. Se a diretiva de compilação não for especificada, esse procedimento ou função será executado no lado do servidor. Na forma usual, todo o código é executado no lado do cliente.

A estrutura do formulário gerenciado contém uma seção de declaração de variáveis, descrições de procedimentos e funções e o corpo do programa (executado quando o formulário é inicializado). Podemos acessar os eventos do formulário padrão através da lista de procedimentos esperados e funções do formulário (Ctrl+Alt+P), ou através da paleta de propriedades do próprio formulário.

Se o atributo principal for atribuído ao formulário, as propriedades e métodos do objeto de aplicativo usado como o atributo principal ficarão disponíveis no módulo de formulário.

módulo de objeto

• pode conter todas as 3 áreas
• executado no lado do servidor

Este módulo está disponível para a maioria dos objetos de configuração e destina-se, em geral, ao processamento de eventos diretamente relacionados ao objeto. Por exemplo, eventos de registro e exclusão de objetos, verificação de preenchimento dos detalhes de um objeto, postagem de um documento, etc.

Alguns eventos de módulo de objeto duplicam eventos de módulo de formulário. Por exemplo, eventos relacionados ao registro. No entanto, deve-se entender que os eventos do módulo de formulário só serão executados no formulário específico do objeto, ou seja, quando o formulário específico for aberto. E os eventos do módulo objeto serão chamados em qualquer caso, mesmo no momento do programa trabalhar com o objeto. Portanto, se você precisa de métodos associados a um objeto sem estar vinculado a uma forma específica do objeto, então é melhor usar o módulo de objeto para isso.

módulo gerenciador de objetos

• pode conter todas as 3 áreas
• executado no lado do servidor

O módulo gerenciador de objetos apareceu apenas a partir da versão 1C 8.2. O módulo gerenciador existe para todos os objetos de aplicativo e é projetado para gerenciar esse objeto como um objeto de configuração. O módulo gerenciador permite estender a funcionalidade de um objeto introduzindo (escrever) procedimentos e funções que não se aplicam a uma instância específica do objeto de banco de dados, mas ao próprio objeto de configuração. O módulo gerenciador de objetos permite colocar procedimentos e funções comuns para um determinado objeto e acessá-los de fora, por exemplo, do processamento (claro, se este procedimento ou função estiver com a palavra-chave Export). O que isso nos dá de novo? Em geral, nada mais é do que organizar procedimentos por objetos e armazená-los em locais separados - Módulos do Gerenciador de Objetos. Podemos também colocar esses procedimentos e funções em módulos comuns, mas 1C aconselha colocar procedimentos e funções comuns de objetos no Módulo Gerenciador de Objetos. Exemplos de uso dos procedimentos e funções do Módulo Gerenciadores de Objetos: preenchimento inicial de detalhes individuais de um diretório ou documento sob certas condições, verificação do preenchimento de detalhes de um diretório ou documento sob certas condições, etc.

Módulo de comando

• pode conter uma seção descrevendo procedimentos e funções
• executado no lado do cliente

Comandos são objetos subordinados a objetos de aplicação ou configuração como um todo. Cada comando possui um módulo de comando no qual você pode descrever um procedimento CommandProcess() predefinido para executar esse comando.

Módulo de Aplicativo Gerenciado

Destina-se principalmente a capturar o momento de inicialização do aplicativo e o momento de desligamento. Existem também manipuladores que permitem interceptar um evento externo do equipamento. É a inicialização interativa do sistema que é rastreada no módulo de aplicativo gerenciado.

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ó raiz de configuração ou do menu de contexto chamado no nó raiz de configuração.

Módulo de aplicativo 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 disparados quando o cliente espesso do aplicativo regular é iniciado.

O módulo de aplicativo regular ficará disponível na paleta de propriedades do nó raiz de configuração após definir a opção "Edição de configuração para modos de inicialização" nas configurações do configurador na guia "Geral" para "Aplicativo gerenciado e normal".

Módulo de conexão externa

O módulo de conexão externa é projetado para lidar com o evento de login (não interativo, mas no modo de conexão COM) e logout. Existem manipuladores apropriados. Uma conexão COM não abre uma janela interativa, portanto, as funções para um diálogo com o usuário não funcionarão. É possível descrever variáveis ​​e métodos de exportação em um 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 comum como "Opções de sessão". O módulo de sessão foi criado para inicializar os parâmetros da sessão (existe um evento específico para isso, ele inicia logo no início da aplicação).

Executa em modo privilegiado (não verifica os direitos de acesso ao acessar o banco de dados). O módulo de sessão é compilado no servidor. Não há seção de declaração de variável e uma seção de programa principal, os métodos de exportação não podem ser descritos, são usados ​​apenas para definir os parâmetros da sessão. Como você pode ver, o módulo de sessão tem um propósito muito restrito.

Módulos gerais

Os módulos gerais descrevem alguns algoritmos gerais, contêm funções que podem ser chamadas de vários lugares. Os módulos compartilhados podem ser compilados no cliente e no servidor.

Nos módulos gerais, APENAS a seção que descreve procedimentos e funções está disponível. Se você precisar usar uma variável global, poderá usar os parâmetros de sessão ou a variável de exportação do 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 definida no módulo geral, suas funções de exportação participarão da formação do contexto global. E podem ser acessadas 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 a criação de um novo elemento de diretório, a entrada de um novo objeto, exclusão, processamento de lançamento de um documento, etc. O evento write existe tanto no módulo form (ocorre durante o processo de gravação interativa quando o usuário clica no botão “escrever”) quanto no módulo objeto.

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

O módulo de objeto pode ser chamado da paleta de propriedades do objeto fornecido ou do menu de contexto. O módulo objeto tem a mesma estrutura do módulo formulário. O módulo de objeto é compilado no servidor, portanto, as diretivas de compilação não são necessárias.

Módulo de formulário

O módulo de formulário é projetado para lidar com as ações do usuário (manipulação do evento de clique do 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 os módulos de formulário regulares diferem principalmente porque um módulo de formulário gerenciado é claramente separado em um contexto. Cada procedimento deve ter uma diretiva de compilação. Na forma normal, todo o código é executado no cliente.

A estrutura do formulário gerenciado contém uma seção de declaração de variável, uma seção de procedimento e função e uma seção de programa principal (executada quando 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. Além disso, em um formulário gerenciado, você pode manipular o evento de registro do elemento (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 para muitos objetos de configuração. O objetivo principal do módulo gerenciador de objetos é redefinir o evento padrão "ProcessingChoiceDataReposing", e também podemos

módulo gerenciador de valor

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

Módulos do conjunto de registros

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

• Antes de Gravar
• Ao gravar
• Processamento de verificação de preenchimento

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

Quase todos os objetos de configuração possuem um módulo gerenciador e, para a maioria dos objetos, um módulo de objeto. Freqüentemente, os programadores novatos não entendem a diferença no propósito desses dois módulos.

Compreender a diferença em sua finalidade permite que você escreva um código de programa com estrutura mais correta e, em alguns casos, economize recursos do servidor 1C e aumente o desempenho da solução do aplicativo.

No artigo, consideraremos as diferenças fundamentais entre esses módulos tanto do lado teórico quanto de um exemplo prático específico.

Teoria

Vamos voltar aos fundamentos da programação orientada a objetos (OOP) e fazer uma analogia com nosso exemplo. Em OOP, métodos em objetos podem ser divididos em estático (estático) e simples. Métodos simples só podem ser chamados em um objeto específico ao qual temos acesso no contexto do código atual. Os métodos estáticos não têm acesso direto aos dados do objeto. Para acessar um objeto, primeiro você precisa criar uma instância dele. O mesmo se aplica à plataforma 1C:Enterprise 8.x.

No módulo objeto, a plataforma armazena procedimentos e funções que só podem ser chamados ao trabalhar com um objeto específico, por exemplo, com o objeto do elemento de referência "Nomenclatura". O módulo gerenciador contém procedimentos e funções que podem ser aplicadas a todos os objetos de um determinado tipo, mas com a criação inicial de uma instância desse objeto. Ou seja, para alterar um elemento da nomenclatura deste módulo, inicialmente, para referenciar o elemento, execute o método "GetObject()" e depois trabalhe com ele futuramente.

Vamos da teoria à prática.

Prática

Vamos a um exemplo prático. Vamos supor que precisamos resolver o problema de imprimir uma lista de mercadorias: o usuário imprime um produto diretamente do elemento diretório ou do formulário de lista de produtos. Vamos considerar duas maneiras de realizar a tarefa.

Procedimento de impressão no módulo de objeto

Adicione a seguinte função ao módulo de objeto do dicionário:

// Passa uma referência ao elemento do diretório para a função Função PrintSelectedItems(Link) Exportar TabDoc = Novo TabDoc; Layout = Diretórios. Bens. GetLayout("Layout"); Solicitação = Nova Solicitação; Solicitar. Text = " SELECIONE | Itens . Apresentação AS Bens,| Bens . Marcar Excluir,| Bens . Código do vendedor |DE| Diretório . Produtos AS Produtos| ONDE | Bens . Link B(& ItemsArray)" ; Request. SetParameter(" Array of Goods " , Link); // Define a seleção por referência

O código do programa é totalmente gerado pelo designer de impressão. A única coisa digna de nota é que ele é exibido por referência ao elemento de diretório "Produtos" na solicitação. A referência é passada como um parâmetro para a função. Como resultado da chamada da função "Imprimindo itens selecionados", um documento de planilha com um item de item preenchido será retornado.

O código do programa para chamar o método do objeto "PrintSelectedProducts" no comando do formulário "Print" é apresentado na listagem a seguir:

& OnClient Imprimir Procedimento(Comando) // Chame o procedimento do servidor para obter o documento de planilha gerado TabDoc = ServidorImpressão(); // Mostra o documento de planilha gerado TabDoc. Mostrar() ; Função EndProcedure e OnServer PrintServer() // Converte o objeto de formulário para o objeto do diretório "Produtos" para chamar a função do módulo de objeto ItemObject = FormAttributeToValue("Objeto"); // Chama o procedimento do módulo objeto, passando ali uma referência ao elemento atual do dicionário. Resultado // volta para o lado do cliente Retorno ObjectItem. PrintSelectedItems(Object.Reference) ; EndFunctions

Assim, imprimimos o elemento atual do diretório, trabalhando com seu objeto. Mas na tarefa dizia-se imprimir uma lista de produtos que o próprio usuário deveria escolher. Ao trabalhar com um objeto, não é possível dar tal oportunidade ao usuário de forma simples. Seria mais correto imprimir da lista de elementos do diretório "Mercadorias".

Procedimento de impressão no módulo gerenciador

Adicione o seguinte procedimento de exportação ao módulo do gerenciador de diretórios:

// Passando um array de links para produtos Função PrintSelectedItems(ItemsArray) Export TabDoc = New SpreadsheetDocument; Layout = Diretórios. Bens. GetLayout("Layout"); Solicitação = Nova Solicitação; Solicitar. Text = " SELECIONE | Itens . Apresentação AS Bens,| Bens . Marcar Excluir,| Bens . Código do vendedor |DE| Diretório . Produtos AS Produtos| ONDE | Bens . Link B(& ItemsArray)" ; Request. SetParameter(" Matriz de Itens " , Matriz de Itens); // Definir filtro por array Resultado = Pedido. Executar(); AreaTitle = Layout. GetRegion("Título"); AreaFooter = Layout. GetRegion("Porão"); Área TableHeader = Layout. GetArea("Cabeçalho da Tabela" ); AreaFooterTables = Layout. GetRegion("TableFooter" ); AreaDetailRecords = Layout. GetRegion("Detalhes"); TabDoc. Claro() ; TabDoc. Output(AreaHeader) ; TabDoc. Output(RegionTableHeader) ; TabDoc. StartAutoGroupRows() ; SampleDetailRecords = Resultado. Escolher() ; Durante a amostragem de registros detalhados. Next() LoopDetailRecordsArea. Opções. Fill(SeleçãoDetalhesRegistros) ; TabDoc. Output(RegionDetailRecords, SelectionDetailRecords. Level() ); FimCiclo ; TabDoc. EndAutoGroupRows() ; TabDoc. Output(RegionFooterTables) ; TabDoc. Output(AreaFooter) ; Retorno TabDoc; EndFunctions

A principal diferença de uma função em um módulo de objeto é o parâmetro da função. Agora, um array com links para os produtos que precisam ser impressos é passado como parâmetro.

O código do programa do módulo de comando do formulário "Imprimir" é o seguinte:

& No procedimento do cliente Print(Command) TabDoc = PrintServer() ; TabDoc. Mostrar() ; Função EndProcedure e OnServer PrintServer() // Passando um array de links de produtos selecionados na lista de pesquisa // na função do módulo gerenciador "PrintSelectedItems" Manuais de Devolução. Bens. PrintSelectedItems(Itens. Lista. Linhas selecionadas); EndFunctions

Nesse caso, o resultado da execução do comando no modo 1C:Enterprise será o seguinte:

No caso de usar o método do módulo gerenciador, podemos acessar os dados do catálogo "Produtos" sem obter um objeto para cada link. Como obter um objeto significa obter todos os dados do banco de dados pelo elemento do diretório e colocar os dados recebidos na RAM, a implementação da tarefa da segunda maneira afetará positivamente o desempenho. Com efeito, neste caso, utilizaremos um mínimo de recursos (RAM) da máquina servidora.

O que usar?

Como sempre, tudo depende da tarefa específica. Se você precisa imprimir um documento, a melhor opção é usar o módulo gerenciador. Se você precisar preencher um objeto, por exemplo, por processamento externo de preenchimento de partes tabulares, nesse caso é melhor colocar procedimentos e funções no módulo de objeto, pois seu trabalho envolve exatamente o objeto.

Na configuração típica "Trade Management" versão 11, o módulo gerenciador para impressão de documentos é usado em todos os lugares. Se você observar a configuração "Production Enterprise Management", o módulo gerenciador praticamente não é usado, pois a configuração foi escrita em versões mais antigas da plataforma, onde não havia suporte total para esse mecanismo.

Configuração com exemplos do artigo.

O que são módulos e para que exatamente eles se destinam? O módulo contém o código do programa. Além disso, vale ressaltar que, diferentemente da plataforma 7.7, onde o código poderia estar localizado tanto nas propriedades dos elementos do formulário quanto nas células das tabelas de layout, na plataforma 8.x, qualquer linha de código deve estar localizada em algum módulo. Normalmente, um módulo consiste em três seções - uma seção para descrever variáveis, uma seção para descrever procedimentos e funções e uma seção para o programa principal. Essa estrutura é típica para quase todos os módulos da plataforma, com algumas exceções. Alguns módulos não possuem uma seção de declaração de variável e uma seção de programa principal. Por exemplo, Módulo de Sessão e qualquer Módulo Geral.

O contexto de execução dos módulos geralmente é dividido em contextos de cliente e servidor. Além disso, alguns módulos podem ser compilados tanto no lado do cliente quanto no lado do servidor. E alguns são puramente do lado do servidor ou do lado do cliente. Então:

módulo de aplicativo

O módulo é projetado para capturar os momentos de inicialização do aplicativo (carregamento da configuração) e sua conclusão. E nos eventos correspondentes, você pode organizar os procedimentos de verificação. Por exemplo, no início do aplicativo, atualize quaisquer dados de referência de configuração, no final do trabalho, pergunte se vale a pena deixá-lo, talvez a jornada de trabalho ainda não tenha terminado. Além disso, intercepta eventos de equipamentos externos, como equipamentos comerciais ou fiscais. Vale a pena notar que o módulo de aplicativo intercepta os eventos descritos apenas no caso de um lançamento interativo. Aqueles. quando a própria janela do programa é criada. Isso não acontece se o aplicativo for iniciado no modo de conexão.

Existem dois módulos de aplicativos diferentes na plataforma 8.2. Estes são o módulo Aplicativo Comum e o módulo Aplicativo Gerenciado. Eles são acionados quando diferentes clientes são iniciados. É assim que o módulo de aplicativo gerenciado é acionado quando o Web client, o thin client e o thick client são ativados no modo de aplicativo gerenciado. E o módulo de aplicativo regular é acionado quando o cliente espesso é iniciado no modo de aplicativo normal.

Todas as seções podem ser colocadas no módulo de aplicativo - descrições de variáveis, procedimentos e funções, bem como descrições do programa principal. O módulo de aplicativo é compilado no lado do cliente, então isso nos limita severamente na disponibilidade de muitos tipos de dados. Você pode estender o contexto de um módulo de aplicativo com os métodos de módulos compartilhados que possuem a propriedade Call Server definida. Todas as variáveis ​​e métodos marcados como export estarão disponíveis em qualquer módulo de configuração do lado do cliente. No entanto, por mais tentador que seja, não coloque muitos métodos aqui. Quanto mais código ele contém, maior o tempo de compilação e, consequentemente, o tempo de inicialização do aplicativo, o que é muito irritante para os usuários.

Conforme observado acima, o módulo de aplicativo manipula os eventos de início e fim do aplicativo. Para lidar com cada um desses eventos no módulo de aplicativo, existem alguns manipuladores Before ... e When ... A diferença entre eles é que quando o código no manipulador Before ... é executado, a ação ainda não foi ocorreu e podemos nos recusar a executá-lo. É para isso que serve a opção Recusa. Nos manipuladores On, a ação já ocorreu e não podemos nos recusar a iniciar o aplicativo ou sair dele.

Módulo de conexão externa

A finalidade do módulo é semelhante à finalidade do módulo de aplicativo. Ele manipula os pontos inicial e final do aplicativo. O módulo de conexão externa é acionado quando o aplicativo é iniciado no modo com-conexão. O processo de junção externa em si não é um processo interativo. Nesse modo, ocorre o trabalho programático com a infobase e a janela do aplicativo não abre, o que impõe certas restrições ao uso de métodos destinados ao trabalho interativo. Neste modo, você não pode usar chamadas de formulário de diálogo, mensagens de aviso, etc. Eles simplesmente não funcionam.

Assim como no módulo de aplicação, aqui estão disponíveis seções para descrever variáveis, métodos e uma seção para o programa principal. Você também pode declarar variáveis ​​e métodos de exportação. A diferença é que no modo com-conexão, todo o trabalho com a infobase ocorre no lado do servidor, portanto, o módulo de conexão externa é compilado exclusivamente no servidor. Consequentemente, variáveis ​​de exportação e métodos de módulos clientes comuns não estão disponíveis nele.

módulo de sessão

Este é um módulo altamente especializado e destina-se exclusivamente à inicialização de parâmetros de sessão. Por que você precisou fazer seu próprio módulo para isso? Isso se deve ao fato de que o processo de inicialização pode exigir a execução de algum código e, além disso, o aplicativo pode ser iniciado em diferentes clientes (o que leva à execução de diferentes módulos de aplicativo ou módulo de conexão externa) e os parâmetros de sessão devem ser inicializado em qualquer modo de inicialização. Portanto, foi necessário um módulo adicional, que é executado em qualquer modo de inicialização do aplicativo.

Há um único evento "SetSessionParameters" no módulo de sessão, que é disparado primeiro, mesmo antes do evento BeforeSystemStart do módulo de aplicativo. Ele não possui uma seção de declaração de variável e uma seção de programa principal. E também é impossível declarar métodos de exportação. O módulo é compilado no lado do servidor.

Evite a tentação de que este módulo seja executado toda vez que o aplicativo for iniciado e coloque nele um código que não esteja diretamente relacionado à inicialização dos parâmetros da sessão. Isso se deve ao fato de que o manipulador SetSessionParameters pode ser chamado repetidamente durante a operação do sistema. Por exemplo, isso acontece quando acessamos parâmetros não inicializados. E embora seja possível capturar o momento do primeiro lançamento deste evento (RequiredParameters tem o tipo Undefined), deve-se notar que este módulo é compilado em modo privilegiado, ou seja, ele não controla os direitos de acesso. E o segundo ponto, ainda não podemos ter cem por cento de certeza de que o sistema será lançado. De repente, o módulo do aplicativo falhará e estamos tentando executar alguma ação com o banco de dados.

Módulos gerais

Os módulos destinam-se a descrever alguns algoritmos comuns que serão chamados de outros módulos de configuração. O módulo geral não contém uma seção de declaração de variável e uma seção de programa principal. Métodos de exportação podem ser declarados nele, cujo contexto de acessibilidade será determinado por sinalizadores de compilação. Devido ao fato de que a seção de declaração de variável não está disponível, não é possível definir variáveis ​​globais em módulos compartilhados. Para fazer isso, você precisa usar as funções de módulos comuns com cache de valor de retorno ou um módulo de aplicativo. Deve-se ter em mente que, mesmo que a propriedade de reutilização do módulo comum seja definida como "Durante a sessão", nesse caso, o tempo de vida dos valores em cache não excede 20 minutos a partir do momento em que foram Último acesso.
O comportamento do módulo compartilhado depende dos parâmetros definidos (globais ou não, vários sinalizadores de compilação, se uma chamada do servidor está disponível, etc.). Neste artigo, não consideraremos todos os tipos de configurações, bem como recursos comportamentais e armadilhas que surgem quando os sinalizadores de propriedade são definidos de forma irracional. Este é um tópico para um artigo separado. Vamos nos deter em apenas alguns pontos que devem ser seguidos ao definir sinalizadores:

• É uma boa regra geral não usar o sinalizador "Global" em todos os lugares. Isso reduzirá o tempo de inicialização do aplicativo, além de melhorar a legibilidade do código (claro, se o módulo comum tiver um nome completamente significativo).
• Não é aconselhável usar mais de um sinalizador de compilação. Não há tantos métodos que precisam ser executados em contextos diferentes e, se esses métodos forem necessários, um módulo comum separado pode ser alocado para eles.
• O sinalizador "Call Server" só é significativo se o módulo for compilado "On the server". Portanto, todos os outros sinalizadores de compilação devem ser removidos para evitar vários problemas.
• Se os métodos do módulo forem usados ​​\u200b\u200bpara processamento de dados em massa, leitura e gravação no banco de dados, para aumentar a velocidade do trabalho, é melhor desativar o controle de acesso definindo o sinalizador "Privilegiado". Este modo está disponível apenas para módulos compartilhados compilados no servidor.

Módulo de formulário

Destina-se a processar ações do usuário, ou seja, vários eventos relacionados à entrada de dados e processamento da correção de sua entrada. O módulo de formulário regular é compilado inteiramente no cliente. Um módulo de formulário gerenciado, por outro lado, é claramente demarcado pelo contexto de execução, portanto, todas as variáveis ​​e métodos devem ter uma diretiva de compilação. Se a diretiva não for especificada explicitamente, essa variável ou método será compilado no lado do servidor. No módulo de formulário estão disponíveis seções para descrição de variáveis ​​e métodos, bem como uma seção para o programa principal.

módulo de objeto

Este módulo é típico para muitos objetos de configuração e destina-se, em geral, ao processamento de eventos de objetos. Por exemplo, os eventos de escrita e exclusão de objetos, o evento de postagem de documentos, etc.

Alguns eventos de módulo de objeto duplicam eventos de módulo de formulário. Por exemplo, eventos relacionados ao registro. No entanto, deve-se entender que os eventos do módulo de formulário serão executados apenas em um determinado objeto de formulário. Em geral, pode haver várias dessas formas. E os eventos do módulo objeto serão chamados em qualquer caso, mesmo no momento do programa trabalhar com o objeto. Portanto, se for necessário executar algum código em todos os casos, então é melhor usar um evento de módulo de objeto para isso.

O módulo de objeto é compilado exclusivamente no servidor. Nele você pode definir variáveis ​​e métodos de exportação que estarão disponíveis em outros módulos de configuração. Com a ajuda dessas propriedades e métodos, podemos expandir significativamente a funcionalidade do objeto.

módulo gerenciador de objetos

Este módulo existe para muitos objetos de configuração. O principal objetivo deste módulo é redefinir o evento de seleção padrão que ocorre no momento da entrada por linha e ampliar a funcionalidade do gerente. O módulo é compilado no lado do servidor. É possível definir propriedades e métodos de exportação. Chamar os métodos de exportação do gerenciador não requer a criação do próprio objeto.

Para todos os itens acima, você pode adicionar uma imagem de alguns módulos de configuração e maneiras de chamar métodos mutuamente no modo de aplicativo gerenciado. A seta indica a direção em que você pode ir para chamar o método correspondente. Como pode ser visto no diagrama, o contexto do servidor está completamente fechado. Mas a partir do contexto do cliente, é possível acessar os métodos do servidor.

Símbolos no esquema: O.M. Cliente - Módulo comum do cliente; O.M. Servidor - Módulo comum do servidor; MF Cliente - Procedimentos de cliente do módulo de formulário; MF Servidor - Procedimentos do servidor do módulo de formulário.