Quais as vantagens de migrar p/ xHarbour ?

[SandroBelarmino]

Pessoal, compilei um programa para teste no xHarbour, com a gtwvw, a janela principal ficou legal em aparência Windows, com os menus, a barra de status, barra de ferramenta, etc.
Porém, para não ter que reescrever o sistema inteiro, as demais rotinas do programa eu deixei no modo console, então quando acesso um cadastro por exemplo, abre a tela dentro da janela igual a que abre no DOS.
Demonstrei pro cliente, e ele me questionou, mas se está igual no dos, qual a vantagem nisso?
Eu sei que a aplicação passa a ser uma aplicação 32 bits, mas em relação a acesso aos dados, em relação a desempenho, tráfego de informações na rede, muda muita coisa do programa em clipper para o programa compilado no xHarbour?
Sei que muitos já usam o xHarbour há algum tempo, por isso gostaria de esclarecer essa dúvida.

Obrigado a todos.

Forte abraço.

[Itamar M. Lins Jr.]

Todas as vantagens técnicas de um programa que é realmente for WINDOWS. Um sistema compilado com harbour em 32Bits no ambiente windows não roda mais no DOS.

Agora seu cliente tem razão mesmo. Para ele não mudou nada, mesmo ficando mais veloz. Se ele não possue impressoras USB, e outras tantas coisas que pode um sistema antigo em clipper não contemplar.
Aprenda a usar a HWGUI, redesenhe suas telas com o IDE da HWGUI, ai ele vai ver muita diferença.
O tempo que tu vais aprender usar gambiarras como WVW, é melhor logo mudar para HWGUI que é uma boa lib gráfica.

Alias até o clipper tambem tem a FiveWin que é melhor que a HWGUI. Não é comparando Clipper x Harbour que irá satisfazer seu cliente.


Saudações
Itamar M. Lins Jr.

[sygecom]

Olá Sandro,
O Simples fato de você não ter que trabalhar pensando em limitações já lhe tras uma paz de espirito muito grande, a facilidade de resolver problemas simples de impressão ou até mesmo aquela preocupação de ter que setar o FILES nas maquinas de clientes, e claro, que desempenho é bem melhor que do clipper. Em fim poderia lhe dar uma lista de enorme de coisas que o xharbour faz facialmente e o clipper somente faz usando aplicativos de terceiro, ou as vez nem assim mesmo faz.

[Maligno]

Sistemas de informação em modo console não atrai o cliente mesmo. Além da inferioridade estética, há também a limitação quanto a visualização de informações. Também por isso, na migração, GUI é unanimidade: precita ter. E além disso, nesse tipo de sistema, migrar para a arquitetura cliente/servidor é praticamente obrigatório. No final, o programa ficará bonito e muito mais rápido. Apesar da carga de trabalho aumentar, vale a pena.

[gvc]

Aqui no trabalho só foram migrados os sistemas para xHarbour para resolver limitações.
Inicialmente era um erro da MV. Um browse não abria em determinadas máquinas.
Após isso, foram as máquinas que dão erro de divisão por 0 (zero).
Depois foi o problema do X na janela DOS.
Agora estamos vendo a impressão de uma mascara e preencher com dados.

Foram mais de 5 anos bricando para trocar o Clipper por xH e só consegui pq não tiveram outra saida.
Só para constar o problema com o X é resolvido com um programa externo (do Mestre Maligno) mas são 6 linhas dentro do xH sem precisar chamar processador de comandos.

É como ter um carro pequeno, que dá conta do trabalho. Se vc trocar por um carro maior, vai continuar dado conta do recado. Vc só vai notar a diferença quando tiver que carregar algo grande realmente. Para o cliente, o que realmente vale é o produto entregue.
Eu comecei a testar o ADORDD aqui e o pessoal JAVA ficou maluco.
Eu diria que é sair do lago e entrar no oceano, para o desenvolvedor. Para o usuário, não haverá mudanças significativas.
Seu sistema pode fazer a confirmação de reserva de hotel e ele mesmo montar o eMail avisando o cliente. Dá para fazer isso com programa externo, mas dá para fazer dentro do xH. Vc tb pode fazer FTP de arquivo sem usar programa externo.

[Maligno]

Só um detalhe: o que se convencionou chamar de programa externo para Clipper, o XHarbour também tem: DLLs, que nada mais são que programas externos. A diferença maior é que as DLLs que o XHarbour usa são carregadas dinamicamente, de forma invisível para o programador (na maior parte das vezes). Ou seja, o XHarbour usa mais programas externos que o Clipper.

[alaminojunior]

