O artigo continua a série “Primeiros passos no desenvolvimento 1C”.

Na configuração da plataforma 1C:Enterprise, ao exibir informações, são mais utilizadas tabelas que exibem diversas listas de informações. Trabalhar com essas listas pode ocorrer tanto na forma de uma lista quanto na forma de um elemento (processamento).

Neste artigo, conheceremos essas opções de personalização de listas e também veremos outros recursos de personalização de formulários por parte do usuário.

Aplicabilidade

O artigo discute a Interface Gerenciada na versão “Versão 8.2” da configuração desenvolvida na plataforma 1C 8.3.4.482.

Se você trabalha com configurações que suportam esta interface, as informações são relevantes para as versões atuais da plataforma.

Se você estiver trabalhando na nova interface do Taxi, os nomes de alguns comandos de configuração, bem como a sequência geral de ações, podem ser um pouco diferentes.

Além disso, a versão atual da plataforma adicionou novos recursos de pesquisa em listas.

Configurando formulários e trabalhando com listas

Para elementos de formulário gerenciados, é possível alterar a visibilidade e algumas outras propriedades. Para estes fins de forma controlada no menu Todas as ações serve como item Alterar formulário.

Após clicar neste comando, a janela “Configurações do formulário” aparecerá.

Na janela que aparece, você pode usar caixas de seleção para alterar a visibilidade de alguns detalhes. Neste caso, o formulário é dimensionado automaticamente.

Você pode alterar a ordem dos detalhes. Adicione um novo grupo e coloque nele alguns detalhes (elementos), definindo a opção para seu agrupamento (horizontal, vertical).

Os detalhes incluídos no grupo serão publicados de acordo. Além disso, você pode configurar propriedades como largura, altura e dados de cabeçalho dos elementos.

Você pode definir atributos que serão ativados quando o formulário for aberto.

Um recurso importante é a capacidade de adicionar novos campos ao formulário. Isto se torna possível através de atributos de tipo de referência.

Por exemplo, ter um atributo de tipo de referência no formulário Contraparte, pode adicionar A pessoa de contato, se este detalhe estiver presente no diretório “Contrapartes”.

Se necessário, campos adicionais podem ser removidos. Os campos criados no configurador não podem ser excluídos. Todas as configurações feitas pelo usuário são salvas.

Para retornar às configurações padrão na janela Configurações de formulário no menu Todas as ações você deve selecionar o item Definir configurações padrão.

Além de customizar formulários na interface gerenciada, é possível customizar listas (elementos de diretório, documentos).

Na forma de uma lista no menu Todas as ações contém um comando especial Personalize a lista.

A janela “Configurações da lista” será aberta. Nesta janela você pode selecionar, classificar, definir formatação condicional e agrupamento.

A figura mostra um formulário para edição da seleção.

A seleção pode ser feita através de vários campos. Neste caso, por padrão a seleção funcionará de acordo com a condição AND. Você também pode usar as condições OR e NOT.

Para usar a condição OR (NOT), você precisa adicionar o grupo apropriado (Grupo OR, Grupo NOT) usando o comando Condições de Grupo.

A figura mostra um formulário para definir campos de classificação.

O agrupamento pode ser configurado. Na figura, o campo para agrupamento está selecionado Contraparte.

A próxima figura mostra como será realizado o agrupamento.

Você pode colorir livremente a lista ou aplicar outros elementos de design condicional (seleção de fonte, formatação específica) de acordo com uma determinada condição, bem como selecionar uma lista de campos a serem formatados.

A figura mostra o resultado do design condicional do fundo do campo Soma.
Quando o valor for > 100.000.

Deve-se observar que é possível visualizar diretórios em modo hierárquico.

A visualização hierárquica dos diretórios pode ser configurada através do item Modo de visualização no menu Todas as ações. Você pode escolher uma das opções: Lista hierárquica, Lista, Árvore.

Também é possível configurar seu próprio agrupamento de elementos de diretório por determinados detalhes.

Por exemplo, você pode agrupar itens por fornecedor. O exemplo é semelhante ao agrupamento dos documentos “Vendas de bens e serviços” por contrapartes.

Um recurso conveniente é a seleção múltipla em listas e posterior execução de ações de grupo (postagem, cancelamento, desmarcação de exclusão).

Os objetos na lista são selecionados mantendo pressionada a tecla Mudança ou Ctrl.

A busca por um determinado valor em uma lista possui características próprias. A pesquisa opera em modo de seleção. Somente as linhas que satisfazem a condição de pesquisa permanecem.

