PC Toledo • Práticas que facilitam programar Clipper/Harbour - Página 2

Página 2 de 7

Práticas que facilitam programar Clipper/Harbour

Enviado: 23 Jun 2015 11:21

por JoséQuintas

Uma coisa que uso em alguns fontes.
Não é comum, mas se o compilador deixa, porque não.

Código: Selecionar todos

      DO CASE
      CASE nWsService == WSNFECANCELAMENTO ;           cUrlWs := "https://.../NfeCancelamento2.asmx"
      CASE nWsService == WSNFECONSULTA ;               cUrlWs := "https://.../NfeConsulta2.asmx"
      CASE nWsService == WSNFEINUTILIZACAO ;           cUrlWs := "https://.../NfeInutilizacao2.asmx"
      CASE nWsService == WSNFERECEPCAO ;               cUrlWs := "https://.../NfeRecepcao2.asmx"
      CASE nWsService == WSNFERETRECEPCAO ;            cUrlWs := "https://.../NfeRetRecepcao2.asmx"
      CASE nWsService == WSNFESTATUSSERVICO ;          cUrlWs := "https://.../NfeStatusServico2.asmx"
      ENDCASE

Nesse caso, são duas linhas em uma. Dá pra enxergar melhor o fonte.
E como sabem, a lista se multiplica, então melhor deixar fácil de enxergar.

E aproveitando...
Usei #define para essas opções WSNFE....
Imaginem usar números ao invés do #define....
Teria que mexer no fonte usando uma tabelinha pra ver do que se trata, ou encher de observações.
E observações, CASEs separados, ficaria um fonte muito poluído, complicando pra mexer numa alteração que se trata apenas de um simples texto com endereço.
Desse jeito tá fácil, economiza tempo pra alteração.

Ganhando tempo um pouquinho aqui, um pouquinho ali...
Muitos fontes, muitos aplicativos, muitos "pouquinhos tempos" que juntos são bastante tempo ganho.

Práticas que facilitam programar Clipper/Harbour

Enviado: 23 Jun 2015 20:12

por lugab

Bravo, Quintas, mostrando que tudo pode ser mais fácil...

Herdei fontes meio "marretas" e tive q aprender a cuidar deles sozinho e afirmo: Se o desaparecido autor tivesse adotado padrões similares a esses,
a minha vida de "programador forçado" teria sido muito menos crespa

Muito obrigado pelas aulas

Práticas que facilitam programar Clipper/Harbour

Enviado: 23 Jun 2015 22:06

por JoséQuintas

E pra ele próprio também seria melhor.

Práticas que facilitam programar Clipper/Harbour

Enviado: 26 Jun 2015 17:37

por JoséQuintas

Acabei de pegar um problema antigo aqui no meu aplicativo.

Código: Selecionar todos

      CASE Dow( Date() ) == 7 .OR. Dow( Date() ) == 6 .OR. Time() > "20:00" .OR. Time() < "05:00"

Coloquei pro servidor de NFE ir mais devagar de sábado/domingo.
O problema é que 7 é sábado, e 6 é sexta.

Está aí uma boa utilização do #define.

Agora acrescentei isto como define

Código: Selecionar todos

#define DOW_SABADO    7
#define DOW_DOMINGO   1

e essa linha ficou assim:

Código: Selecionar todos

      CASE Dow( Date() ) == DOW_SABADO .OR. Dow( Date() ) == DOW_DOMINGO .OR. Time() > "20:00" .OR. Time() < "05:00"

Desse jeito, não vai dar pra errar mais e fica bem visível.
É pra esse tipo de coisa que serve o #define.

E não precisa estar no fonte, pode ser num arquivo CH.
Como exemplo, eu uso pras minhas configurações um arquivo JPA.CH

O começo desse JPA.CH:

No tempo do Clipper, fui adotar a SIXCDX.
A primeira coisa era colocar os #include em cada fonte pra sixcdx.
Pra facilitar, criei o jpa.ch e coloquei tudo dentro dele, e nos fontes coloquei #include "jpa.ch"
Com isso, bastava alterar um único arquivo, pra já alterar todos os fontes de uma vez.
Sempre mantive o jpa.ch, mesmo quando ele ficou vazio
A partr de hoje, por exemplo, vou acrescentar isso de dia da semana.
E já dar uma geral nos fontes pra fazer uso disso.

