Guia Digitação

Esta seção descreve as principais causas de conflitos de digitação nas variáveis, bem como maneiras de evitá-los.

Conflitos de tipo de dados simples podem ser resumidas da seguinte forma:

• o conflito entre dois usos,
• os conflitos entre o uso e uma diretiva de compilação,
• os conflitos resultantes de redigitação,
• conflito implícito entre as duas diretivas do compilador.

Os conflito de tipo de dados mais simples é aquele que resulta de uma única variável que designa dois objetos diferentes. Suponha que, em um aplicativo, você escreva:

e que em outro lugar, na mesma aplicação, você escreva:

Isso gera um conflito de tipo de dados. O problema pode ser resolvido renomeando uma das variáveis.

Suponha que, em um aplicativo, você escreva:

e que em outro lugar, na mesma aplicação, você escreva:

Desde que o compilador verifique as primeiras diretrizes, a variável será do tipo booleano, mas quando encontrar a declaração:

detecta um conflito de tipo de dados. Você pode resolver o problema, renomeando a variável ou modificando a diretiva de compilador.

Usando variáveis de tipos diferentes de dados em uma expressão cria inconsistências. O compilador aponta incompatibilidades. Aqui está um exemplo simples:

Algumas funções retornam variáveis de um tipo de dado muito preciso. Atribuir o resultado de uma dessas variáveis para uma variável já digitada causará um conflito de tipo de dados se você não for cuidadoso.
Por exemplo, em um aplicativo interpretado, você pode escrever:

Neste exemplo, você cria um tipo de conflito na terceira linha. A solução consiste em controlar o comportamento da variável. Em alguns casos, você deve criar uma variável intermediária que usa um nome diferente. Em outros casos, como este, o método pode ser estruturado de forma diferente:

Declarando a mesma variável através de duas diretivas do compilador constitui uma redigitação. Se, no mesmo banco de dados, você escrever:

o compilador detecta o conflito e relata um erro no arquivo de erro. Normalmente, você pode resolver o problema renomeando uma das variáveis.

Tenha em mente que um conflito de tipo de dados podem surgir devido à utilização de C_STRING se você modificar o tamanho máximo da string. Assim, se você escrever:

o compilador identifica um conflito, porque ele deve fornecer uma localização adequada de tamanho quando declarar variáveis String.
A solução é usar uma diretiva de compilação que dá o comprimento máximo, uma vez que, por padrão, o compilador irá aceitar um tamanho menor. Você pode escrever:

Nota: Se tiver escrito C_STRING (7; String) duas vezes, ou seja:

o compilador, no entanto, aceita as diretivas, a segunda diretriz é simplesmente redundante.

Conflitos de tipo de dados envolvendo variáveis locais são idênticas às do inter ou variáveis do processo. A única diferença é que deve haver coerência somente dentro de um método especificado.
Para as variáveis de processo e entre processos, os conflitos ocorrem em geral no banco de dados. Para as variáveis locais, os conflitos ocorrem no nível do método. Por exemplo, você não pode escrever no mesmo método:

e, em seguida,

No entanto, você pode escrever:

no método M1, e:

no método M2, pois o escopo de variáveis locais é o método em si e não o banco de dados inteiro.

Conflitos sobre um array nunca estão relacionados ao tamanho. Tal como em bancos de dados não compilado, arrays são gerenciados dinamicamente. O tamanho de um aray pode variar ao longo de métodos, e você não precisa declarar o tamanho máximo para um array.
Portanto, você pode dimensionar um array como null, adicionar ou remover elementos, ou excluir o conteúdo.

Você deve seguir estas orientações, ao escrever uma base de dados destinada para a compilação:

• Não altere os tipos de dados de elementos de um array,
• Não mude o número de dimensões de um array,
• Para um array de String, não altere a seqüência de caracteres de comprimento.

Se você declarar um array como um array de inteiros, deve permanecer um array de inteiros em todo o banco de dados. Ela nunca pode conter, por exemplo, elementos do tipo Boolean.
Se você escreve:

o compilador não pode dar um tipo a MeuArray.
Basta mudar o nome de um dos arrays.

Em um banco de dados não compilado, você pode alterar o número de dimensões em um array. Quando o compilador cria a tabela de símbolos, arrays unidimensionais e arrays bidimensionais são geridos de forma diferente.
Conseqüentemente, você não pode redeclarar uma matriz unidimensional como bidimensional, ou vice-versa.
Portanto, no mesmo banco de dados, você não pode ter:

No entanto, você pode escrever as instruções a seguir na mesma aplicação:

O número de dimensões em um array não pode ser alterado em um banco de dados. No entanto, você pode alterar o tamanho de um array. Você pode redimensionar um array de um array bidimensional e escrever:

Nota: Um array bidimensional é, na verdade, um conjunto de vários arrays unidimensionais. Para mais informações, consulte a seção de Arrays de duas dimensões.

Arrays de string seguem as mesmas regras de string sfixas, pelas mesmas razões.
Se você escreve:

o compilador detecta um conflito de comprimento. A solução é simples: declarar o tamanho máximo da string. O compilador automaticamente manipula seqüências de comprimento mais curto.

Ao usar comandos como COPY ARRAY, LIST TO ARRAY, ARRAY TO LIST, SELECTION TO ARRAY, SELECTION RANGE TO ARRAY, ARRAY TO SELECTION, ou DISTINCT VALUES, você pode mudar, voluntariamente ou não, os tipos de dados de elementos, a número de dimensões, ou, em uma matriz de String, o comprimento da string. Você vai, assim, encontrar-se em uma das três situações mencionadas anteriormente.

O compilador gera uma mensagem de erro, a correção requerida é geralmente bastante óbvia. Exemplos de redigitação implícita de array são fornecidos na seção Detalhes de sintaxe.

Se você deseja compilar um banco de dados que utiliza arrays locais (arrays visíveis apenas pelos métodos que os criou), você deve declará-los explicitamente em 4D antes de usá-los.
Declarar explicitamente um array consiste em utilizar um comando do tipo ARRAY REAL, ARRAY INTEGER, etc:

Variáveis criadas em um formulário (por exemplo, botões, caixas de lista suspensa, e assim por diante) são sempre variáveis de processo ou interprocessos.
Em um banco de dados interpretado, o tipo de dados variáveis, não é importante. No entanto, em aplicações compiladas, ele poderá ter que ser levado em consideração. As regras são, no entanto, bem claras:
• Você pode digitar variáveis de formulário usando diretivas de compilador, ou
• o compilador atribui um tipo padrão que pode ser definido em Preferências de compilação (veja o Manual de Referência).

As seguintes variáveis de formulário são tipadas como Real por padrão:

Caixa de seleção
Caixa de seleção 3D
Botão
Botão invertido
Botão invisível
Botão 3D
Botão imagem
Grade de botões
Botão de opção
Botão de opção 3D
Botão imagem de opção
Menu imagem
Menu suspenso hierárquico
Lista hierárquica
Régua
Dial
Termômetro.

Nota: A Régua, Dial e variáveis de formulário Termômetro são sempre tipadas como reais, mesmo se você escolher inteiro longo como o botão padrão em Preferências.

Para uma dessas variáveis, o único conflito de tipo de dados que pode surgir seria se o nome de uma variável fosse idêntico aos de um outro localizado em outro lugar no banco de dados. Neste caso, renomeie a segunda variável.

A área do gráfico é automaticamente os dados do tipo de gráfico (Longint). Esta variável não cria um conflito de tipo de dados. Para uma variável do tipo de gráfico, o único conflito de tipo de dados que pode surgir seria se o nome de uma variável fosse idêntico aos de um outro localizado em outro lugar no banco de dados. Neste caso, renomeie a segunda variável.

Um plug-in é sempre uma área Longint. Nunca pode haver um conflito de tipo de dados.
Para um plug-in de área, o único conflito possível de tipo de dado seria se o nome de uma variável fosse idêntico ao de um outro localizado em outro lugar no banco de dados. Neste caso, renomeie a segunda variável.

Estas variáveis são dos seguintes tipos:
Variável não editável,
Variável editável,
Lista suspensa,
Menu/Lista suspensa,
Área de rolagem,
Combo box,
Menu Pop-up,
Guia.

Estas variáveis estão divididas em duas categorias:

• variáveis simples (variáveis editáveis e não editáveis),

• variáveis localizadas em arrays (listas suspensas, menus/listas suspensas, áreas de rolagem, menus pop-up, combo boxes e guias)

• variáveis simples
  O tipo de dados padrão é Texto. Quando usado em métodos ou métodos de objetos, eles são atribuídos ao tipo de dados selecionado por você. Não há perigo de um conflito que não seja resultante de atribuir o mesmo nome de outra variável.

• Variáveis Display
  Algumas variáveis são usadas para exibir os arrays em formulários. Se os valores padrão foram inseridos no editor de formulário, você deve explicitamente declarar as variáveis correspondentes usando os comandos Array Declaration (ARRAY STRING, ARRAY TEXT...).