Para pesquisar por valor na coluna atual, basta posicionar o cursor na coluna desejada e clicar no botão Encontrar no painel de comando. Aparecerá uma janela na qual você também deverá clicar no botão Encontrar.

Para tornar sua pesquisa mais específica, você pode usar a caixa de seleção Pesquisar em encontrado.

Ao pesquisar uma linha de dados de um tipo de referência (por exemplo, unidades de medida), você deve selecionar a opção de pesquisa apropriada ...(por linha).

Isso conclui com listas e formas de configurá-las. No próximo artigo continuaremos conhecendo a interface e veremos uma ferramenta conveniente para informar o usuário, da qual não falamos antes. Que tipo de instrumento é esse? :)

1C são criados automaticamente pelo sistema ao usar a solução do aplicativo. Eles são a base para apresentar (exibir) informações no sistema 1C:Enterprise.

Estrutura do formulário 1C

O Formulário B é uma descrição lógica da composição do formulário. elementos descreve a aparência do formulário. A colocação dos elementos do formulário é realizada automaticamente pelo sistema no momento da sua exibição.

A parte exibida do formulário (visível ao usuário) é descrita como uma árvore que inclui elementos do formulário (veja na figura abaixo, o campo “Elementos do formulário”):

• grupo incluindo outros elementos,
• campos de entrada,
• caixas de seleção,
• comuta,
• botões,
• tabelas que incluem elementos de coluna, etc.

"Elementos do formulário 1C"

[colapso]

Um grupo de elementos de formulário pode ser representado como

1. painel com moldura,
2. painel com páginas (marcadores),
3. a própria página,
4. painel de comando.

Todas as funcionalidades do formulário são descritas a seguir:

• detalhes (dados com os quais o formulário funciona);
• comandos (ações executadas).

Personalizando a aparência de um formulário gerenciado

Personalizando a aparência de um formulário gerenciado pelo usuário

A aparência de um formulário gerenciado pode ser personalizada no nível do usuário. Para esta funcionalidade, nas ações do formulário existe um comando “Mais” - “Alterar formulário” (gerenciando apenas os elementos do formulário que são definidos na fase de desenvolvimento ou de acordo com regras padrão para geração automática de formulários).

"Mais" - "Mudar forma"

Comando "Mais" - "Alterar forma":

Após clicar em “Alterar formulário”, a janela de configurações do formulário 1C é exibida:

[colapso]

Além disso, no modo usuário é possível:

• altere a ordem dos formulários, mova-os de uma coluna para outra (se a área de trabalho estiver organizada em duas colunas), mas você não pode alterar o número de colunas da área de trabalho;
• exibir informações na forma de janelas separadas (ao chamar um comando de navegação, você precisa manter pressionada a tecla Shift).

Se seções forem usadas, quando você chamar um comando no painel de navegação, a lista correspondente será exibida na área de trabalho, substituindo o conteúdo anterior da área de trabalho.

Personalizando a aparência de um formulário gerenciado por um desenvolvedor

O desenvolvedor pode influenciar a disposição dos elementos com várias configurações. Pode determinar a ordem dos elementos, especificar sua largura e altura e também usar:

• comandos do próprio formulário;
• comandos globais usados ​​em toda a configuração;
• comandos parametrizáveis ​​que abrirão outros formulários com base nos dados específicos do formulário atual.

Figura (mudança do formulário 1C pelo desenvolvedor)

[colapso]

Ao desenvolver o Formulário 1C você deve:

1. No editor de formulários, inclua os detalhes e comandos necessários no formulário;
2. crie elementos de formulário que os exibam, determine a ordem dos elementos, especifique a largura e a altura (se necessário);
3. organize os elementos em grupos (se necessário).

1. Use configurações de visibilidade baseadas em função em elementos de formulário (visualização e edição de detalhes por , visibilidade personalizada de campos de formulário por função, uso de comandos por função) no caso de um grande número de funções na configuração (de várias dezenas). Em vez disso, as seguintes abordagens devem ser seguidas:
   • quando há grandes diferenças na aparência e funcionalidade do formulário dependendo da presença de determinadas funções para o usuário – desenvolver formulários separados, especializado para um conjunto específico de direitos de usuário;
   • com pequenas diferenças - realizar verificações de permissão no código. Deve-se ter em mente que o controle de visibilidade programática pode reduzir a velocidade de abertura do formulário, o que deve ser levado em consideração na escolha entre as abordagens propostas.
2. Use configurações de visibilidade baseadas em função na interface de comando de configuração, na interface de comando da seção principal e na área de trabalho da página inicial. Em vez disso, você deve definir permissões em seções da interface de comando e objetos incluídos na interface de comando ou na área de trabalho. Isso torna o comportamento da interface gerenciada mais previsível para o usuário e também facilita a investigação de erros.