Como eu vivo dizendo: sempre tem alguma coisa que dá pra melhorar nos fontes...

Nota:
Só descobri a falha porque a cliente ligou hoje, praticamente 2 minutos antes de completar essa 1 hora.
Vi na tela do servidor a indicação de 1 hora, e em seguida o servidor continuou o trabalho.
Se a ligação fosse 2 minutos depois, não sei quando eu iria perceber, porque ele estaria trabalhando normalmente.
Já com o #define, não vou errar nunca mais, vai estar conferido antes mesmo de entrar em uso.

Práticas que facilitam programar Clipper/Harbour

Enviado: 26 Jun 2015 18:26

por JoséQuintas

Esqueci de dizer antes:

No #define, pode usar maiúsculas, minúsculas ou misto.
Mas no fonte, tem que usar exatamente igual está no #define

O mais comum é usar maiúsculas no #define e no fonte, porque assim isso se destaca no fonte e já vai saber que se trata de um #define.

Está aí outra coisa que parece besteira:
Escrever o fonte em minúsculas, e só usar maiúsculas para determinadas coisas, como comandos e ítens do #define.

No começo é chato, depois a gente acostuma.
E com o tempo percebe a vantagem.

Práticas que facilitam programar Clipper/Harbour

Enviado: 27 Jun 2015 11:34

por fladimir

Legal...

Essa das minusculas comecei a adotar este ano e estou achando melhor de visualizar ai uso MAIUSCULAS pra COMANDOS, DEFINES, mas isso não tinha lido foi no dia a dia mesmo achei melhor assim.

Essa de centralizar algumas coisas em 1 CH e ter esse CH em cada PRG e depois se precisar alterar altera somente o CH eu comecei usar a uns 3 anos atrás qdo trocando ideia online com um colega percebi q ele fazia isso e perguntei pq... ai ele explicou e parei pra analisar e é isso mesmo, hj qdo preciso de um DEFINE genérico eu includo em 1 unico CH q já esta em todos e pronto todos estão alterados.

Uma coisa legal q aprendi aki no fórum é o #IFDEF TALCOISA etc... com isso tenho conseguido migrar pra Xailer (no meu caso) com mais facilidade pois uso os mesmos fontes tanto pra console qto pra Visual e qdo tem alguma questão q quero diferente coloco

Código: Selecionar todos

...
   codigo comum a ambos
...
...
   #IFDEF XAILER
       codigo diferenciado
  #else
       codigo console
  #endif
...
...
   continuacao do codigo comum a ambos.
...

[]´s

Práticas que facilitam programar Clipper/Harbour

Enviado: 14 Jul 2015 21:40

por JoséQuintas

Está aí uma coisa que eu tinha esquecido: Quando comecei a alterar os fontes de Clipper pra Harbour.
Eu usava

Código: Selecionar todos

#IFDEF HARBOUR
 ....
#ELSE
  ...
#ENDIF

A vantagem era usar os fontes normais de trabalho, sem atrapalhar.
E com o tempo, dependendo das diferenças, fui centralizando as diferenças num único fonte.

Tipo... ao invés de colocar #IFDEF em diversos fontes, com rotinas idênticas ou quase, transformava em uma rotina padrão e deixava em um arquivo separado.
Então ao invés de diversos fontes com #IFDEF, era apenas um.
E ao invés de diversas rotinas semelhantes, uma só mais flexível.

Bem lembrado. Fiz uso disso pra passar de Clipper pra Harbour.
Até abandonei a idéia do Harbour por um tempo, mas por causa dessa preparação, os fontes continuaram sempre compatíveis, e permitiam testes a qualquer momento.

Inclusive isso começou na época do xHarbour... e quando foi pra valer já era no Harbour.
Não fosse esse recurso, usado nos fontes de trabalho, seria sempre começar do zero pra fazer testes.

Clippeiros não se assustem.
Isso foi há muuuito tempo. Na época acho que era o Harbour 0.8.
Inclusive na época o recomendado era o ADS, porque o DBFCDX ainda não estava 100%.
Faz muuuito tempo mesmo.
Hoje em dia tá mais fácil, mas a técnica continua valendo, até pra testar bibliotecas gráficas diferentes isso pode ser interessante.

Práticas que facilitam programar Clipper/Harbour

Enviado: 31 Jul 2015 20:53