Quando você usa ponteiros em seu banco de dados, você aproveitar uma ferramenta 4D poderosa e versátil. O compilador preserva todas as vantagens de ponteiros.
Um ponteiro pode apontar para variáveis de tipos diferentes de dados. Não crie um conflito através da atribuição de diferentes tipos de dados a uma variável. Tenha cuidado para não alterar o tipo de dados de uma variável a que um ponteiro se refere.
Aqui está um exemplo do problema:

Neste caso, o ponteiro dereferenced é uma variável real. Ao atribuir-lhe um valor booleano, você pode criar um conflito de tipo de dados.

Se você precisar usar ponteiros para fins diferentes no mesmo método, certifique-se que os ponteiros são definidos:

Um ponteiro é sempre definido em relação ao objeto a que se refere. É por isso que o compilador não pode detectar conflitos de tipo de dados criado por ponteiros. Em caso de conflito, você não receberá nenhuma mensagem de erro quando você estiver na fase de digitação ou em fase de compilação.
Isso não significa que o compilador não tenha como detectar conflitos envolvendo ponteiros. O compilador pode verificar o uso de ponteiros quando você marcar a opção Range Checking em Preferências de compilação (veja o Manual de Referência).

Durante a compilação, o compilador analisa as definições dos comandos de plug-in usados no banco de dados, ou seja, o número e tipo de parâmetros desses comandos. Não há perigo de confusão ao nível de digitação se as chamadas são consistentes com a declaração do método.

Verifique se o plug-ins estão instalados na pasta de plugins, em um dos locais autorizados pela 4D: ao lado da estrutura de arquivo de banco de dados ou ao lado do aplicativo executável (Windows) / no pacote de software (Mac OS). Por razões de compatibilidade, ainda é possível usar o Win4DX ou pasta Mac4DX ao lado do arquivo estrutura. Para obter mais informações, consulte o Guia de Instalação de 4D.

O compilador não duplica esses arquivos, mas analisa-os para determinar a declaração correta de suas rotinas.
Se o plug-ins estão localizados em outros lugares, o compilador irá pedir para localizá-los durante a digitação, através de uma caixa de diálogo Abrir arquivo.

Alguns plug-ins, por exemplo, 4D Write, executam comandos que implicitamente chamam comandos 4D.

Tomemos o exemplo de 4D Write. A sintaxe para do comando WR ON EVENT é:
WR ON EVENT(area;evento;eventoMetodo)

O último parâmetro é o nome do método que você criou em 4D. Este método é chamado pelo 4D Write cada vez que o evento é recebido. Ele automaticamente recebe os seguintes parâmetros:

Para o compilador levar em consideração esses parâmetros, você deve se certificar de que eles tenham sido digitados, ou por uma diretiva de compilador, ou por seu uso no método. Se eles têm sido utilizados para fins processuais, o uso tem de ser explícito o bastante para ser capaz de deduzir o tipo com clareza.

4D pode ser usado para criar e trabalhar com componentes. Um componente 4D é um conjunto de objetos 4D que representa uma ou mais funcionalidades e agrupados em um arquivo de estrutura (o chamado banco de dados do array), que pode ser instalado em bancos de dados diferentes (chamados de bases de dados do host).

Um banco de dados host executando no modo interpretado pode usar componentes interpretados ou compilados indiferentemente. É possível instalar os dois componentes interpretados e compilados no banco de dados de um mesmo host. Por outro lado, um banco de dados do host em execução no modo compilado não pode usar componentes interpretados. Neste caso, apenas componentes compilados podem ser usados.

Um banco de dados host interpretado contendo componentes interpretados podem ser compilados se não chamar quaisquer métodos do componente interpretado. Se este não for o caso, uma caixa de diálogo de aviso aparece quando você tenta compilar a aplicação e a compilação não é possível.

Um conflito de nomes pode ocorrer quando um método de projeto compartilhado do componente tem o mesmo nome que um método de projeto do banco de dados do host. Neste caso, quando o código é executado no contexto do banco de dados do host, o método do banco de dados do host é chamado. Isso significa que é possível "mascarar" o método do componente com um método personalizado (por exemplo, para obter uma funcionalidade diferente). Quando o código é executado no contexto do componente, o método do componente é chamado. Esta máscara será indicada por um aviso no caso da elaboração do banco de dados do host.

Se dois componentes compartilham métodos com o mesmo nome, um erro é gerado quando o banco de dados do host é compilado.

Para obter mais informações sobre componentes, consulte o manual de referência de desenho.

A manipulação de variáveis locais segue todas as regras que já foram indicadas. Tal como acontece com todas as outras variáveis, seus tipos de dados não pode ser alterado quando o método é executado. Nesta seção, vamos examinar dois casos que podem levar a conflitos de tipo de dados:

• Quando você realmente necessita uma redigitação. O uso de ponteiros ajuda a evitar conflitos de tipo de dados.
• Quando você precisa resolver parâmetros por indireção.

Uma variável não pode ser digitada novamente. No entanto, é possível usar um ponteiro para se referir a variáveis de diferentes tipos de dados.
Como exemplo, considere uma função que retorna o tamanho da memória de uma matriz unidimensional. Ao todo, mas dois casos, o resultado é um Real; para arrays de Texto e arrays de Imagem, o tamanho da memória depende dos valores que não podem ser expressos em termos numéricos (veja a seção Arrays e Memória).

Para Texto e array de Imagens, o resultado é retornado como uma seqüência de caracteres. Esta função requer um parâmetro: um ponteiro para o array cujo tamanho de memória que queremos saber.

Existem dois métodos para realizar esta operação:

• Trabalhar com variáveis locais sem se preocupar com seus tipos de dados, neste caso, o método é executado somente no modo interpretado.
• Use os ponteiros, e proceda no modo interpretado ou no modo compilado.

No método anterior, o tipo de dados $0 muda de acordo com o valor de $1 e, portanto, não é compatível com o compilador.

• MemSize funciona em modo interpretado e compilado (exemplo para Macintosh)
  Aqui, o método é escrito usando ponteiros:

Aqui estão as principais diferenças entre as duas funções:
• No primeiro caso, o resultado da função é a variável esperada,
• No segundo caso, o resultado da função é um ponteiro para essa variável. Você simplesmente volta a referenciar o resultado.

O compilador gera o poder ea versatilidade de indireção parâmetro. No modo interpretado, 4D oferece-lhe uma mão com os números e tipos de dados dos parâmetros. Você mantém essa liberdade no modo compilado, desde que você não introduza conflitos de tipo de dados e que você não use mais parâmetros que você passou no método de chamada.
Para evitar possíveis conflitos, os parâmetros abordados por engano devem ser todos do mesmo tipo de dados.
Este engano é melhor gerido, se você respeitar a seguinte convenção: se apenas alguns dos parâmetros são abordados por engano, eles devem ser passados após o outro.
Dentro do método, um endereço de indireção é formatado : ${$i}, onde $ i é uma variável numérica. ${$i} é chamado de parâmetro genérico.

Como exemplo, considere uma função que agrega valores e retorna a soma formatada de acordo com um formato que é passado como um parâmetro. Cada vez que este método é chamado, o número de valores a serem adicionados pode variar. Temos de passar os valores como parâmetros para o método e o formato em forma de uma cadeia de caracteres. O número de valores pode variar de chamada para chamada.
Essa função é chamada da seguinte forma:

Neste caso, o método de chamada receberá a string "182,70", que é a soma dos números, formatada como especificado. Os parâmetros da função devem ser passados na ordem correta: primeiro o formato e depois os valores.

Aqui está a função, chamada MySum:

Esta função pode agora ser chamada de várias maneiras:

Tal como acontece com outras variáveis locais, não é necessário declarar parâmetros genéricos por diretiva do compilador. Quando necessário (nos casos de ambiguidade ou de otimização), é feita usando a seguinte sintaxe:

Este comando significa que todos os parâmetros a partir do quarto (incluído) serão abordados com indireção e serão do tipo de dados Integer. $1, $2 e $3 podem ser de qualquer tipo de dados. No entanto, se você usar $2 por indireção, o tipo de dados utilizado será do tipo genérico. Assim, serão do tipo de dados Integer, mesmo que para você fosse, por exemplo, do tipo de dados real.

Nota: O compilador usa este comando na fase de digitação. O número da declaração deve ser uma constante e não uma variável.

Algumas variáveis 4D e constantes são atribuídas a um tipo de dados e a uma identidade com o compilador. Portanto, você não pode criar uma nova variável, método, função ou plug-in de comando usando qualquer uma dessas variáveis ou nomes de constantes. Você pode testar seus valores e utilizá-los como você faz em modo interpretado.

Aqui está uma lista completa de 4D com os seus tipos de dados.

Quando você cria uma coluna calculada em um relatório, 4D cria automaticamente uma variável C1 para a primeira, C2 primeiro para a segunda, C3 e assim por diante. Isso é feito de forma transparente.
Se você usar essas variáveis em métodos, tenha em mente que, assim como outras variáveis, C1, C2, ... Cn não pode ser digitada novamente.

Uma lista completa das constantes pré-definidas em 4D pode ser encontrada usando a Lista de temas constantes. Constantes 4D também são exibidas no Explorer em modo Desenho.