Para obter informações mais detalhadas sobre como trabalhar com formulários, consulte o curso “Trabalhando com formulários em 1C:Enterprise 8.3”, http://www.1c.ru/rus/partners/training/uc1/course.jsp?id=161.

E Objeto de Transferência de Dados para estruturação de código, forma controlada no ambiente 1C 8.2.

Introdução

Vamos começar com uma breve descrição do conceito de “formulário gerenciado” e conceitos relacionados da plataforma 1C. Os conhecedores da plataforma podem querer pular esta seção.

Em 2008, foi disponibilizada uma nova versão da plataforma 1C: Enterprise 8.2 (doravante denominada Aplicação Gerenciada), que altera completamente toda a camada de trabalho com a interface. Isso inclui a interface de comando, formulários e o sistema de janelas. Ao mesmo tempo, não apenas o modelo de desenvolvimento da interface do usuário na configuração muda, mas também é proposta uma nova arquitetura para separar funcionalidades entre a aplicação cliente e o servidor.
O aplicativo gerenciado oferece suporte aos seguintes tipos de clientes:

• Cliente grosso (modo de inicialização normal e gerenciado)
• Cliente magro
• cliente da web

O aplicativo gerenciado usa formulários baseados em novas tecnologias. Eles são chamados Formulários gerenciados. Para facilitar a transição, os formulários anteriores (os chamados formulários regulares) também são suportados, mas sua funcionalidade não é desenvolvida e estão disponíveis apenas no modo de inicialização do Thick Client.
As principais diferenças dos formulários gerenciados para um desenvolvedor:

• Descrição declarativa, não “pixel por pixel” da estrutura. A colocação específica dos elementos é realizada automaticamente pelo sistema quando o formulário é exibido.
• Todas as funcionalidades do formulário são descritas como detalhes E equipes. Detalhes são os dados com os quais o formulário trabalha e comandos são as ações a serem executadas.
• O formulário é executado no servidor e no cliente.
• No contexto do cliente, quase todos os tipos de aplicativos estão indisponíveis e, portanto, é impossível alterar os dados na infobase.
• Para cada método ou variável de formulário, deve ser especificado diretiva de compilação, definindo o local de execução (cliente ou servidor) e acesso ao contexto do formulário.

Vamos listar as diretivas para compilar métodos de formulário:

• &NoCliente
• &No servidor
• &OnServerSem Contexto
• &OnClientOnServerSem Contexto

Vamos ilustrar o que foi dito acima. A captura de tela mostra um exemplo de formulário gerenciado e seu módulo em modo de desenvolvimento. Encontre a descrição declarativa, adereços, diretivas de compilação, etc.

Todas as discussões futuras serão sobre o lado direito da ilustração, sobre como estruturar o código do módulo e quais princípios permitirão implementar uma interação cliente-servidor eficaz.

Vamos definir o problema

Vários anos se passaram desde que a nova versão da plataforma 1C foi usada ativamente e muitas soluções (configurações) foram lançadas pela 1C e por seus diversos parceiros.
Durante esse período, os desenvolvedores desenvolveram um entendimento comum dos princípios da interação cliente-servidor ao criar formulários, e a abordagem para implementar módulos de software mudou nas novas realidades arquitetônicas?

Vejamos a estrutura do código (módulo de formulário) em vários formatos da mesma configuração padrão e tentemos encontrar padrões.
Por estrutura queremos dizer seções de código (na maioria das vezes são blocos de comentários) alocadas pelo desenvolvedor para agrupar métodos e diretivas de compilação para esses métodos.
Exemplo 1:
Seção de manipuladores de eventos Método - no cliente Método - no servidor Método - no cliente Seção de procedimentos e funções de serviço Funções auxiliares de controle de entrada
Exemplo 2:
Procedimentos e funções de serviço Documentos de pagamento Valores Manipuladores de eventos
Exemplo 3:
Procedimentos de serviço no servidor Procedimentos de serviço no cliente Procedimentos de serviço no servidor sem contexto Manipuladores de eventos de cabeçalho Manipuladores de eventos de comando
Exemplo 4:
Procedimentos de uso geral Manipuladores de eventos de formulário Procedimentos do subsistema “informações de contato”
Essencialmente, falta a estrutura do código ou, para dizer o mínimo, é semelhante ao que estava no Formulários 8.1:

