lar » Esporte » Switches, aplicação regular, formulários gerenciados. Switches, aplicação regular, formulários gerenciados 1c problemas com formulários gerenciados

Switches, aplicação regular, formulários gerenciados. Switches, aplicação regular, formulários gerenciados 1c problemas com formulários gerenciados

A plataforma 1C:Enterprise permite adicionar e alterar programaticamente elementos de um formulário gerenciado. Vamos descobrir por que isso pode ser necessário.

A modificação do software do formulário pode ser necessária em vários casos:

Ao finalizar as configurações padrão para facilitar o procedimento de atualização posterior. Neste caso, apenas o módulo do formulário será alterado. Os módulos são muito mais fáceis de atualizar do que os formulários.
Ao implementar alguns algoritmos comuns. Por exemplo, no subsistema “Proibição de edição de detalhes de objetos”, um botão pode ser criado programaticamente para todos os objetos conectados ao subsistema para permitir a capacidade de editar detalhes.
Ao implementar alguns algoritmos específicos. Por exemplo, no diretório Nomenclatura, são criados campos para edição de detalhes adicionais.

Em um formulário gerenciado, você pode adicionar, alterar e excluir programaticamente:

requisitos;
equipes locais;
elementos.

Todas essas operações são possíveis apenas no servidor.

A remodelagem programática tem limitações:

Você só pode excluir detalhes/comandos/elementos adicionados programaticamente. Você não pode excluir programaticamente objetos criados no configurador.
Você não pode atribuir um atributo como principal.

Alterando comandos de formulário

Para gerenciar a composição de comandos para um objeto Formulário Gerenciado há uma coleção Equipes

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

Quantidade ()

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

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

A coleção Teams está disponível no cliente e no servidor. Você pode alterar a coleção (métodos Add() e Delete()) apenas no servidor. Você pode pesquisar e obter o número de elementos (métodos Find () e Count ()) tanto no cliente quanto no servidor.

Como exemplo de trabalho com comandos de formulário, vamos criar um novo comando ChangeHistory com o título “ChangeHistory...”, que chamará o manipulador Histórico de exibição(). A criação ocorre quando o formulário é aberto.

&No servidor
Procedimento WhenCreatingOnServer (Falha, Processamento Padrão)
Equipe = Equipes. Adicionar( "História das Mudanças");
Equipe . Ação = ;
Equipe . Título = “Histórico de mudanças…”;
Fim do procedimento
&NoCliente
Procedimento Connectable_DisplayHistory(Comando)
//comando ações
Fim do procedimento

O manipulador de comandos deve estar localizado em um formulário e ter uma diretiva de compilação &OnClient.

Alterando detalhes do formulário

A leitura da composição dos detalhes do formulário é realizada pela função Obtenha detalhes(< Путь >) retornando uma matriz do tipo FormAttributes. O parâmetro function especifica o caminho para o atributo pai (como uma string). Se o parâmetro for omitido ou uma string vazia for especificada, os detalhes de nível superior serão retornados.

A alteração dos detalhes é feita usando o método Detalhes da alteração(<Detalhes adicionados>, <Detalhes removíveis>) objeto Formulário Gerenciado. Para parâmetros Detalhes adicionados E Detalhes removíveis São transmitidos arrays com elementos do tipo Form Attributes.

Atenção!

O processo de alteração da composição dos detalhes consome muitos recursos. O formulário está realmente sendo recriado. Nesse sentido, o trabalho com detalhes do formulário é realizado em lote.

Vamos criar um novo atributo de formulário com o nome Comprador:

AddedDetails = Nova Matriz;
Detalhes adicionados. Adicionar(Novos atributos de formulário(“Comprador”, Descrição do Novo Tipo (“DirectoryLink. Contrapartes”), “Cliente”));

// Mudanças na composição dos detalhes
);

Alterando elementos do formulário

Para controlar a composição dos elementos de um objeto Formulário Gerenciado há uma coleção Elementos. A coleção possui vários métodos:

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

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

Quantidade ()

Encontrar (< Имя >)

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

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

A coleção Items está disponível no cliente e no servidor. Modificar uma coleção (Inserir métodos () , Adicionar (), Mover () e Excluir ()) estão disponíveis apenas no servidor. Você pode pesquisar e obter o número de elementos (métodos Find () e Count ()) tanto no cliente quanto no servidor. Os elementos da coleção podem ser:

FormGrupo;
FormTable;
FormField;
Botão de formulário.

Você pode atribuir programaticamente manipuladores de eventos a elementos de formulário. O método é destinado a esses fins DefinirAção(< ИмяСобытия>, < Действие >) .

Vejamos alguns dos exemplos mais comuns de trabalho com comandos, detalhes e elementos de formulário.