Só um detalhe:
Dependendo do ramo de atividade do cliente, nada vai adiantar o sistema ter aparencia windows, bla bla bla, cheio de nós pelas costas, botôezinhos, ícones, enfim, aquela frescura toda.
Bota um sistema desses pra rodar numa loja com alto giro de clientes prá ver. O cliente do cliente vai chiar.
Resumindo....faça sim, o upgrade de seus sistemas para xharbour. E caso o seu cliente esteja enquadrado na questão acima, argumente com ele: vai ficar mais bonito sim, mas onde ele deseja chegar com essa lindeza toda ?
Agora, ....se não for o caso e vc tiver tempo e disposição para encher a telinha de figurinhas, melhor usar algo mais robusto e estável, como o Delphi.

[janio]

Não sei pq tanta gente dá valor a programas com janelas, botões e todas aquelas friscurinhas de programas "for windows"! Nunca gostei disso. Prefiro texto mesmo. É muito mais prático. Os bancos usam internamente texto. Conheço uma empresa do ramo de Avicultura que o programador deixou as duas versões do seu sistema (texto e janelado) para o usuário usar um ou outro. Sabe quantos usuários passaram a usar o janelado??? NENHUM.

A única "inveja" que tenho de programas "janelados" é com relação a se poder mostrar mais informações na tela devido ser possível usar vários tamanhos de fonte. A ÚNICA.

Janio

[Maligno]

Você pensa dessa forma porque nunca desenvolveu um ambiente GUI com recursos gráficos que são impossíveis em modo texto. Cito apenas um recurso que é emblemático: análise com gráficos estatísticos. Num sistema pobre, sem recursos desse tipo (e outros), o modo texto está bom demais. Agora, se o objetivo for alcançar um bom nível de qualidade, com riqueza de recursos, não há como escapar: é GUI. Se o usuário tem dois sistemas pobres (mal feitos), GUI e texto, é lógico que ele vai escolher o mais fácil de usar. Aí o texto pode ser o preferido, realmente.

[alaminojunior]

análise com gráficos estatísticos

Mais uma vez, foi exatamente o que eu disse. Se for o caso, use e abuse, porém se fosse eu, preferiria usar uma ferramenta mais adequada e sem enchertos como o Delphi.
Mas se o fluxo de utilização num balcão por exemplo for muito alto, repito por experiência própria, não funciona !
Agora o mais importante, é que o cliente nunca sabe ao certo o que quer. Cabe a nós profissionais, argumentar com ele. E também acredito que um sistema "pobre", é aquele que não faz o que se propõe a fazer, do contrário ....

[Maligno]

se fosse eu, preferiria usar uma ferramenta mais adequada e sem enchertos como o Delphi.

Com XHarbour é perfeitamente possível desenvolver software GUI de boa qualidade operacional. Diferenças óbvias à parte (incluindo a produtividade), nesse ponto XHarbour é igual ao Delphi.

Mas se o fluxo de utilização num balcão por exemplo for muito alto, repito por experiência própria, não funciona !

Discordo por dois motivos: primeiro que eu sei que é possível, embora ainda não tenha feito. No mês que vem vou fazer isso. Na prática é outra coisa, mas isso não me preocupa. Sei que precisa ficar e ficará prático e rápido.

Segundo que eu já vi um sistema de balcão, feito em Delphi, que tem um grande fluxo de movimento. Coisa bem feita com um sistema simples. Usa mouse se quiser. Tem atalhos fáceis. A tela é limpa. Você vê a coisa fluindo muito bem. É até bonito de ver.

Aliás, há bancos (vi no Itaú) em que os caixas usam sistemas GUI sem mouse. Mesma coisa: tela limpa, simples, atalhos práticos, rápido. Bem feito. Sobrou perícia.

E há outros bancos (vi no Sicred) em que tudo é texto, feito da forma mais porca possível. Tenha pena dos caixas desse banco. Faltou perícia.

Em suma: a qualidade final do produto e, principalmente, as facilidades inerentes ao software, para o bom atendimento às necessidades que ele deverá atender, dependem apenas da perícia do programador. Não há regra geral do tipo: para "data enter" o modo texto é rápido e GUI é lento. Me desculpe, mas pra mim isso não existe.

[janio]

Eu ainda estou pra ver um programa GUI prático.

Hoje, por exemplo, visitei um cliente que tem um programa (GUI) de um desses bancos que fazem empréstimos.

Fiquei observando a funcionária fazendo um cadastro de um cliente. Meu Deus do céu! Foi um Deus nos acuda. Clica aqui, clica ali, clica aqui, clica ali, clica aqui, clica ali ... quase meia hora pra fazer um cadastro...ufa... se eu fosse o cliente, tinha ido embora.

Jânio

[marcos.gurupi]