• Palavras não informativas “Geral, Serviço, Auxiliar”.
• Tentativas tímidas de separar métodos cliente e servidor.
• Os métodos são frequentemente agrupados por elementos de interface “Trabalhando com a parte tabular Produtos, Informações de contato”.
• Arranjo arbitrário de métodos e grupos de códigos. Por exemplo, os manipuladores de eventos podem estar na parte superior em um formulário, na parte inferior em outro, nem sequer destacados em um terceiro, etc.
• E não esqueçamos que tudo isso está dentro de uma configuração.
• Sim, existem configurações em que as palavras “Geral, Serviço, Auxiliar” estão sempre nos mesmos lugares mas...

Por que você precisa de estrutura de código?

• Simplificação da manutenção.
• Simplifique o aprendizado.
• Registrando princípios gerais/importantes/de sucesso.
• ...sua opção

Por que o padrão de desenvolvimento existente da 1C não ajuda?

Vejamos os princípios publicados nos discos ITS e em vários “Guias do Desenvolvedor...” que são recomendados ao escrever um formulário gerenciado.

• Minimize o número de chamadas do servidor.
• Computação máxima no servidor.
• As chamadas de servidor não contextuais são mais rápidas que as contextuais.
• Programe tendo em mente a comunicação cliente-servidor.
• e assim por diante.

São slogans absolutamente verdadeiros, mas como implementá-los? Como minimizar o número de chamadas, o que significa programar em modo cliente-servidor?

Padrões de design ou sabedoria geracional

A interação cliente-servidor tem sido usada em diversas tecnologias de software há décadas. A resposta às questões delineadas na secção anterior é conhecida há muito tempo e está resumida em dois princípios básicos.

• Fachada Remota(doravante denominada Interface de Acesso Remoto)
• Objeto de transferência de dados(doravante denominado Objeto de Transferência de Dados)

Uma palavra de Martin Fowler, sua descrição destes princípios:

• … Cada objeto potencialmente destinado ao acesso remoto deve ter interface de baixa granularidade, o que minimizará o número de chamadas necessárias para realizar um procedimento específico. ... Em vez de solicitar uma fatura e todos os seus itens separadamente, você precisa ler e atualizar todos os itens da fatura em uma única solicitação. Isso afeta toda a estrutura do objeto...Lembre-se: interface de acesso remoto não contém lógica de domínio.
• ...se eu fosse uma mãe carinhosa, com certeza diria ao meu filho: “Nunca escreva objetos de transferência de dados!” Na maioria dos casos, os objetos de transferência de dados nada mais são do que conjunto de campo inchado... O valor deste monstro nojento reside unicamente na possibilidade transmitir várias informações pela rede em uma chamada- uma técnica de grande importância para sistemas distribuídos.

Exemplos de modelos na plataforma 1C

A interface de programação de aplicativos disponível para o desenvolvedor ao desenvolver um formulário gerenciado contém muitos exemplos desses princípios.
Por exemplo, o método OpenForm(), uma interface “grosseira” típica.
OpeningParameters = Nova Estrutura("Parâmetro1, Parâmetro2, Parâmetro3", Valor1, Valor2, Valor3); Formulário = OpenForm(NomeDoFormulário, Parâmetros de Abertura);
Compare com o estilo adotado na v8.1.
Formulário = GetForm(NomeFormulário); Formulário.Parâmetro1 = Valor1; Formulário.Parâmetro2 = Valor2; Formulário.Open();

No contexto de um formulário gerenciado, existem muitos “Objetos de Transferência de Dados”. Você pode selecionar sistêmico E definido pelo desenvolvedor.
Os do sistema modelam um objeto de aplicação no cliente, na forma de um ou mais elementos de dados de formulário. É impossível criá-los sem referência aos detalhes do formulário.

• Estrutura DataForms
• DataFormsCollection
• DataFormStructureWithCollection
• Árvore de Formas de Dados

A conversão de objetos de transferência de dados do sistema em tipos de aplicativos e vice-versa é realizada usando os seguintes métodos:

• ValorInFormData()
• FormDataValue()
• CopiarFormData()
• ValueInFormAttributes()
• FormAttributesValue()

Freqüentemente, a conversão explícita é usada ao adaptar uma solução existente. Os métodos podem esperar (usar recursos) parâmetros de entrada, como ValueTable em vez de FormDataCollection, ou o método foi definido no contexto de um objeto de aplicativo e tornou-se indisponível para chamada direta do formulário.
Exemplo 1C v8.1:
// no cliente no contexto do formulário FillUserCache(DepartmentLink)
Exemplo 1C v8.2:
// no servidor no contexto do formulário ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueFormAttributes(ProcessingObject, "Objeto");