Adicionando um comando e seu botão associado:

//Cria um comando
Equipe = Equipes. Adicionar( "História das Mudanças");
Equipe . Ação = "Plug-in_DisplayHistory"; // O formulário deve conter um procedimento com o nome especificado
Equipe . Cabeçalho = “Histórico de mudanças…”;
// Cria um botão e associa-o a um comando
Elemento = Itens. Adicionar( "História das Mudanças", Type("FormButton" ));
Elemento.CommandName = "História das Mudanças";

Adicionando um atributo e o campo de entrada associado:

//Descrição dos detalhes adicionados
AddedDetails = Nova Matriz;
Detalhes adicionados. Adicionar(Novos adereços de formulário (“Comprador”, Nova descrição de tipo ( "DirectoryLink. Contrapartes"), "Cliente" ));
//Alterando a composição dos detalhes
ChangeDetails(Detalhes Adicionados);
// Criando um campo de entrada e conectando com atributos
Elemento = Itens. Add("Comprador", Type("FormField" ));
Elemento . Visualizar = FormFieldView. Campo de entrada;
Elemento . Caminho para dados= "Comprador";

Atribuindo um manipulador de eventos a um elemento de formulário:

ItemCliente. Definir ação("Quando muda" , "Connected_BuyerOnChange");

&NoCliente
Procedimento Connected_BuyerOnChange(Elemento)
// Ações do evento
Fim do procedimento

Atenção!

Procedimentos definidos como manipuladores de eventos do código usando o método DefinirAção(), é recomendado definir o prefixo Connectable_.

Atenção!

Você pode baixar o processamento com exemplos de pesquisa programática e alteração de detalhes, comandos e elementos de um formulário gerenciado.

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.

Formulários em 1C:Enterprise destinam-se à exibição e edição de informações contidas no banco de dados. Os formulários podem pertencer a objetos de configuração específicos ou existir separadamente deles e são usados por toda a solução do aplicativo.

Por exemplo, um diretório Nomenclatura pode ter vários formulários que serão usados para fins específicos - edição de um elemento de diretório, exibição de uma lista, etc.:

Junto com isso, podem existir formulários gerais que não pertencem a objetos de configuração específicos - formulários gerais.

Formulários básicos

Cada objeto de configuração pode ser usado para executar algumas ações padrão. Por exemplo, para qualquer diretório, você pode precisar exibir uma lista de seus elementos, exibir elementos individuais do diretório, exibir um grupo do diretório, selecionar elementos e grupos de elementos do diretório. Para qualquer documento, a lista de tais ações será muito menor: visualizar uma lista de documentos, selecionar em uma lista de documentos e visualizar um documento separado.

Para garantir que tais ações padrão sejam executadas com os dados dos objetos de solução da aplicação, para cada um deles existe um conjunto de formulários básicos que serão utilizados na execução das ações correspondentes. Qualquer um dos formulários subordinados a este objeto pode ser atribuído como principal. Por exemplo, no diretório Nomenclatura Podem existir os seguintes formulários básicos:

E o documento Recebimento de mercadorias e serviços a composição dos formulários principais será diferente:

Assim, se o usuário quiser visualizar a lista de diretórios Nomenclatura ou lista de documentos Recebimento de mercadorias e serviços, o sistema abrirá o formulário correspondente designado como formulário de lista para esses objetos.

Formulários gerados automaticamente

Uma característica importante do sistema 1C:Enterprise 8 é o mecanismo de formulários gerados automaticamente. Este mecanismo libera o desenvolvedor de ter que criar todos os formulários possíveis para cada objeto de configuração. Basta o desenvolvedor adicionar um novo objeto de configuração, e o próprio sistema irá gerar, nos momentos certos do trabalho do usuário, os formulários necessários para exibir as informações contidas neste objeto.

Assim, o desenvolvedor precisa criar seus próprios formulários de objetos de solução de aplicação somente se eles tiverem diferenças (design diferente ou comportamento específico) dos formulários gerados automaticamente pelo sistema.

Vinculando um formulário aos dados

O fato de um formulário pertencer a um objeto de configuração específico não determina a composição dos dados exibidos no formulário. O fato de o formulário pertencer, por exemplo, a um diretório Nomenclatura, permite atribuí-lo como um dos formulários principais deste diretório, mas não determina de forma alguma quais dados este formulário exibirá e qual será seu comportamento.

Para associar um formulário aos dados, são utilizados os detalhes do formulário, que indicam a lista de dados exibidos pelo formulário. Todos os formulários, por si só, têm o mesmo comportamento, independentemente dos dados que exibem. No entanto, um dos atributos do formulário pode ser designado como seu atributo principal (está destacado em negrito), caso em que o comportamento padrão do formulário e suas propriedades serão complementados dependendo do tipo do atributo principal do formulário:

Por exemplo, se um documento for atribuído como atributo principal do formulário Recebimento de mercadorias e serviços, então ao fechar o formulário o sistema solicitará a confirmação da gravação e postagem deste documento. Se você atribuir, digamos, um diretório como o atributo principal do formulário Nomenclatura, essa solicitação de confirmação não aparecerá ao fechar o formulário.

Estrutura do formulário

A principal característica dos formulários é que eles não são desenhados detalhadamente pelo desenvolvedor, “pixel por pixel”. Um formulário em uma configuração é uma descrição lógica da composição do formulário. E o posicionamento específico dos elementos é realizado automaticamente pelo sistema quando o formulário é exibido.

A parte exibida do formulário (visível para o usuário) é descrita como uma árvore contendo elementos do formulário.

Os elementos podem ser campos de entrada, caixas de seleção, botões de opção, botões, etc. Além disso, um elemento pode ser um grupo que inclui outros elementos. Um grupo pode ser representado como um painel com moldura, um painel com páginas (marcadores), a própria página ou um painel de comando. Além disso, o elemento pode ser uma tabela, que também inclui elementos (colunas). A estrutura do elemento descreve a aparência do formulário.

Todas as funcionalidades do formulário são descritas na forma de detalhes e comandos. Detalhes são os dados com os quais o formulário trabalha e comandos são as ações a serem executadas. Assim, o desenvolvedor no editor de formulários deve incluir os detalhes e comandos necessários no formulário, criar elementos de formulário que os exibam e, se necessário, organizar os elementos em grupos.

Com base nesta descrição lógica, o sistema gera automaticamente a aparência do formulário para exibição ao usuário. Neste caso, o sistema leva em consideração diversas propriedades dos dados exibidos (por exemplo, tipo) para organizar os elementos do formulário da forma mais conveniente possível para o usuário.

O desenvolvedor pode influenciar a disposição dos elementos com várias configurações. Pode determinar a ordem dos elementos, especificar a largura e altura desejadas. No entanto, estas são apenas algumas informações adicionais para ajudar o sistema a exibir o formulário.

Nos formulários, o desenvolvedor pode utilizar não apenas os comandos do próprio formulário, mas também comandos globais utilizados na interface de comandos de toda a configuração. Além disso, é possível criar comandos parametrizáveis que abrirão outros formulários levando em consideração os dados específicos do formulário atual. Por exemplo, isso poderia ser a chamada de um relatório sobre saldos no armazém atualmente selecionado no formulário de fatura.

Todos nós sabemos que a empresa 1C tinha muitas versões diferentes da plataforma 1C, agora estaremos interessados em uma das versões mais recentes no momento em que escrevemos este artigo, são as versões 1C 8.2 e 1C 8.3. Se você teve que trabalhar em ambas as versões, provavelmente notei diferenças nas interfaces dessas versões, para os usuários eles diferem apenas na aparência. Essencialmente uma escolha aplicativo regular ou gerenciado informa ao sistema quais formulários exibir para execução, regular ou controlado, bem como qual aplicativo cliente será usado por padrão, grosso ou fino. Para informações mais detalhadas sobre os clientes, leia o artigo “O que são clientes grossos e finos em 1C, bem como suas diferenças”.

Aplicativo 1C regular (formulários regulares, interface regular, versão 1C 8.2)

Em 1C 8.2 só é possível trabalhar com formulários regulares, em modo de aplicação regular. A imagem abaixo mostra o banco de dados no modo de operação “aplicação 1C normal” (formulários regulares).

Aplicativo 1C gerenciado (formulários gerenciados, interface gerenciada, versão 1C 8.3)

Na plataforma 1C 8.3 podemos trabalhar tanto com formulários regulares (em modo de compatibilidade) quanto com formulários gerenciados. Além disso formulários gerenciados têm dois tipos de exibição: padrão e táxi. Um exemplo de configuração 1C 8.3 com formulários gerenciados padrão é mostrado abaixo e, em seguida, a interface “Táxi” é mostrada.

Qual é a diferença entre um aplicativo 1C regular e gerenciado?

Como já descobrimos um aplicativo regular e um aplicativo gerenciado são esses tipos de lançamento de um programa 1C. Além disso, dependendo do valor do tipo de lançamento 1C ( aplicativo regular ou gerenciado), uma interface específica será carregada por padrão ( formulários regulares ou gerenciados), portanto, existem tantos sinônimos para esse conceito. Gostaríamos de ressaltar que as diferenças nas interfaces são bastante significativas, a interface gerenciada foi totalmente redesenhada. Em princípio, essas são todas as diferenças que os usuários comuns do programa 1C veem. Quanto aos programadores, a interface gerenciada requer a escrita de código modificado, pois o desenvolvimento já é realizado em 1C 8.3, e não em 1C 8.2, daí todas as consequências decorrentes. O código também deve ser dividido em cliente e servidor; isso é indicado através das diretivas correspondentes no configurador.

