Compilar com -w3 -es2

[Softwhouse]

Como resolver o erro na compilação desses .prg compilando com -w3 -es2 ?

Código: Selecionar todos

Memvar cVar
Procedure Main()
Public cVar:= 'Hello World'
Teste()
Return

Teste.prg :

Código: Selecionar todos

Function Teste()
? cVar
Return(Nil)

Hbmk2 Demo.prg teste.prg -w3 -es2

[JoséQuintas]

alterei os nomes pra fazer o teste aqui.

test4.prg:2: warning W0001 Ambiguous reference 'CVAR'

No segundo fonte, falta declarar a variável.

Código: Selecionar todos

// fonte1.prg
Memvar cVar
Procedure Main()
Public cVar:= 'Hello World'
Teste()
Return

//fonte2.prg
MEMVAR cVar // <<<<====
Function Teste()
? cVar
Return Nil   // <=== Porque poluir fonte ? RETURN não é função

Isso resolve, ou MEMVAR dentro da rotina.
Mas pode pensar..... porque a variável pública ?
Será que seria melhor usar de outra forma ?

Código: Selecionar todos

// fonte1.prg
LOCAL cVar := "Hello World"

Teste( cVar )

RETURN

// fonte 2.prg
FUNCTION Test( cTexto )

   ? cTexto

   RETURN Nil

Cada caso é um caso diferente.
O alerta na compilação é um aviso.
Qual a melhor solução pra cada situação, aí cada um decide o que fazer.

[alxsts]

Olá!

Como resolver o erro...

Compile com -N, além dos demais parâmetros de compilação que já utiliza.

Editado:

Prefira a outra solução apresentada, usando variáveis LOCAL.

PUBLIC e PRIVATE são tipos de variáveis lentas, não recomendáveis. Se precisar de variáveis visíveis em todo o arquivo .PRG, use variáveis do tipo STATIC, declaradas antes da primeira PROCEDURE ou FUNCTION declarada no .PRG, assim como fez com MEMVAR no exemplo que apresentou.

[Softwhouse]

Valeu Quintas e Alexandre. O motivo das varáveis public é que são informadas no prg principal o Path dos arquivos, nome da empresa, arays... para serem utilizados nos outros prgs.

[alxsts]

Olá!

Funciona com -N?

[Softwhouse]

Olá, funciona sim.
Não sei se isso está correto, criei um arquivo .ch que contém todas as MemVar, então basta colocar #include 'variáveis.ch' em cada módulo e funciona corretamente, compilando com -w3 -es2 -n

[alxsts]

Olá!

Ok.

MEMVAR
Declare private and public variable names
------------------------------------------------------------------------------
Syntax

MEMVAR <idMemvar list>

Arguments

<idMemvar list> is a list of public and private variable names to declare to the compiler.

Description

MEMVAR is a declaration statement that causes the compiler to resolve references to variables specified without an explicit alias by implicitly assuming the memory variable alias (MEMVAR->). Only explicit, unaliased references to the specified variables are affected.
MEMVAR, like all declaration statements, has no effect on references made within macro expressions or variables.

The MEMVAR statement neither creates the variables nor verifies their existence. Its primary effect is to ensure correct references to variables whose existence is known to be guaranteed at runtime. At runtime, the specified variables must be created using the PRIVATE, PARAMETERS or PUBLIC statements. This can occur in the procedure containing the MEMVAR declaration or in a higher -level procedure.
Attempting to access the variables before they are created will cause an error.

The scope of the MEMVAR declaration is the procedure or function in which it occurs, or the entire source file if it precedes any PROCEDURE or FUNCTION statements and the /N compiler option is used. The /N option suppresses automatic definition of a procedure with the same name as the program (.prg) file.

Like other declaration statements, MEMVAR must precede any executable statements, including PARAMETERS, PUBLIC, and PRIVATE statements in a procedure or function definition, or the program (.prg) file if the declaration has filewide scope.

MEMVAR can be used in conjunction with the /W compiler option--which generates warning messages for ambiguous variable references--to perform compile--time checking for undeclared variables.

For more information on variable declarations and scoping, refer to the Variables section in the "Basic Concepts" chapter of the Programming and Utilities Guide.

Examples

. This example demonstrates the relationship between a private
and field variable with the same name. The private variable is
declared with the MEMVAR statement:

FUNCTION Example
MEMVAR amount, address
PRIVATE amount := 100
USE Customer NEW
//
? amount // Refers to amount private variable
? Customer->Amount // Refers to Amount field variable
//
RETURN NIL

Fonte: Norton Guides - Clipper 5.3

[JoséQuintas]

O motivo das varáveis public é que são informadas no prg principal o Path dos arquivos, nome da empresa, arays... para serem utilizados nos outros prgs.

Uso de outra forma, principalmente por causa de multithread, mas pra LIB GUI acaba sendo interessante.

Opções:

- Classe
Não vai ter checagem se colocar nome errado

- um único array ou hash
Não vai ter checagem,

- array + define
Passa a ter checagem

Código: Selecionar todos

#define VAR_IMPRESSORA 2
pub_var[ VAR_IMPRESSORA ]

- Função estática array
Cai no que já foi mencionado

Código: Selecionar todos

FUNCTION AppVar( x )
   STATIC aList[ 100 ]
  RETURN aList
...
AppVar()[ VAR_IMPRESSORA ]

- função estática pras variáveis públicas
Vai ter checagem se errar

Código: Selecionar todos

FUNCTION AppImpressora( xValue )
   STATIC AppImpressora := ""
   IF PCount()  != 0
      AppImpressora := xValue
   ENDIF
   RETURN xValue
...
AppImpressora( "EPSON" )
? AppImpressora()

- DBF ou equivalente
Pode usar um DBF ou uma tabela SQL pra determinadas configurações

Código: Selecionar todos

cImpressora := AllTrim( dbfsetup->Impressora )

Em GUI ou multithread pode ter necessidades diferentes.
DBF ou AppImpressora() ficaria visível em qualquer lugar.
Mas antes de mudar alguma coisa, pense no alcance da visibilidade, e/ou atualização.
Por exemplo: impressora parece algo comum, mas pode ter módulos usando impressoras diferentes.

Quais as vantagens/desvantagens entre todos:
O compilador consegue detectar se escrever AppImpressora() errado, porque vai chamar função que não existe.
O compilador usando -w3 -es2 consegue detectar se escrever esse nome errado ao usar #define APP_IMPRESSORA 4
O compilador não vai perceber erro se usar array e 1,2,3,4,5,6,7, ou hash "impressora", "impesora"
Por outro lado, nunca tivemos checagem em campo de arquivo e sobrevivemos a isso.

Nisso também, a gente pensa em quais variáveis são importantes manter na memória ou não. AppUsuario(), AppEmpresa()
Outras, deixar salvas em DBF mesmo, é o comum, até para o Windows, que usa o registro dele.
Pode encontrar variáveis públicas que deixa em memória pra usar só em situações isoladas, o que usar em DBF ou outro não seria problema.