por JoséQuintas

Tem horas que até eu me espanto de como fica fácil.

Imaginem o seguinte:
Mostrar nomes, e os totais de cada mês, num tbrowse.

Primeira coisa provável que vém na cabeça:
Montar o arquivo temporário e fazer o tbrowse.

E que tal fazer durante o browse?
Difícil?

Uso uma rotina minha do tbrowse, mas isso é o de menos, não faz diferença.
O segredo são as colunas do tbrowse, como definir essas colunas.

Então vamos lá... um tbrowse que mostre os meses de 1 a 12, não é isso?

Código: Selecionar todos

   LOCAL oTBrowse := { ;
      { "NOME",    { || hldimcab->Nome } }, ;
      { "LOCADOR", { || hldimcab->Locador } }, ;
      { "MES1",    { || SomaMes(1) } }, ;
      { "MES2",    { || SomaMes(2) } }, ;
      { "MES3",    { || SomaMes(3) } }, ;
      { "MES4",    { || SomaMes(4) } }, ;
      { "MES5",    { || SomaMes(5) } }, ;
      { "MES6",    { || SomaMes(6) } }, ;
      { "MES7",    { || SomaMes(7) } }, ;
      { "MES8",    { || SomaMes(8) } }, ;
      { "MES9",    { || SomaMes(9) } }, ;
      { "MES10",   { || SomaMes(10) } }, ;
      { "MES11",   { || SomaMes(11) } }, ;
      { "MES12",   { || SomaMes(12) } } }

Pronto, meses de 1 a 12.

Agora as somas:
O Tbrowse navega pelas pessoas, então fica posicionado em alguém.
A coluna do tbrowse informa qual é o mês.
Então basta uma rotina que some um mês de uma pessoa.

Código: Selecionar todos

STATIC FUNCTION SomaMes( nNumMes )

   LOCAL mTotAluguel := 0, mTotComissao := 0

   SELECT informe
   SEEK Str( hldimcab->Locador, 4 )
   DO WHILE informe->LoCod == hldimcab->Locador .AND. .NOT. Eof()
      IF informe->Mes == nNumMes
         mTotAluguel  += informe->Valor
         mTotComissao += informe->ValorComis
      ENDIF
      SKIP
   ENDDO
   SELECT hldimcab
   RETURN Transform( mTotAluguel, "@E 999,999,999.99" ) + " " + Transform( mTotComissao, "@E 999,999,999.99" )

Tive que aproveitar um índice existente, senão poderia pegar em ordem de data e deixar mais rápido, processando só um intervalo de data.
Como ainda é fase de testes, pra ver as necessidades, não me preocupei com isso ainda.

Mas está aí.

Um detalhe curioso:
Durante a navegação com "setinhas", caso haja um pagamento lá no caixa, o tbrowse vai ser atualizado instantâneo, já que calcula na hora !!!!

A pessoa está acostumada a esperar o final do ano pra ver alguma soma, e está preocupada com isso.
Imaginem essa pessoa vendo os totais on-line, assim que o pagamento for efetuado no caixa....
Não vejo a hora de mostrar pra essa pessoa, pra ver a reação.

Lógico... já sei que uma coisa leva a outra....
Qualquer coisa a mais que seria no final do ano, vai ser antecipado pra agora.
Mas tudo bem, teremos mais tempo pra isso, ao invés de fazer correria no final do ano.
E até começar a acompanhar quais os problemas, e corrigir antes que os problemas se acumulem.
E puxar a orelha de quem estiver gerando problema.

Mas não parei por aí....
Depois tem a parte de rateio entre pessoas, e também vou colocar pra quando der ENTER numa coluna, mostrar todos os detalhes do que está sendo somado.
Mas uma coisa de cada vez.
O principal é ver se está caminhando para o resultado esperado, antes de complicar mais.

Práticas que facilitam programar Clipper/Harbour

Enviado: 02 Ago 2015 16:24

por JoséQuintas

E não é que já vi necessidades nisso, e por causa de valores estranhos.
Já tem valores em novembro e dezembro... mas estamos em julho....

Acrescentei uma coisa relativamente simples nesse tbrowse: mostrar os lançamentos responsáveis pela soma.
Relativamente simples: no tbrowse adicionar a função a ser acionada

E a função, parecida com a de soma, mas com outro tbrowse.