Klyuev V.V.

http://prof1c.kklab.ru

TRABALHANDO COM INTERRUPTORES

Leve em consideração todos os usuários do serviço do site - posto materiais na seção Iniciantes!!!

8.2 Formulários gerenciados

Ao estudar o comportamento dos formulários gerenciados, os programadores ou desenvolvedores de interface se deparam com a questão de onde estão os switches nos formulários gerenciados e como adicioná-los ao formulário. É uma coisa pequena, mas é desagradável que muito tempo seja gasto nessas ninharias, embora esse tempo pudesse ser gasto no desenvolvimento e otimização do algoritmo, em vez de projetar o formulário.

Então, vamos criar uma configuração vazia para entender a questão, ou escolher qualquer uma típica.
Vá para o grupo que contém os diretórios e adicione um novo diretório para experimentar. Gostaria de ressaltar que a configuração deve ter o modo de inicialização principal - Aplicativo Gerenciado.

Então, vamos criar um novo diretório e adicionar o atributo “Propriedade1”, com o tipo “Boolean”

Agora vamos para a aba Formulários e adicionar um novo formulário.

Então, o formulário controlado foi criado, agora vamos trabalhar com o formulário e descobrir onde está localizado o switch.
Aqui está o nosso formulário, e nele vemos nossos adereços, mas em forma de bandeira

Então, o que fizemos de errado?
Vamos dar uma olhada nas propriedades dos adereços para ver se há uma mudança no tipo de controle.
E vemos que o campo Switch não está aqui!(Onde foi que erramos?

Aparentemente, o tipo de controle no formulário depende do tipo de dados, vamos voltar às propriedades do formulário, ou seja, a aba de detalhes, e alterar as propriedades do nosso atributo - ou seja, seu tipo “Booleano”, para o tipo “Número ”.

Agora vamos voltar às propriedades do controle e verificar se a View do controle foi adicionada às suas propriedades - - - E viva, vemos a view lá - Switch Field.

Agora olhe para o formulário, o que vemos:

Vemos - 3 valores padrão, 3 opções, mas precisamos de dois deles, vamos novamente para as propriedades do atributo e olhamos as propriedades “Número de colunas” lá

Para 2 - defina o Número de colunas - 2.

Isso pode impedir um pouco um programador cansado)), mas agora tanto ele quanto nós sabemos disso!

8.2 Formulários regulares.

Chato com interruptores em formas comuns.
Existem momentos assim, e eles acontecem) em que você precisa modificar algum formulário pronto, que já possui algumas opções, e você precisa adicionar outra opção a este formulário. É aí que surge uma espécie de tédio, que leva muito tempo, e não tempo para programar o código - mas uma perda de tempo para exibir essas opções para o usuário.

Então, vejamos um exemplo. Existe tal documento para ajuste de recebimentos em 1C UPP - ele definitivamente existe. Certa vez, precisávamos adicionar opções para que entradas contábeis ligeiramente diferentes fossem desenhadas. Qual é o problema, parece que devemos, devemos, faremos isso. Mas este formulário já possui 2 botões de opção.

Esta é a aparência do formulário em que precisamos adicionar mais opções

Na aba Avançado, gostaríamos de colocar mais dois botões de opção. Portanto, o primeiro passo é adicionar ousadamente um novo elemento de controle ao local que precisamos e inseri-lo.

Parece que tudo é simples. Criamos um novo atributo do tipo “Número” e inserimos 2 switches, um dos quais poderá gravar dados no atributo e o outro não.

Adicione um novo elemento de controle - Switch, adicione Switch2 na tabela com o número e descrição dos switches, defina Switch1 primeiro no grupo e pressione OK. Coloque os controles criados no formulário. Atualizamos a configuração do banco de dados (F7) e executamos para depuração.

Ao executar (ao criar um novo documento no modo 1C:Enterprise), vemos que por mais que tentemos clicar no Switch2, nada acontece. Os elementos não funcionam como deveriam. Há um truque aqui.
Retorne ao configurador. Selecione o item de menu Formulário -> Definir ordem de passagem... (é importante que o formulário esteja aberto na tela)

Para que nossos Switches funcionem, você deve quebrar a ordem automática e concordar com uma ordem manual. E coloque-o no formulário para que nossos interruptores fiquem um após o outro em ordem.