Softwhouse escreveu: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
- 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
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.