Código: Selecionar todos

FUNCTION HLDIMCABSIMULADIG( oBrowse )

   LOCAL nCol, oTBrowse, nSelect := Select()

   nCol := oBrowse:ColPos
   IF LastKey() != K_ENTER .OR. nCol < 3
      RETURN 0
   ENDIF
   SELECT informe
   oTBrowse := { ;
      { "Recibo",     { || informe->Recibo } }, ;
      { "Extrato",    { || informe->NExtra } }, ;
      { "Valor",      { || informe->Valor } }, ;
      { "ValorComis", { || informe->ValorComis } }, ;
      { "Mes",        { || informe->Mes } }, ;
      { "Data",       { || informe->Data } }, ;
      { "Nome",       { || informe->Nome } } }
   SET FILTER TO informe->Mes == nCol - 2
   SET SCOPE TO Str( hldimcab->Locador, 4 )
   GOTO TOP
   FazBrowse( oTBrowse )
   SET SCOPE TO
   SET FILTER TO
   SELECT ( nSelect )
   RETURN 0

Pelo objeto browse sei a coluna atual, sei que os meses começam na coluna 3. Então o mês da coluna equivale a coluna-2.
Pronto.

Resultado geral:
o primeiro tbrowse mostra as pessoas, e os totais somados de cada mês.
Ao teclar um ENTER em um mês, um novo tbrowse se abre com cada um dos lançamentos que foram somados.

Próxima etapa será junto com o cliente.
Quem fez o aplicativo esqueceu de uma informação simples nesse arquivo: qual a data de pagamento?
Esquisito mas tem lá:
- data de vencimento - exemplo 21/12/2014
- número do mês - exemplo 12
- nome do mês - exemplo DEZEMBRO
- DIA do pagamento - exemplo 21

Pois é... é um trabalho gerando outro.

A rotina do tbrowse, que de certa forma foi simples, permitiu descobrir essa falha.
E como a pessoa sempre fez tudo manualmente, não percebeu isso, ou não se incomodou com isso.

O interessante é um tbrowse relativamente simples, que resume tudo, já permitir a visualização de tudo, inclusive os problemas.

Práticas que facilitam programar Clipper/Harbour

Enviado: 02 Ago 2015 16:37

por JoséQuintas

Sobre o nome da função, que parece esquisito....

Os nomes de arquivo começam com HL
O arquivo em questão é para o DIMOB, mas serão necessários dois arquivos, considero um de cabeçalho e outro de detalhe.
Juntando isso, HLDIMCAB.DBF e HLDIMDET.DBF.
O nome do programa que mexe com HLDIMCAB é PHLDIMCAB, um P seguido do nome do arquivo.
A digitação do tbrowse é o nome do fonte, acrescido de DIG: PHLDIMCABDIG.
P-HLDIMCAB-DIG
Achei interessante assim por deixar visível o arquivo, o programa que mexe com ele, e as rotinas dentro dele.
Lógico... só uso isso pra rotinas que não podem ser STATIC.

Práticas que facilitam programar Clipper/Harbour

Enviado: 23 Ago 2015 19:48

por JoséQuintas

Me mandaram um fonte nestes dias, e usa muito o SET COLOR.
SET COLOR diferente pra SAY e pra GET.
Convém lembrar: isso é automático.

Código: Selecionar todos

SET COLOR W/N, N/W, , , W/B
@ 1, 0 SAY "código:" GET nCodigo
@ 2, 0 SAY "Nome:" GET cNome
IF field->Status == "I"
   @ 3, 0 SAY "IRREGULAR" COLOR "W/R"
ENDIF
READ

O código acima vai mostrar 4 conjuntos de cores diferentes.
SAY vai usar W/N
GET vai usar N/W para o get em foco, e W/B para os demais gets
E o alerta vai usar W/R
São 4 conjuntos de cores, sem encher de SET COLOR no fonte.

Outra dica também:
Deixar a tela toda colorida, parecendo carnaval, não é bom.
Desse jeito, se quiser chamar a atenção em alguma parte não vai conseguir, porque o usuário vai estar acostumado a ver cores em tudo que é lugar, e nada que faça vai chamar a atenção dele.
Basta usar cores nos lugares corretos, sem exagerar.
Até os sistemas operacionais vém reduzindo o uso de cores, justamente pra evitar poluição visual.