Os objetos de transferência de dados, cuja estrutura é determinada pelo desenvolvedor, são um pequeno subconjunto dos tipos disponíveis no cliente e no servidor. Na maioria das vezes, os seguintes são usados ​​​​como parâmetros e resultados de métodos de uma interface “grosseira”:

• Tipos primitivos (string, número, booleano)
• Estrutura
• Correspondência
• Variedade
• Links para objetos de aplicativo (identificador exclusivo e representação de texto)

Exemplo: o método aceita uma lista de pedidos para alteração de status e retorna uma descrição dos erros ao cliente.
Função &OnServerWithoutContext ServerChangeOrderStatus(Pedidos, NewStatus) Erros = Nova Correspondência(); // [pedido][descrição do erro] Para cada pedido do ciclo de pedidos StartTransaction(); Tente DocOb = Order.GetObject(); …. outras ações, possíveis não apenas com o pedido... Exception CancelTransaction(); Erros.Insert(Ordem, ErroDescrição()); FimTentativa; Fim do Ciclo; Erro de retorno; EndFunction // ServerChangeOrderStatus()

Estruturando o código

Os principais objetivos que o módulo de formulário gerenciado deve refletir e as abordagens para a solução.

• Separação clara de código de cliente e servidor. Não esqueçamos que no momento da execução são dois processos interativos, cada um com funcionalidades disponíveis significativamente diferentes.
• Identificação clara da interface de acesso remoto, quais métodos de servidor podem ser chamados do cliente e quais não podem? Os nomes dos métodos de interface remota começam com o prefixo "Servidor". Isso permite que você veja imediatamente a transferência de controle para o servidor durante a leitura do código e simplifica o uso da ajuda contextual. Observe que a recomendação oficial (ITS) sugere nomear métodos com postfixes, por exemplo, ChangeOrderStatusOnServer(). No entanto, repetimos que nem todos os métodos do servidor podem ser chamados a partir do cliente e, portanto, a acessibilidade lógica é mais importante do que o local de compilação. Portanto, com o prefixo “Servidor” marcamos apenas os métodos disponíveis para o cliente; vamos chamar o método exemplo ServerChangeOrderStatus().
• Legibilidade. Por uma questão de gosto, aceitamos o pedido quando o módulo inicia com os procedimentos de criação de formulário no servidor e métodos de acesso remoto.
• Manutenção. Deve haver um local claro para adicionar novo código. Um ponto importante é que os templates de métodos criados automaticamente pelo configurador são adicionados ao final do módulo. Como os manipuladores de eventos para elementos de formulário são geralmente criados automaticamente, o bloco correspondente é localizado por último, para não arrastar cada manipulador para outro local no módulo.

Abaixo está a estrutura básica do módulo que implementa os objetivos listados.

• Opção gráfica – mostra claramente o fluxo principal de execução.
• A opção de texto é um exemplo de design de modelo para inserir rapidamente uma estrutura em um novo módulo de formulário.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Data=""/> // <Описание> // // /////////////////////////////////////////// // //////////////////////// // VARIÁVEIS DO MÓDULO ///////////////// // /////////////////////////////////////////// //// ////////// // NO SERVIDOR //******* EVENTOS NO SERVIDOR ******* &No Servidor Procedimento Quando Criado no Servidor (Falha, Processamento Padrão) / /Inserir o conteúdo do manipulador Fim do Procedimento //******* INTERFACE DE ACESSO REMOTO ******* //******* LÓGICA DE NEGÓCIO NO SERVIDOR ******* ///////// /////////////////////////////////////// ////// ////////////////// // MÉTODOS COMUNS DE CLIENTE E SERVIDOR /////////////// /////// //////////////////////////////////////// ///// //////// // NO CLIENTE //******* LÓGICA DE NEGÓCIO NO CLIENTE ******* //******* EQUIPE * ****** //******* EVENTOS DE CLIENTES ******* ///////////////////////// ///// ////////////////////////////////////////// // // / PRINCIPAIS OPERADORES DO PROGRAMA

Perguntas relacionadas

Concluindo, descreveremos diversas áreas nas quais é útil pensar ao programar a interação cliente-servidor.

• Opções de implementação de interface de acesso remoto. Assincronia, nível de detalhe...
• Cache. 1C tomou uma decisão arquitetônica malsucedida, introduzindo cache apenas no nível de chamada de métodos de módulos comuns e não fornecendo recursos de controle (tempo de relevância, redefinição sob demanda).
• Chamadas de servidor implícitas. Não se esqueça dos recursos tecnológicos: muitas operações “inofensivas” no cliente fazem com que a plataforma entre em contato com o servidor.