Embora poucos concordem com as opinioes do "Maligno" dessa vez vou concordar com ele. O sistema eh a conseguencia da pericia ou n do programador, isso feito em texto ou em GUI eu fiz o meu PDV em hwgui tive muita dificuldade pq queria fazer tudo no teclado (como meus clientes estavam acostumados a fazer) e a hwgui tinha e tem alguns problemas de focu, mas agora estah usual (ainda n ideal), ou seja, o usuario usar 90% o teclado.

Marcos Roberto

[Maligno]

Eu ainda estou pra ver um programa GUI prático.

Como eu disse, isso é relativo. Se o programador realmente se preocupar com a qualidade operacional do seu programa, pode ficar tão bom ou melhor do que qualquer programa orientado a texto. Recursos para isso ele tem, nos dois modos.

Eu mesmo estou desenvolvendo um grande sistema de planejamento e controle de produção. Meus forms para cadastros, citando apenas esse aspecto, são rápidos e práticos. A navegação entre campos é igual ao que se tem no Clipper. Na gravação pode-se usar um atalho ou clicar num botão. O usuário tem todo a opção e o conforto. Ainda não fiz aqueles cadastros de "hard data enter", mas só com o que já obtive, fico tranqüilo porque sei que não vou ter qualquer problema pra conseguir um resultado excelente. Eu tenho os recursos necessários. Só preciso querer fazer bem feito.

Ou seja, em texto ou GUI pode funcionar muito bem. Mas com uma boa vantagem para GUI, justamente porque a (boa) estética torna o trabalho do usuário mais agradável, além de permitir coisas que em Clipper é impossível.

Também como eu já disse: a qualidade operacional não depende tanto da interface, mas sim do programador. Se ele não tiver experiência e/ou sensibilidade ou mesmo se não quiser ter compromisso com a qualidade, aí não tem jeito, ficará ruim mesmo.

[SandroBelarmino]

Salve pessoal, desculpe a demora pra responder e agradecer a todos, é que fiquei um "tempinho" sem acesso à internet...

Muito obrigado a todos, todas as opiniões são muito importantes pra mim e minha equipe, pude observar que o assunto deu muito pano pra manga, ) ) e acho que a idéia do fórum é essa mesmo.

Eu quis saber da opinião de gente que já usa o xH há algum tempo pois eu ainda sou leigo nesse assunto, e o que estou pretendendo fazer é: mudar minhas aplicações de alguns clientes, digamos assim, "grandes" que são indústrias, onde temos sistemas rodando em clipper, porém já está gargalando algumas operações, sistemas de pedido e faturamento, contas a receber, financeiro e contas a pagar, controle de produção, controle de compras e estoque de materiais, enfim, praticamente um ERP, só que em vários módulos em clipper, porém todos ligados, todos pegando informações necessárias um do outro.

Como passamos a ter algumas limitações, como por exemplo impressão, com a chegada do XP no começo tivemos alguns problemas de queda e lentidão do sistema, agora com o Vista já está ficando complicado de novo, temos alguns problemas de gargalo de tráfego de informações na rede, mas isso eu sei que é por causa da estrutura xbase (dbf) o que pode ser resolvido com um banco de dados, enfim, estamos tentando de alguma forma com o xH resolver esses problemas de momento, enquanto desenvolvemos nosso novo sistema em outra plataforma (GUI), mas ainda estamos na dúvida de fazer isso em Delphi, linguagem que já temos alguma experiência e alguns programas rodando, e bem, ou se partimos para Visual C#, o que já estamos estudando e vendo a grande diferença no desenvolvimento.

Em relação à discussão quanto o programa ser em modo texto ou GUI, tenho plena convicção que a funcionalidade do programa, realmente depende unica e exclusivamente do programador, pois como disse, temos programas em Delphi rodando, e, de forma prática e funcional para o usuário, pois nos preocupamos com esse ponto, pois viemos do mundo clipper. Para se ter uma idéia temos programa de Frente de Caixa (PDV) em Delphi onde não se precisa usar mouse, temos todas as funcionalidades no teclado, mas a maneira de trabalhar com o programa fica a cargo do usuário, programas esses rodando em lojas de departamentos, material de contrução, etc. ou seja, onde tem alto giro de clientes e geralmente cliente com pressa, e que até agora em nossos clientes, não tivemos reclamação de gente ter que ficar na fila do caixa esperando.

Emfim, voltando ao assunto xHarbour, já deu uma boa clareada em minhas idéias, e acho que temos condição sim de fazer exatamente isso, migrar essas nossas aplicações para o xHarbour, mesmo que paliativamente, e funcionando parte em modo console mesmo, enquanto isso desenvolvemos nosso novo produto, esse sim totalmente no modo GUI.

Muito obrigado a todos, pois ajudou e muito nessa decisão.
Forte abraço e sucesso pra todos nós. :-Y :-Y