Práticas que facilitam programar Clipper/Harbour

Enviado: 23 Ago 2015 20:09

por JoséQuintas

Código: Selecionar todos

SET EPOCH TO Year( Date() ) - 90

Adotei isso há alguns anos.
Datas com ano 20 serão consideradas 2020, e com ano 30 serão consideradas 1930.
Isso dá uma margem de 10 anos para o futuro, e 90 anos para o passado.

No caso de ano com 4 dígitos (SET CENTURY ON), essa regra vai ser aplicada quando o usuário digitar apenas 2 dígitos no ano, o que acaba sendo uma ajuda extra ao usuário pra digitar menos números.

Práticas que facilitam programar Clipper/Harbour

Enviado: 23 Ago 2015 22:35

por JoséQuintas

Voltar um pouco naquele assunto de compilar usando -w3 -es2

Código: Selecionar todos

PROCEDURE Main
   LOCAL x := 0, z := 0
   @ 2, 0 GET x
   @ 3, 0 GET Y
   RETURN
   READ

Compilando normal, ok, gerado EXE.
Ao executar o EXE:

Error BASE/1003 Variable does not exist: Y
Called from (b)HB_MACROBLOCK(0)
Called from __GET(0)
Called from MAIN(4)
d:\temp>

Compilando com -w3 -es2

d:\temp>hbmk2 test -w3 -es2
Harbour 3.4.0dev (42ec833) (2015-08-14 15:54)
Copyright (c) 1999-2015, https://github.com/vszakats/harbour-core/
Compiling 'test.prg'...
test.prg(3) Warning W0001 Ambiguous reference 'GETLIST'
test.prg(3) Warning W0001 Ambiguous reference 'GETLIST'
test.prg(4) Warning W0001 Ambiguous reference 'Y'
test.prg(4) Warning W0001 Ambiguous reference 'GETLIST'
test.prg(4) Warning W0001 Ambiguous reference 'GETLIST'
test.prg(6) Warning W0028 Unreachable code
test.prg(6) Warning W0001 Ambiguous reference 'GETLIST'
test.prg(6) Warning W0001 Ambiguous reference 'GETLIST'
test.prg(6) Warning W0001 Ambiguous reference 'GETLIST'
test.prg(7) Warning W0032 Variable 'Z' is assigned but not used in function 'MAIN(2)'

Problemas do fonte:
- RETURN antes do READ. O READ nunca será executado (unreachable code)
- Variável Z criada e com valor atribuído, mas nunca foi usada
- Variável Y não foi declarada (tem apenas o GET, e nem valor foi atribuído)
- GetList não foi declarado.

Simplificando: alguns erros que poderiam acontecer no cliente, já foram identificados na compilação.

Práticas que facilitam programar Clipper/Harbour

Enviado: 24 Ago 2015 11:28

por janio

Qual a vantagem em usar um .ch e criar a variável no fonte?

Qndo eu preciso de um valor fixo para o programa inteiro, crio uma variavel public no meu prg principal e pronto: fica visivel em todo o sistema.

Código: Selecionar todos

Public cVariavel := valor

Práticas que facilitam programar Clipper/Harbour

Enviado: 24 Ago 2015 13:44

por JoséQuintas

O ch não cria variável.

Código: Selecionar todos

#include "inkey.ch"
IF LastKey() == K_ESC
...

Isso é pra ajudar ao programador.
Ao compilar, K_ESC vai ser substituído por 27 ANTES de compilar. (por isso chamado de pré-compilador).

Pra efeito de comparação:

Código: Selecionar todos

use clientes; goto top; do while .not. eof(); skip; enddo; use

Código: Selecionar todos

USE CLIENTES
GOTO TOP
DO WHILE .NOT. Eof()
   SKIP
ENDDO
USE

Qual dos dois fontes acima é melhor para o compilador?
Sinceramente.... deixaria do primeiro jeito se fizesse diferença?

O fonte é pra nós, tem coisas onde nem importa se faz diferença para o compilador.
E como o fonte é pessoal, cada um decide de que jeito acha melhor pra si.

Por falar em variável pública, todas as variáveis públicas poderiam ser um único array.
E pra facilitar:

Código: Selecionar todos

#define NOME_USUARIO 10

IF VarPublic[ NOME_USUARIO ]
...

Teria uma única variável, sem ter que decorar números de cada uma.