Os formulários existentes em 1C:Enterprise são projetados para que o usuário interaja interativamente com os dados da base de informações. Para disponibilizar esse recurso, o formulário é “preenchido” com as funcionalidades necessárias.

A funcionalidade do formulário é determinada pela composição de seus detalhes e comandos. Os detalhes do formulário são os dados com os quais o formulário funciona. Comandos de formulário são ações que um formulário pode executar nos dados. Porém, só porque um comando está em um formulário não permite que você use sua funcionalidade. Da mesma forma, os próprios detalhes não oferecem a capacidade de exibir e editar dados.
Para usar comandos, para exibir e editar dados armazenados em detalhes, são usados ​​​​elementos de formulário associados aos comandos e detalhes correspondentes.
Sem entrar em detalhes, a relação entre comandos, detalhes e elementos do formulário pode ser representada por um diagrama.

Relacionamento entre comandos, detalhes e elementos do formulário

Os seguintes recursos principais dos formulários podem ser observados.
Primeiramente, o novo formulário não é desenhado detalhadamente pelo desenvolvedor, mas é construído automaticamente pelo sistema. O desenvolvedor está no modo de configuração:

• define a composição do formulário na forma de uma árvore de elementos
• descreve o comportamento de um formulário definindo valores para suas propriedades e/ou implementando procedimentos em uma linguagem integrada.

Ao construir uma interface para um determinado usuário, o sistema utiliza esta descrição declarativa para criar o formulário e posicionar seus elementos.
Em segundo lugar, ao criar um formulário, é utilizado um novo modelo de gerenciamento de acessibilidade e visibilidade dos elementos do formulário. Isso leva em consideração:

• configurações de direitos por funções de usuário
• dependência dos elementos do formulário nas opções funcionais
• personalização do formulário realizada pelo desenvolvedor na fase de configuração da solução do aplicativo
• customização do formulário realizada pelo usuário na fase de operação da solução aplicacional.

Funcionalidade padrão

Em 1C:Enterprise você não precisa criar formulários para apresentar e processar objetos de dados. Neste caso, ao executar comandos para abrir formulários, o sistema criará automaticamente o formulário necessário em tempo real. O formulário gerado terá funcionalidade e apresentação padrão. O que determina a apresentação e funcionalidade de um formulário?
A apresentação padrão e a funcionalidade de um formulário são determinadas pelo objeto de interface do formulário gerenciado (por exemplo, a capacidade do formulário ser fechado) e pela extensão do formulário (por exemplo, a capacidade de gravar dados do formulário na infobase).
Uma extensão de formulário são propriedades, métodos, parâmetros e comandos adicionais que aparecem no objeto Form quando o atributo principal é atribuído a ele.

ATENÇÃO!
Apenas um atributo pode ser selecionado como principal
nos detalhes do formulário.

É importante entender que:

• a funcionalidade adicional fornecida está incluída no objeto Formulário Gerenciado, ou seja, torna-se parte integrante dele
• a composição dos recursos adicionais é determinada pelo tipo do atributo principal do formulário, ou seja, o tipo de dados que o formulário se destina a editar.

As extensões também podem estar presentes nos elementos do formulário. Tal como acontece com o próprio formulário, a composição da extensão, ou seja, propriedades adicionais, métodos, etc., de um elemento de formulário é determinada pelo tipo de atributo ao qual o elemento está associado.
Caso seja necessário implementar uma apresentação de dados não padronizada ou funcionalidade não padronizada, o desenvolvedor pode criar de forma independente um formulário no configurador. O editor de formulários é usado para criar formulários. Usando este editor, o desenvolvedor cria o conjunto necessário de detalhes e comandos para o formulário, bem como os elementos do formulário com os quais eles são exibidos.

Comandos de formulário

Para conhecer os comandos do formulário, vamos criar outro formulário para o documento Consumo de Mercadorias. No menu de contexto do nó Formulários deste documento, selecione Adicionar.

Adicionando um subformulário

Como resultado, a janela do designer de formulário será aberta. Na janela do designer, selecione o tipo de formulário – Document Form, marque a caixa de seleção Atribuir formulário como principal e defina o nome MainForm. Clique no botão Concluir.

Janela de design de formulário

1C8: Janela do designer de formulário

Como resultado do trabalho do designer, é criado um formulário de documento, este formulário é atribuído como principal, ou seja, é utilizado por padrão para trabalhar com o documento. Depois que o designer concluir o formulário criado, a janela do editor de formulário será aberta.

Editor de formulários com formulário de documento criado automaticamente

