4D v14.3Detalhes de sintaxe |
||
|
4D v14.3
Detalhes de sintaxe
Detalhes de sintaxe
O compilador espera as regras de sintaxe habituais dos comandos 4D, não necessita modificações especiais para bancos que vão ser compilados. Entretanto esta seção oferece alguns lembretes e detalhes específicos:
Para os comandos que operam sobre strings, só a função Character code requer atenção especial. Em modo interpretado, pode passar indiferentemente uma string não vazia ou vazia a esta função. SEND VARIABLE(variable) O parâmetro que passa deve ser sempre do mesmo tipo. Suponha que deseja enviar uma lista de variáveis a um arquivo. Para eliminar o risco de mudar os tipos de dados involuntariamente, recomendamos especificar ao princípio da lista o tipo das variáveis enviadas. Desta forma, quando você recebe estas variáveis, sempre começará por obter um indicador. Depois, quando chama a RECEIVE VARIABLE, a transferência se maneja através de uma instrução Case of. Exemplo: SET CHANNEL(12;"Arquivo") Field (ponteiro campo) ou (tabela número;campo número) Lembre que as referências do documento retornado pelas funções Open document, Append document e Create document são de tipo Hora. Mod (valor;divisor) Variable:=Mod(25;3) ou Variable:=25%3 O compilador vê uma diferença entre as duas: Mod aplica a todos os tipos numéricos, enquanto o operador % aplica somente a Inteiros e Inteiros longos. Se o operando do operador % excede a faixa dos Inteiros longos, o resultado retornado provavelmente será errado. IDLE O comando IDLE foi adicionado à linguagem 4D para manejar exceções. Este comando deve ser utilizado quando utilize o comando ON EVENT CALL. Este comando pode ser definido como uma diretriz de gestão de eventos. Por outra parte, quando 4D está esperando tranquilamente por um evento, por exemplo em um loop de espera, é evidente que não haverá nenhuma chamada. `Método de projeto CliqueMouse Neste caso, se adiciona o comando IDLE da seguinte forma: `Método Espera Utilize este comando só em métodos de projeto de lidar com erros. Este comando funciona exatamente como em 4D, exceto em um método que tenha sido chamado por um dos seguintes comandos: EXECUTE FORMULA, APPLY TO SELECTION e APPLY TO SUBSELECTION. Trate de evitar esta situação. Sete comandos de 4D são utilizados pelo compilador para determinar o tipo de um array: COPY ARRAY(fuente;destino) O comando COPY ARRAY aceita dois parâmetros de tipo Array. Se um dos parâmetros de array não foi declarado, o compilador determina o tipo do array não declarado segundo o tipo do declarado.
Como o compilador é rigoroso com os tipos, COPY ARRAY só pode ser feito desde um array de um certo tipo a um array do mesmo tipo. $Tamanho:=Size of array(ArrInt)
Com 4D em modo interpretado, estes quatro comandos não necessitam a declaração de arrays. Os arrays não declarados recebem o mesmo tipo que o campo especificado no comando. SELECTION TO ARRAY([MinhaTabela]CampoInteiro;MeuArray) o tipo de dados de MeuArray seria Inteiro de uma dimensão. (assumindo que CampoInteiro seja um campo inteiro). Se o array foi declarado, tenha certeza de que o campo seja do mesmo tipo. Mesmo que Inteiro, Inteiro longo e Real são tipos similares, não são equivalentes. O mesmo acontece no caso dos campos de tipo Texto––suas diretrizes tem prioridade. O comando SELECTION TO ARRAY também tem uma segunda sintaxe: Os comandos LIST TO ARRAY e ARRAY TO LIST referem só a dois tipos de arrays:
O compilador não pode detectar um conflito de tipo se utilizar um ponteiro sem referência como parâmetro de um comando de declaração de um array. Se escreve: SELECTION TO ARRAY([Tabela]Campo;Ponteiro->) onde Ponteiro-> representa um array, o compilador não pode verificar que o tipo do campo e o do array são idênticos. Deve prevenir tais conflitos; deve declarar o array referenciado pelo ponteiro. O compilador emite uma advertência quando encontra uma rotina de declaração de array na qual um dos parâmetros é um ponteiro. Estas mensagens podem ser úteis na detecção de este tipo de conflito. Se seu banco utiliza arrays locais (arrays reconhecidos unicamente no método no qual foram criados), é necessário declará-los explicitamente em 4D antes de utilizá-los. Para declarar um array local, utilize um dos comandos de array tais como ARRAY REAL, ARRAY INTEGER, etc. Por exemplo, se um método cria um array local de inteiros que contém 10 elementos, deve declarar o array antes de utilizá-lo. Utilize o comando: ARRAY INTEGER($MeuArray;10) Get pointer(varName) Get pointer é uma função que devolve um ponteiro ao parâmetro que você lhe passou. Suponha que deseja inicializar um array de ponteiros. Cada elemento nesse array aponta a uma variável dada. Suponha que há doze variáveis chamadas V1, V2, …V12. Pode escrever: ARRAY POINTER(Arr;12) Também pode escrever: ARRAY POINTER(Arr;12) Ao final desta operação, pode obter um array de ponteiros onde cada elemento aponta a uma variável Vi. Estas duas sequências podem ser compiladas. Entretanto, se as variáveis V1 a V12 não são utilizadas explicitamente em outra parte do banco, o compilador não pode dar-lhes um tipo. Portanto, devem ser utilizadas ou declaradas explicitamente em outra parte.
C_LONGINT(V1;V2;V3;V4;V5;V6;V7;V8;V9;V10;V11;V12)
V1:=0 Como cada variável em um banco compilado tem um só tipo, esta função pode parecer não muito útil. Entretanto, pode ser útil quando trabalha com ponteiros. Por exemplo, pode ser necessário conhecer o tipo da variável a qual o ponteiro faz referencia; devido à flexibilidade dos ponteiros, nem sempre é possível saber a que objeto apontam. Este comando oferece janelas em modo interpretado que não oferece em modo compilado. Dada a seguinte sequência: i:=FormFunc Pode ser substituída por: i:=FormFunc Olhemos este outro exemplo: $Num:=SelPrinter Aqui, EXECUTE FORMULA pode ser substituída por Case of: Case of O comando EXECUTE FORMULA pode ser substituído sempre. Como o método a executar se escolhe da lista dos métodos de projeto do banco ou dos comandos de 4D, há um número finito de métodos. Portanto, sempre é possível substituir o comando EXECUTE FORMULA por Case of ou por outro comando. Além disso, seu código se executará mais rápido. Estes dois comandos são utilizados no processo de depuração. Não tem nenhum objetivo em um banco compilada. Entretanto, pode mantê-los em seus métodos, simplesmente serão ignorados pelo compilador. Undefined(variable) Considerando o processo de declaração efetuado pelo compilador, uma variável não pode em nenhum momento indefinida em modo compilado. Na verdade, todas as variáveis foram definidas no momento em que termina a compilação. A função Undefined portanto sempre retorna False, sem importar o parâmetro que seja passado. Nota: para saber se sua aplicação está correndo em modo compilado, chame o comando Compiled application. Em modo interpretado, pode verificar que o documento existe provando se uma das variáveis está indefinida depois da execução de LOAD VARIABLES. Isto não é possível em bancos compilados, já que a função Undefined sempre retorna False. Esta proba pode ser realizada em modo interpretado ou compilado: Var1:="xxxxxx" Esta rotina utiliza duas sintaxes diferentes em modo interpretado: Para um array MeuArray cujos elementos são de tipo Entero, CLEAR VARIABLE(MiArray) tem o mesmo efeito de uma das expressões seguintes: ARRAY INTEGER(MiArray;0) A segunda sintaxe, CLEAR VARIABLE("a"), não é compatível com o compilador, já que o compilador acessar as variáveis por direção, não por nome. Os seguintes comandos tem uma característica em comum: aceitam um primeiro parâmetro opcional [Tabela] e o segundo parâmetro pode ser um ponteiro. Em modo compilado, é fácil retornar o parâmetro opcional [Tabela]. Entretanto, quando o primeiro parâmetro passado a um desses comandos é um ponteiro, o compilador não sabe a que ponteiro está fazendo referência; o compilador o trata como um ponteiro de tabela. Tomemos o caso do comando QUERY cuja sintaxe é a seguinte: QUERY(PtrField->=True) o compilador buscará um símbolo que represente um campo no segundo elemento. Quando encontra o signo "=", emitirá uma mensagem de erro, ao não poder identificar o comando com uma expressão que saiba como processar. Por outro lado, se escrever: QUERY(PtrTabla->;PtrCampo->=True) ou QUERY([Tabla];PtrCampo->=True) evitará qualquer ambigüidade possível. When using pointers, there is a particularity concerning commands where the first parameter [aTable] and second parameter are both optional. In this context, for internal reasons, the compiler does not allow a command that returns a pointer (for example Current form table) to be passed directly as a parameter (an error is generated). This is the case, for example, of the FORM SCREENSHOT command. The following code works in interpreted mode but is rejected during compilation: //triggers a compilation error In this case, you can just use an intermediate variable in order for this code to be validated by the compiler: //equivalent compilable code Se criar seus próprios recursos 4DK# (constantes), tenha certeza de que os numéricos sejam declarados como de tipo Inteiro longo (L) ou Reais (R) e as cadeias de caracteres como Strings (S). Qualquer outro tipo gerará uma advertência. |
PROPRIEDADES
Produto: 4D VER TAMBÉM
Dicas de otimização ARTICLE USAGE
Manual de linguagem 4D ( 4D v12.4) Inherited from : Detalhes de sintaxe ( 4D v11 SQL Release 6) |