OBSERVAÇÃO
No editor de formulários, os principais detalhes do formulário são destacados em negrito.

Se você abrir o documento Consumo de Mercadorias no modo 1C:Enterprise, nós veremos que o formulário que criamos é usado para trabalhar com o documento.

Formulário para edição do documento “Consumo de bens”

Os elementos que fornecem acesso aos comandos estão localizados nos painéis de comando. No nosso caso, o sistema gerou um painel de comando de formulário e um painel de comando de tabela de produtos. Você pode selecionar qualquer um dos comandos disponíveis no menu Todas as ações do painel de comandos correspondente. Para agilizar o acesso aos comandos, alguns deles (os mais importantes ou mais utilizados) são apresentados como botões diretamente nos painéis de comando.
O que “orienta” o sistema na formação da composição das equipes uniformizadas? Quais equipes devem estar uniformizadas? Para responder a essas perguntas, você precisa se lembrar do objetivo principal do formulário - o processamento interativo de dados. Portanto, o formulário deve conter comandos que forneçam ao usuário a capacidade de processar os dados do formulário e de acessar os dados associados aos dados processados.

Para processar dados de formulário - comandos de formulário padrãoé

O formulário deve conter comandos para processamento de dados e gerenciamento do formulário. Esses recursos são fornecidos por comandos de formulário local padrão. No editor de formulários eles são apresentados na aba Comandos padrão editor de comandos.

Comandos de formulário padrão no editor e na interface

1C8: Comandos de formulário padrão no editor e interface

Esses comandos são fornecidos pelo formulário e pela extensão do formulário. A composição dos comandos fornecidos pelo formulário é padrão e não depende dos dados do formulário - estes são os comandos:

• Referência
• Alterar formulário...
• Fechar
• Salvar configurações...
• Restaurar configurações...

A composição dos comandos fornecidos pela extensão depende do tipo do atributo principal do formulário. No nosso caso, o atributo principal do formulário é atribuído ao atributo Object com o tipo de dados DocumentObject.ProductConsumption (ver figura acima).A extensão correspondente a este tipo de dados forneceu os comandos:

• Deslize e feche
• Escreva
• Reler
• cópia de
• Marcar para exclusão
• Desmarcar exclusão
• Excluir
• Conduta
• Cancelamento.

ATENÇÃO!
É necessário distinguir entre comandos de objeto de configuração padrão e comandos de formulário padrão. Os primeiros são usados ​​na interface de comando global e são fornecidos pelo objeto de configuração. Estes últimos são utilizados no formulário e são fornecidos pelo próprio formulário, sua extensão e extensões dos elementos do formulário do tipo Tabela.

Para facilitar o desenvolvimento de algoritmos de gerenciamento de formulários, os comandos de formulário padrão incluem os seguintes comandos:

• Não,
• Cancelar,
• Abortar,
• Pular,
• Repita.

Se tal comando for adicionado ao formulário, quando o usuário o selecionar, as seguintes ações serão executadas:

• para um formulário aberto em modo modal, o formulário é fechado e um valor do tipo DialogReturnCode correspondente ao comando selecionado é retornado
• Para um formulário aberto no modo sem janela restrita, apenas o formulário é fechado.

Se os elementos do formulário contiverem tabelas, serão adicionados comandos aos comandos locais padrão do formulário para processar os dados exibidos nesses elementos. No documento Consumo do produto Existe uma parte tabular, que é representada nos dados do formulário pelo atributo Produtos. Para exibir uma lista de produtos no formulário, utilize o elemento Produtos do tipo Tabela. Os comandos locais padrão do formulário incluem comandos para processamento de dados tabulares - o nó Produtos no editor de comandos.

Comandos de tabela padrão no editor e na interface

Para trabalhar com dados vinculados – comandos parametrizados globais

Ao processar dados de formulário, pode ser necessário visualizar os dados associados aos dados que estão sendo processados. Pode ser, por exemplo, um conjunto de lançamentos no registo de liquidações mútuas com contrapartes, subordinados ao documento que está a ser processado, ou uma lista de preços de mercadorias vendidas, etc. , por exemplo, insira um documento de pagamento com base em um documento de vendas ou imprima códigos de barras das mercadorias vendidas, etc.

O acesso aos dados vinculados é fornecido por comandos de navegação parametrizáveis ​​globais, e o processamento de dados vinculados é fornecido por comandos de ação parametrizáveis ​​globais. No editor de formulários, eles são apresentados na aba Comandos globais do editor de comandos.

Comandos parametrizáveis ​​globais no editor e na interface

Esses comandos são fornecidos pela interface de comando global da solução do aplicativo. A composição dos comandos disponíveis no formulário depende do tipo de parâmetro do comando parametrizado (ver. "Comandos arbitrários"). Esses comandos globais parametrizados estão disponíveis no formulário para o qual, no contexto do formulário, você pode obter os valores dos parâmetros do tipo necessário.
No editor de comandos, a origem do parâmetro de um comando é indicada entre parênteses após o comando. Por exemplo, para o comando de abertura de lista de cadastro de vendas, o parâmetro é um link para o documento que está sendo editado.
Se houver várias fontes para um comando em um formulário, o comando será representado como um nó de árvore e a lista de fontes será representada como os elementos desse nó. Tal comando pode ser incluído no formulário comandos com qualquer uma das fontes (ou várias instâncias do mesmo comando com fontes diferentes).
Para trabalhar com a funcionalidade do aplicativo - comandos independentes globais Ao processar dados de formulário, pode ser necessário usar funcionalidades do aplicativo que não estão diretamente relacionadas aos dados que estão sendo processados.
Por exemplo, ao processar dados de documentos, precisamos realizar uma pesquisa nos dados ou inserir um novo tipo de preço. Equipes globais independentes irão ajudá-lo a realizar essas operações. No editor de formulários, eles são apresentados na aba Comandos globais do editor de comandos.

Comandos globais independentes no editor e na interface

Comandos globais independentes são fornecidos pela interface de comando global. No editor de comandos, os comandos globais independentes são agrupados em seções da interface de comando global. O comando estará disponível em todas as seções da interface de comando global na qual está incluído.

Métodos para formar a composição da equipe

Conhecendo as fontes dos comandos de formulário, vamos ver quais opções o sistema nos oferece para criar a composição dos comandos de formulário.

OBSERVAÇÃO
Existe outra fonte de comandos para o formulário - o desenvolvedor, que pode criar comandos locais arbitrários para o formulário. Falaremos sobre esses comandos um pouco mais tarde (consulte "Se faltarem comandos padrão").

No caso mais geral, existem três opções:

• automático – a composição dos comandos do formulário é determinada pelo sistema de forma totalmente automática
• combinado – a composição dos comandos do formulário é determinada automaticamente pelo sistema, e o desenvolvedor, usando o editor de formulário, corrige-a
• manual – a composição dos comandos do formulário é determinada inteiramente pelo desenvolvedor.

A opção automática é a mais rápida e menos dispendiosa em termos de desenvolvimento de uma solução aplicacional - o sistema faz tudo de forma independente. A opção de combinação é provavelmente a mais comumente usada. Com esta abordagem, o desenvolvedor intervém no funcionamento do sistema somente quando o conjunto de comandos gerados pelo sistema não fornece a funcionalidade necessária para o processamento dos dados do formulário. Na grande maioria dos casos, a intervenção expressa-se numa simples ampliação da composição das equipas uniformizadas. A opção manual oferece oportunidades máximas para gerenciar a composição dos comandos do formulário e seu posicionamento. No entanto, exige que o desenvolvedor execute uma quantidade significativa de trabalho meticuloso.

A plataforma contém um grande número de mecanismos que facilitam o processo de implementação e proporcionam maiores oportunidades de customização da solução aplicacional. O que em outros sistemas precisa ser feito adicionando ou reescrevendo o código do programa, em 1C:Enterprise 8 pode ser feito com apenas alguns cliques do mouse. Às vezes até mesmo no modo de usuário. Sem modificar a própria solução da aplicação, sem alterar o código do programa.

Via de regra, uma solução de aplicativo contém todas as funções necessárias para a operação completa. No entanto, pode haver requisitos especiais para uma implementação específica. O implementador pode criar novas funções para atender a essas necessidades. A maneira mais conveniente de fazer isso é copiar e alterar as funções já existentes na solução do aplicativo.

Configurando o painel de seção

Você pode alterar a composição do painel de seção no Configurador no modo 1C:Enterprise.

Configurando a página inicial

A composição dos formulários localizados na página inicial pode ser alterada no Configurador com detalhes por função, ou individualmente para um ou vários usuários no modo 1C:Enterprise.

Configurando a interface de comando da seção principal

Você pode alterar a composição das equipes exibidas na seção principal do Configurador com detalhes por função.

Configurando interfaces de comando de partição

A composição dos comandos exibidos em uma determinada seção da solução do aplicativo pode ser alterada no Configurador com detalhes por função. Ao mesmo tempo, é possível configurar todas as seções de uma vez (o editor "Todos os subsistemas") e cada seção separadamente (o editor da interface de comando).

Configurando formulários