Mercado p/ Clipper

[Maligno]

Acho que você amigo Maligno devia ir frequentar forum de Delphi

Eu freqüento.

Apesar de ter 17 anos de clipper você ainda não conheceu ele a fundo

Baseado em quê você diz algo tão contundente sobre a vida de quem você não conhece?
Conheço Clipper. Mas não estou aqui para jogar confete em mim mesmo. ))))

Usei muito o DeDe e digo com toda certeza e sem medo de errar, Uma rotina simples de delphi sempre executa mais codigo ASM do que uma rotina do mesmo porte em xHarbour, o xHarbour não é mais rapido, mas o que faz com que ele rode em um 586 133 e o Delphi demore até 3 segundos simplesmente para abrir um relogio na tela, sem contar os problemas de consumo de memoria.

586? Quer o quê? Veja: cada ferramenta tem sua utilidade. Delphi não foi feito pra 586. XHarbour foi. Ou, pelo menos, serve pra máquinas antigas.

OOP não é tudo, tem suas limitações e no fundo no fundo, até o OOP é gerenciado por rotinas em C, se falar que mentira eu nem respondo

No fundo, no fundo... Isso é muito vago! O que você quer dizer com "no fundo"?
Não vou dizer que seja mentira. Mas verdade não é. Pelo menos até que você explique que "no fundo" é esse. Se expresse de maneira mais inteligível. Não se acanhe. Pode usar termos técnicos.

não achei meio de fazer com o Delphi, claro que existe, mas é meio obscuro ainda, sem contar os infinitos erros. o xHarbour eu conheço a fundo e conheço os processos que ele tem e dispara.

Inclusive a parte que é executada pelo SO? Menos, Wagner. Menos. ))
Obscuridade no uso de recursos é algo que existe para quem não tem conhecimento. Se você não foi atrás desse conhecimento, é claro que tudo fica obscuro.

Quanto ao Delphi e Processos, não tem como você controlar os processos, pois senao vc teria que fazer rotinas para criar forms, eventos, e controlar tudo mais

Poxa! Fazer forms com botões, edits, grids, etc na unha é coisa que dispenso totalmente. Se é isso que você chama de "controlar os processos", tô fora. Eu sei como criar e manter um form, processar mensagens, etc. Mas eu nunca vou querer fazer isso. Eu prefiro uma IDE que gerencie essa coisa chata. Tenho coisa melhor pra fazer.
Mas é um absurdo, ainda assim. Simplesmente porque NINGUÉM pode controlar tudo. Nem programando em Assembly em ring 0. Se fosse pra controlar tudo, você teria que se meter no SO, no banco de dados, etc. Em XHarbour você não faz isso.

o Delphi é muito extenso e é impossivel de você gerenciar todos os processos, por isso maior parte dos erros o proprio programador demora dias para descobrir de onde vem, quem nunca viu uma mensagem assim apenas "I/O Erro" e ai???

Eu nunca vi.
O programador que demora dias pra encontrar um erro é um programador inexperiente, sem dúvida alguma. Um programador experiente, seguindo a lógica do programa, consegue resolver os erros que aparecem. E ele nem precisa "controlar todos os processos" pra fazer isso. É só uma questão de competência.
Aquilo que fica fora do alcance do programador, ele não resolve. Troca de componente. Da mesma forma que você trocaria uma função defeituosa no Clipper por outra sem bug. Em qualquer linguagem é assim.

são processos que você tem que programar seu controle, quando vc abre um banco de dados mesmo usando o Datasource, quanto replace eu ja fiz errado por que tem processos que disponisicionavam o ponteiro do arquivo, mentira? nao, tenho certeza que nao.

Não digo que seja mentira, mas é, digamos, ilusão.
Datasource não abre banco de dados. Esse componente é só uma fonte de dados provenientes do provider e do connection. Apesar de pouca experiência, nunca vi um UPDATE fazer o cursor se perder. Se você se perdia desse jeito, é porque, como você mesmo disse, cometia erros. Teria sofrido menos se tivesse tido paciência e aprendido mais quanto ao uso desses componentes.

Quanto ao componente, veja no site do Mediator, alias, é até usando a RDD para xharbour que fizeram o tal componente.

De onde diabos você tirou a idéia de que esse componente foi escrito em Xharbour para ser usado no DELPHI???? Foi isso que você afirmou na sua mensagem mais antiga.

Lembre tambem que o xHarbour pode usar recursos do Delphi e até mesmo os componentes dele, acredite, eu fiz isto interagindo com Minigui e WVW

Não acredito. Para o XHarbour DE FATO usar os componentes do Delphi você teria que dispor da VCL dentro do XHarbour. A VCL, você deve saber, é uma estrutura complexa que envolve não só o componente em si, mas toda a estrutura hierárquica dos classes que ela contém. Já viu a planta da VCL? Eu já vi. É imensa. Se o XHarbour tivesse isso, seria ótimo. Mas não tem jeito nenhum disso acontecer.
Se você diz que isso é verdade, me diga como usar, por exemplo, o componente DevExpress Quantum Grid do Delphi no XHarbour.
Agora, não sei o que você fez com MiniGUI e WVW que te fez pensar que usou um componente Delphi. Não acho que você esteja mentindo. Acho que você apenas fez uma grande confusão com os termos e acredita que usou um componente Delphi. Se você se dispor a isso, pegue seu Delphi 5 e procure entender melhor a VCL. Vai acabar entendendo o que eu estou dizendo.
Observe: quando um novato lê você dizer "dá pra usar componente Delphi no XHarbour", o que ele vai pensar? Vai pensar que é mesmo possível. Vai se prender a uma informação errada. Me incomoda ver alguém passando uma informação errada, que eu sei que vai acabar iludindo alguém. Assim, se eu discordo, procuro, ao menos, levantar a polêmica, pra não deixar uma informação errada passar em branco. Agora, por favor, tenha mais responsabilidade nas suas afirmações.

agora não adianta, em Geral, o Delphi para aplicação comercial é mais lento e interagir ele direto com o C, não é tão fácil quanto ao xHarbour.

Interagir Delphi com C? Não programo em Delphi, mas duvido muito que exista isso. Até porque OPascal nem precisa de C/C++. Ela já é uma linguagem potente e o compilador produz código objeto muito bem otimizado.
Mas discordo que Delphi seja mais lento para aplicação comercial. Tenho amigos em Londrina que desenvolveram em Delphi excelentes aplicativos comerciais. Já vi funcionando e a velocidade (em máquinas decentes, que fique claro) é excelente. Agora, com relação ao XHarbour não digo nada. Não conheço em Londrina alguém que use XHarbour. Se tiver alguém, deve ser pouca gente.
Mas ao afirmar isso, você deveria levar em conta diversos fatores. Um exemplo: XHarbour é mais rápido que Assembly? Pode ser que sim. Pode ser que não. Depende do programador. Mas você generaliza. De forma errada. Não diga que é por sua experiência que você sabe o que diz. Só sua experiência não é suficiente pra confirmar isso.

Quantos menos OOP mais memoria disponivel e mais velocidade do código, porem com OOP a programação fica mais organizada.

Reveja seus conceitos sobre OOP. A finalidade dela não é tornar o código mais organizado. Se fosse, seria ridículo.
Usando OOP, é óbvio que mais código será gerado. Com qualquer linguagem é assim. O overhead extra é só uma conseqüência, em todas as linguagens.

Falamos entao de tranzição, ir do Clipper direto para outra linguagem e ainda relacionada a objeto, meu Deus, num brinca né...

Foi o que eu fiz há seis meses. Programo em C/C++ já há um bom tempo. Os maiores obstáculos foram outros que não a linguagem. Mas eu pude mudar dessa forma. Há quem não possa, por diversos motivos técnicos e não-técnicos.

O xHarbour está evoluindo, trabalha muito bem com OOP nos mesmo moldes do Delphi

Não conheço XHarbour a fundo, mas já conversei com alguém que conhece XHarbour e Delphi muito bem, que garante que a OOP no XHarbour é meia-boca, e está longe da OOP do Delphi. Claro que isso nem é tão importante. Primeiro que o XHarbour "ainda" está evoluindo. Segundo que quase ninguém usa OOP no XHarbour mesmo. ))

pois você esquece que OOP é gerenciado por rotinas simples escritas em C mesmo e ASM, ha, fala que é mentira?!?!?! nem respondo mais.

Não tem isso de ser gerenciado. Ainda mais por rotinas simples em C e ASM. OOP é simplesmente parte da linguagem e pronto. A relevância está em como o parser (o mecânismo interno ao compilador, que transforma código fonte em objeto) foi feito. Isso é o que conta. Não sei de onde você tirou essa idéia. Aliás, se fosse assim, você só poderia saber se alguém de dentro da Borland te dissesse como este parser foi feito. O que eu duvido. )

Logo, atras de um OOP sempre tem uma programação estruturada em não oop

Agora eu concordo. Apesar do paradigma OOP, os métodos são simples procedimentos estruturados.

o xHarbour tem suporte OOp e está sendo totalmente remodelado para isto, todas as rotinas e está ficando bom, vai ficar mais delphado, para quem quiser, para quem não quiser, será o mesmo velho e bom xharbour, preservando caracteristicas que o tornam transparentemente semelhante ao Clipper.

Concordo.

Agora falar que Delphi é melhor caminho para quem já tem um sistema rodando?!?!?!?!

Meu caso, mas com o Builder. Mas porque pude fazer isso. Quem tem código legado deve se preocupar com esse detalhe. Eu tenho código XBase legado. Mas não tenho compromisso de migrá-lo para XBase 32 bits.

Há, quanto a maquina virtual do xharbour, é mais rapida que qualquer outra existente, inclusive a .NET, java, etc

Voocê me obriga a fazer a mesma pergunta de antes: de onde você tirou isso? Alguma pesquisa séria, confiável, etc? Em que condições a medição foi feita?
Nem precisa responder. Eu sei que você está apenas "achando" isso, sem qualquer embasamento. Aliás, até parece que você vende XHarbour. Nem o Lombardo e o Culik apelavam tanto.

sem brigas e recentimento... melhor ir por onde eu conheço e sei que vou andar do que me prender nas mãos de quem controla o caminho.

Ressentimento nenhum. Mas é sempre bom colocar os pingos nos "is". E você está certo. Deve mesmo procurar seguir o caminho que lhe parece melhor, de acordo com as suas conveniências. Mas é sempre bom lembrar que nem todos tem os mesmos problemas, as mesmas conveniências.

Nao vamos discutir mais isto. Aqui se trata de clipper, e já fora definido a muitos e muitos anos atrás que o delphi não seria um bom caminho

Você tem o péssimo habito de "extrair do nada" coisas que não existem. Quem definiu isso??? Wagner, fale por você. Apenas por você. E diga que é a SUA opinião. Seja mais honesto com seus colegas. Senão, daqui a pouco você vai dizer: "Votem no FULANO!!! Já foi definido que ELE é o melhor candidato!" Seria ridículo, não?

devido a aprender toda uma nova estrutura e linguagem, para quem o fez parabens, eu programo em Delphi e gosto, porem para os amigos Clippeiros, como ainda sou tambem, xHarbour, sem discução.

Errado! Deve ser COM muita discussão. Senão você acaba chamando os colegas de "ROBÔS", que não devem ter opinião própria. Passe informações verdadeiras e deixe os colegas decidirem por si próprios.
As vidas das pessoas são diferentes. As necessidades que você tem podem não ser as mesmas que os demais colegas têm. Assim, é natural que alguns escolham um caminho diferente do seu.

Nesse ponto da conversa o Grings deve estar pulando da cadeira. Eu disse que não voltaria. Mas voltei. ))))))
Mas já que você respondeu (mais ou menos) as dúvidas que eu tinha levantado e depois de eu ter chegado a conclusão de que tudo era fantasia mesmo, acho que posso parar por aqui.

Espero que os colegas tenham aproveitado a conversa e, principalmente, tenham conseguido clarear melhor as idéias, os conceitos, etc.

[]'s
Maligno
http://www.buzinello.com/prg

[angeiras]

just my 2 cents...

Acompanhando essa discussão, que já caminha pra um lado mais pessoal, gostaria de observar o seguinte :

- Clipper é realmente uma linguagem pobre de recursos. Tudo o que a gente pode fazer a mais ( acessar RDBMS, imprimir USB, etc. ) são add-ons e não fazem parte do clipper. Por isso, geralmente, existem incompatibilidades entre libs que transformam a integração em um verdadeiro inferno. Se existe alguma vantagem em usar xbase é a sua simplicidade no acesso aos dados ( DBF principalmente ) e foi isso também um dos motivos que ajudou a torna-la popular.

- O Xharbour incorpora essas características que não tinhamos em Clipper como facilidade da própria linguagem. Mas não se enganem : se for apenas para traduzir o seu código de 16 para 32 bits é simples, mas se for usar um IDE como o Visual Xharbour ou o Xailer prepare-se para aprender quase uma nova linguagem, com um paradigma completamente diferente. A única coisa que sobra é a sintaxe xbase, e olhe lá. E aí, não é só o xharbour que oferece sintaxe xbase : temos o CULE.net ( sintaxe xbase para o framework .net ), Vulcan ( antigo VO ), o Visual FoxPro e até mesmo o Delphi, com um componente chamado Clipper Functions for Delphi.

Porque entao uso Xharbour ? comodidade, tenho tudo que preciso de uma linguagem a um preço acessível e ainda de quebra, ganho sintaxe xbase. Consigo desenvolver rápido aplicações comerciais com qualidade, mesmo em Windows, ate mesmo usando RDBMS.

Mas aqui gostaria de, se valer de alguma coisa, deixar uma sugestão para os novatos : não torne uma linguagem de programação ou SO em uma cruzada santa. Aprenda sempre mais, sempre coisas novas. Vale a pena. Programo em xbase desde antes mesmo do Clipper existir, mas não fecho meus horizontes para nada novo. Programo também em Delphi, faço manutenções em sistemas em VFP, VB e estou me preparando para certificação Java. Por causa do xharbour estou desenferrujando meus conhecimentos em C.

Ah, e é claro, aprenda Linux o mais rápido possível.

[]s
Manoel Angeiras

[rrfsistemas]

:)Pos Devo parabenizar mais uma vez : Maligno

e gostei muito da esplanação do Manoel.

A proposito alguém ja viu um anuncio de emprego solicitando programador xHarbour ? Sinceramente eu nunca vi !!

:xau

abraços a todos...

[Stanis Luksys]

Hehehe...

Eu nunca vi também... O Maligno mesmo disse isso em um outro tópico parecido com este, bem recente. Para quem está interessado no mercado de trabalho não é uma boa se aventurar com xHarbour, e muuuito menos com Clipper. Alias com nada que envolva xBase em geral. Para quem já tá nessa, até é uma boa conhecer todas essas ferramentas, basta notar que ainda existem programadores Cobol ganhando rios de dinheiro em Bancos e outros tipos de sistemas seguros. Ou seja, na parte de manutenção ainda existe algo... Quanto ao "emprego para xHarbour", se você o domina e vai atrás de um anúncio para Clipper, você pode inclusive surpreender seu entrevistador, oferecendo a ele a possibilidade de migrar seu aplicativo em horas... E ainda ganha um pontinho :=)

Quanto a toda esta polêmica, acho que é bobagem ficar discutindo, tudo isso não passa de preferências pessoais, pois como já foi dito, não há estudo sério que faça comparações a ponto de qualquer um aqui poder afirmar embasado em algo.

Eu, particularmente, indico o xHarbour para quem tem um programinha legal compilado com Clipper 5.2 e tal...

Para quem não tem nada, quer começar a programar agora, quer aprender, quer entrar nessa vida de louco, de programador, indico um Delphinho de boa (limitado em Windows) ou um Java, uma aplicaçãozinha em PHP plataforma WEB de repente... Vai da imaginação. Escreva "linguagem de programação" no Google e escolhe alguma entre as 10 primeiras... hehehe

Falou.

[rrfsistemas]

Olá a todos !

Para quem quer se manter informado sobre o que está em alta no mundo das linguagens de programação, no mundo inteiro, ai vai um link interessante, que mostra o ranking das LP's no quesíto mais usados...

http://www.tiobe.com/tpci.htm

Fiquem de olho... ´o)

[vagucs]

Fiote, quis te ofender não.

Mas vamos lá:


O OOP do Delphi tem sim que se tornar um código assembler simples e como se não usasse orientação a objeto, aprendemos e você sabe disto que, o que programamos em Delphi e maioria das linguagens é alto nível, depois vira baixo nível que em suma é tudo igual, porem OOP gera mais código, acredito que você não discordará disto. Quanto aos objetos Delphi, eu uso e muito e to montando uma lib que facilita no uso dos mesmos, eu já tinha feito testes básicos e conversando com o Vailton Renato que tinha feito os mesmo testes eu levei a idéia adiante, tanto que o PRWIN a partir da versão 3 foi escrito em xHarbour+Minigui+C+Delphi, acredite, os códigos de barras gerados por ele eu usei um componente muito bom do delphi, e fiz a importação do mesmo para dentro do sistema em xHarbour, a os boletos bancarios também, são do antigo projeto Delphi-boleto, mudei muita coisa e atualizei os arquivos e fiz uma interface com o componente e o xHarbour, tem uma rotina que montei que torna possível captar o Handle do componente do delphi e usar ele sem delongas no xHarbour, como se fizesse parte pura do seu sistema. Agora você como é um programador experiente em C, Delphi e Clipper, acho que já deve ter entendido que quando qualquer linguagem gera um código de máquina, por mais que a linguagem seja diferente, o código de maquina é o mesmo, tanto que uso objetos de C++ dentro do C, mentira??? não, é que os objetos gerados com uso de C++ so tem os nomes de funções modificados de forma que o código C não entenda os objetos e rotinas, agora se você pega o OBJ gerado e fazer a mudança nos nomes das rotinas para que se compatibilize C++ com C, vc poderá usar recursos existente somente no C++ para fazer rotinas para C, e conseqüentemente em xHarbour, mas não é nada que nem a borland ou qualquer programador saiba ou se preocupe em ensinar, alias, não vai fazer diferença na vida de ninguém, apenas digo que é possível, tanto que o FOXTOOLKIT, que é C++ puro e multiplataforma, eu compilei, compatibilizei e usei todos os objetos com C interfaceando para xHarbour. Quanto ao OOP do xHarbour, ele está meia boca porque maior parte dos componentes comuns estão sendo migrados (O que no final vai reduzir ainda mais a velocidade do mesmo, porque orientação a objeto é mais código sendo executado), quando ao código gerado, ele conseqüentemente tem que ser mais lento por se tratar de uma OOP, porem comparado com o Delphi em diversas situações se comporta melhor, pois maior parte deste código é C puro é totalmente otimizado, alocações, handle, etc... e por ser C, permite que se interaja com qualquer linguagem e se use qualquer recurso disponível. Interface C com Delphi somente via DLL, interface xHarbour com Delphi é só colocar os recursos que deseja usar do Delphi em DLL previamente criada para isto e depois declarar a variável em xHARBOUR com o handle do recurso e use a vontade, qualquer componente, relembrando, o Delphi boleto usa também o QuickReport, e incrível, tudo ta dentro do PRWIN, parece mentira não é, mas não é, com o xHarbour você pode usar os melhores recursos que cada linguagem oferece, e isso é ótimo. Você pode criar todos os formulários do seu sistema em Delphi, apesar de que não vejo grande vantagem nisto, mas pode.

Outra particularidade interessante do xHarbour, se você quiser gerar um código C puro sem passar diretamente pela VM, você pode, tem um parâmetro do xHarbour que não me lembro bem agora, que no lugar de gerar o PCODE gera as chamadas diretas as rotinas, então, ai se tem um ganho de velocidade exorbitante, porque não é mais maquina virtual executa mais o código, mas é tudo C puro e super rápido.

E também acho uma loucura de sua parte dizer que pelo xHarbour você não pode controlar os processos, nunca esqueça que Harbour é C e parte do código que o Delphi executa, internamente foi feito em C, não há como negar. Mas delpheros estarão dentro de pouco tempo, presos também a plataforma .NET o que anexa custos a qualquer projeto.

E quando disse que o programador demora dias, o fórum não existiria, se todos os programadores fossem suficientemente experientes a ponto que achar os erros na velocidade que o amigo encontra.

Amigos programadores, se os objetos do Delphi OOp compilados não viram assembler "EU MUDO MEU NOME PARA VIRGINIA".

Não se deixem serem enrolados, o melhor caminho para o Clipper se chama.


XHARBOUR X H A R B O U R

Quanto a procura de emprego, não é tanta quanto em outras linguagens, o problema é que pelos programadores em xHarbour virem de uma arquitetura limitada, maior parte continua preso no mesmo pensamento, eu mesmo não me faltaram nunca ofertas de empregos e trabalho.

No momento fui contrato pelo governo, pela CONAB (Companhia Nacional de Abastecimento, aquele orgão que controla armazéns do governo, fome zero, distribuição de recursos agrários), pois é... sabe qual foi o quesito:

Queriam um programador Clipper experiente com as evoluções do mesmo (xHarbour) para atualizar o sistema antigo deles para Linux e interligar todos os estados na central de Brasília, mas o sistema como não tinha estrutura lógica está sendo reescrito do ZERO, até o governo agora vai por xHarbour hein, que legal não, um dos setores aqui usa um sistema de Delphi, legal né, pois é, já estão se preparando para dar tchau para ele também, tem muita gente usando, é só pesquisar, mas não é como as linguagens mais populares, mas tem recursos extraordinários...

Detalhes, a CONAB tem no momento, uns 45 programadores, 5 programadores Clipper que davam assistência no sistema antigo, agora todo mundo tá abismado com as possibilidades que apresentei com o xHarbour, legal né... até o governo.


Fui..............

[vagucs]

Quanto ao componente de Delphi feito em xHarbour, resolvi postar o texto todo aqui separado.

Leiam com atenção ou acessem www.otc.pl e visualizem o menu "Products" e cliquem em "DBF/xHarbour component for Delphi".

Para quem fala que é impossível...

Código: Selecionar todos

DBF/xHarbour components for Delphi 
This is basically the same as Mediator Delphi client but from another perspective.

For those who are not interested in Mediator server SQL capabilities right now, we provide this xHarbour components for Delphi as a mean to easily access xHarbour's data and functions from Delphi applications.

While Mediator Delphi client is available only as a part of Mediator client in common installer, xHarbour components for Delphi have been put into separate installer file for easy download and deployment. 

This solution is absolutely free and can be used by anybody interested in any kind of applications including commercial.

For detailed info about xHarbour components for Delphi see documentation.

xHarbour components for Delphi are based on the state of the art xHarbour kernel (Harbour.dll). The appropriate version of Harbour.dll file is attached to the components installer, so you don't need to worry about it. More information about the xHarbour project is available at www.xharbour.org. 

xHarbour components for Delphi include two sets of Delphi objects which correspond to two different data access interfaces. To access DBF (and Mediator) tables you can use either low-level objects or VCL (Visual Class Library) Delphi components.

Low level objects

THbConnection and THbTable are low-level objects which allow the programmatical access to xHarbour tables/workareas and kernel from Delphi. These objects contain easy to use wrappers for about 150 xHarbour and 120 Mediator functions.

VCL components

There are two visual-level components which can be usefull for accessing DBF files:

TMedConnection is similar to BDE's TDatabase component. It is used for setting environmental parameters and interacting with xHarbour kernel (Harbour.dll) functions. Some functions are implemented as TMedConnection methods, others are accessible through the ancapsulated THbConnection object.

TMedTable component is a TDataSet descendant which ensures the easy, BDE-like access to DBF files. It is very similar to BDE's TTable component and easily integrates with existing Delphi data-aware components such as DataSource, DBGrid or DBNavigator. Built around the encapsulated THbTable object, it also provides the access to the low-level xHarbour functionality.

RDD drivers

Replaceable Data Driver is an xHarbour's interface used to access data.
Our components give you access to the following RDD drivers:

DBFNTX - DBF files with NTX indexes

DBFCDX - DBF file with CDX indexes

MEDNTX, MEDCDX - Mediator SQL drivers compatible with DBFNTX and DBFCDX respectively


Every DBF-based application built around TMedConnection and TMedTable components can be easily switched to use SQL database by simply modifying a few properties in TMedConnection and TMedTable components.

What can I use it for?

a) Use xHarbour Delphi components as migration path for your xBase applications. You can gradually migrate your applications writing new modules in Delphi. Thanks to xHarbour kernel underlying Mediator components, your DBF and Mediator data is accessed in 100%-compatible way from both xHarbour and Delphi applications. 

It is hard to belive but now you can even integrate your xHarbour code with Delphi application! All you need to do is to put your xHarbour code into DLL file and then run it from Delphi application passing required parameters!

b) Use xHarbour Delphi components as high-grade RAD environment for developping new GUI modules extending your existing xHarbour/Clipper applications.

c) Use xHarbour Delphi components as GUI for your xHarbour code kept in DLL files.


Advantages of xHarbour/DBF components for Delphi
easy access to DBF files from Delphi applications

BDE-compatible, TDataset descendant data access interface

low-level and VCL-level interfaces to best suit your application

100% xHarbour files compatibility thanks to underlaying xHarbour kernel

ability to integrate and execute existing xHarbour/Clipper code

no need for BDE files on user workstation

instant migration to SQL database without writing a single SQL statement


System requirements
 

Acho que esta parte da discursão acaba aqui.


VIVA XHARBOUR QUE USA O RECURSO DE QUALQUER LINGUAGEM.

Hehehehehehehe

:|< :|< :|< :|< :* -:] -:] -:] -:] -:]

[marcos.gurupi]

Primeiro gostaria de parabenizar ao Dudu_xbase e ao Wagner Nunes pelo post objetivo e esclarecedor, n fico magoado quando dizem q o clipper eh uma linguagem pobre ou mesmo q jah eh ultrapassada, pelo menos nisso o Maligno tem razao eh passado foi bom enquanto durou c n vamos ficar como nossos avos apegados por exemplo em um carro velho q me carregou muitos anos mas q agora estah caindo aos pedacos, nos como programadores temos q procurar solucoes eficazes para os clientes. Quando resolvi q iria mudar/evoluir, foi pq eu alugava cada vez mais meu software e cada vez mais o meu celular tocava, bom comecei a ficar preocupado pq assim eu teria vida curta ou morreria de stress e sempre eram problema relacionados as limitacoes q o DOS tinha, procurei entaum saber sobre as vantagens e desvatagens d outras linguagens usadas no mercado, esperimentei a VFP, Delphi e VB.

VFP: Ultra Pesada!

Deplhi: Eh pessada como um elefante! E principalmente ficaria dependendo de componentes na maioria d terceiros para trabalhar.

VB: Alem d ser sulreal acontece erros q nem programadores mais experientes n sabem d onde vem, ai dizem ao cliente formata a maquina e eu instalo o sistema novamente.

Ah muito tempo eu lia o Wagner orientando a todos para experimentarem o harbour e posteriormente o xharbour, entaum resolvi. Peguei um sistema meu e passei para xharbour, resumindo a historia hoje meu celular n toca mais, meus clientes estaum super contentes e alugo sistema com a mesma frequencia :)Pos .

Maligno fica parecendo q vc quer provar pra todos q vc eh o certo e todos aqui entaum errados, meu pai jah dizia "desconfie daquele q quer c dono da verdade" e eh o q vc parece estah fazendo, eu mesmo jah mudei varios mas varios sistemas em delphi para o velho clipper e posteriormente para xharbour. Entaum meu colega ex-clipeiro encerra esse papo pq na verdade jah estah ficando cansativo ler suas msg, ateh pq vc n acresenta nada d novo e apenas ataca quem estah ensinando e aprendendo, pq a finalidade desde forum eh esse e n c o "DONO DA VERDADE".

Marcos Roberto.

[Pablo César]

É triste ver que ficam se jogando pedras para se sobre-sair dos demais. Acusar ao colega e dar a entender dizendo que não é para confiar da sua palavra, mais feio ainda.

Diferenças, TODOS nós vamos encontrar, graças a DEUS !.

Mas ninguém é dono da verdade, nem mesmo aqueles qua acusam os outros serem donos da verdade. O colega, MALIGNO, como muito aqui, simplesmente, compartem idéias, comentários é pra isso que o FORUM serve. Não para fazer propagandas.

Devemos agradecer a todos que de alguma forma contribuem na sua opinão sobre este tema, não simplesmente intentar silenciá-los. Não foram somente os colegas DUDU_XBASE e WAGNER NUNES que deram boas opinões. Acho que devemos recapacitar e sem agressão.

Bonito é ver gente que constroi, não que destroi. Devemos nos orgulhar de termos este FORUM para debate, imparcialidades haverá sempre. Mas lembrem TODOS este é um FORUM sobre o CLIPPER, não de xHarbour, FIVEWIN, DELPHI... Não se trata de promocionar alguma liguagem nas custas do nosso querido CLIPPER. Viver nas sombras dele sem ter seus proprios méritos, não é legal.

Eu pergunto, colegas: Qual é a contribuição que deixam para os que estão trabalhando arduamente no CLIPPER ?. Nenhuma, simplesmente, vocês desejam que ele acabe. Sei que temos muitas razões, mas quem trabalha para melhorar isso ?. Bem, dirão que o CLIPPER não tem jeito e caramba quatro. Mas não sejamos ingratos com ele, nem com nenhum colega aqui. O CLIPPER ja ajudou a muitos conquistar muitas coisas e ele tem a sua fatia no mercado. Claro outras linguagens irão surgir e não precisamos ficar no tempo. Eu gostaria de propor a TODOS nós que este assunto ja foi tratado ao extremo. E que todos nós, colocassemos mais atenção aos colegas que precisam ajuda técnica. Muitos deles, as vezes, é um começo de um aprendizado que chama-se PROGRAMAR. Estamos gastando muita energia nisto e até agora só poucos colegas fazerem contribuições ao CLIPPER.

Eu não fico com invea do colega, porque ao recompilar/transformar seu código em xHarbour, resolveu todos os seu problemas (ja que ninguem mais liga pra ele reclamando), que BOM !. Mas eu ainda com o meu CLIPPERZINHO, não tenho reclamações (sugestões, melhoras), bem isso sempre teremos em TODAS as liguagens de programação.

Eu farei como alguns colegas que ja praticam isto. Deixarei de clicar neste tópico. Pois ele ja me cansou pelas agressões. Se falessem de forma que não identifique a ninguém, talvez poderia pensar que a informação dada é méritamente TÉCNICA.

Vamos trabalhar, gente. Não digo para não debater, isso é sadio, mas por favor sem ofensas.

Fique com DEUS, e ajudem aos colegas que estao precisando, por favor

Um clip-abraço

[vagucs]

So para relembrar:

Começamos com o clipper, e ele é apenas um compilador xBase, logo sabemos programar em xBase e existem diversas opções.


O Clipper é ótimo, ainda tenho muitos sistemas com ele, apesar de nao dar mais suporte aos usuarios, mas o programa nao dá pau e ninguem para de usar, apesar de até já ter recomendado, o povo continua usando e toda vez que passo em minha cidade tem um monte de gente querendo mudanças e melhorias que na medida do possível sempre tento atender.

Agora para modernizar, não acho viável um programador abrir mão de um grande sistema e de todo o seu conhecimento para "EVOLUIR", logo, se você sabe xBase e não Clipper, temos todo um potencial que infelizmente as limitações do clipper não nos deixa explorar.

Uma historia muito interessante é a do elefante que foi criado a vida inteira amarrado a um tronco muito forte, certo dia colocaram ele amarrado é um graveto e ele não fez força para se soltar, pois psicologicamente já estava enfadado aquela situação e não percebeu que o tronco que o prendia tinha sido trocado pelo graveto.

Quando você se intitula "PROGRAMADOR CLIPPER" está preso ao tronco.

Quando você se intitula "PROGRAMADOR xBase" está preso ao graveto.

Se você está preso ao graveto, tenta dar um passo adiante e nada mais será limitado a você.

O xHarbour torna atualizado todo o conhecimento xBase e ainda torna nossa visão muito mais ampla. É só caminhar...

Introduza o xHarbour com calma, sem correria, alias como disse e reafirmo, as grandes corporação não estão nem ai por um visual bonito de programa, querem apenas resultado, isto é o que todos nos queremos, do Governo ao Manoel dono da padaria da esquina.

Só isto apenas...

Abraços.

[rrfsistemas]

Gostaria de fazer uma pergunta ao Vagner :

A titulo de informação qto vai custar aos cofres da CONAB essa mudança dos sistemas ?

Temos que ter base pra mudar o que ja esta pronto !!

100+ agradeço

[vagucs]

acho que seria imprudente disponibilizar esta informação.

Para para titulo de informação para quem quer mudar, geralmente o custo é 0 (zero), depende muito do objetivo a ser alcançado.

Ai já começamos a averiguar ferramentas e infitas possibilidades.

Tudo depende do que deseja ser alcançado.

O projeto aqui começou com a reestruturação do sistema, porém ficou inviável visto que o programa não tem uma estrutura logica, então estamos refazendo tudo e no final do ano vamos colocar tudo em postgres, terei prazer em deixar o amigos sempre bem informados de todo o recurso que planejamos utilizar.

Abraços.

[rrfsistemas]

O objetivo do governo é não gastar mais com mudanças...

e pelo o que eu entendi então você, Vagner, vai trabalhar, apenas por adquirir mais bagagem, de graça ?

[Maligno]

Marcos,

Você não lê com atenção? Quem disse "já fora definido a muitos e muitos anos atrás que o delphi não seria um bom caminho"? O sujeito empurra essa "decisão" pros outros e eu que quero ser o dono da verdade? Acorda!

Tudo bem. Se você entendeu isso, entendeu errado. Mas isso é problema seu. Não meu.
Duvido que você acredite, mas estou dispondo do meu tempo só pra ajudar os colegas do grupo, de forma desinteressada e imparcial.

Eu não vendo Delphi nem nada da Borland. A intenção aqui foi apenas esclarecer alguns conceitos errados, fantasias, etc. Não sei se adiantou discutir, mas espero que alguém tire algum bom proveito da thread.

Seja qual o caminho que os colegas escolherem, desejo sempre todo o sucesso. Mas, de qualquer forma, seja qual for o resultado disso tudo, certamente minha vida não mudará um milímetro sequer. Mas fico feliz de ter colaborado.





Wagner,
Não vou me dar ao trabalho de responder todos os pontos que você colocou, por dois motivos: não quero extender o post. Esse é o último. Já está ficando repetitivo demais e não está adiantando. Tento esclarecer de tudo quanto é jeito, mas não dá. Decerto você não está querendo entender. Não me faz diferença. Tenho coisa melhor pra fazer.

E por último: você não se expressa direito, usa termos errados ("controlar processos", "tudo vira código C"), conceitos misturados (componente de programação / componente de reutilização), entende errado o que eu digo e, pior, tem a firme intenção de enfiar o XHarbour guela abaixo dos colegas, como se todos fossem robôs.
Faltou honestidade nessa thread, ao afirmarem que o XHarbour faz o que de fato não faz. Aqui houve papo de vendedor, não papo de amigo.

Só vou comentar o tal componente XHarbour Para Delphi. PIADA! Esse tal componente é apenas e tão somente uma DLL XHarbour para uso no Delphi.
Existe uma diferença entre componente de reutilização de código na forma de uma biblioteca dinâmica e um componente de programação. Destaco a frase: It is hard to belive but now you can even integrate your xHarbour code with Delphi application! All you need to do is to put your xHarbour code into DLL file and then run it from Delphi application passing required parameters!. Ou seja, nesse esquema, podemos fazer um componente Delphi em qualquer linguagem que gere uma DLL. Teríamos então, componentes escritos em VFP, VB, C++, PowerBuilder, COBOL, etc. Então, deixa de ser uma característica exclusiva do XHarbour. Democrático, não? Mas que ninguém se engane. Isso é a boa e velha gambiarra. Como diz no site deles: uma forma de migrar para Delphi de forma suave. Até eles... ))

Agora faça diferente: "INSTANCIE uma CLASSE desse componente NO FONTE do Delphi!" Se você sabe o que é instanciar uma classe, vai entender, FINALMENTE, o que eu estou dizendo. Se é que você tem a intenção honesta de entender.
Agora, se você conseguir instanciar uma classe XHarbour no Delphi, você terá de mudar de nome mesmo, para MANDRAKE.

Quanta fanfarronice!

[]'s
Maligno
http://www.buzinello.com/prg

[kiko]

acho que aqui nao tem mais nenhum moleque pra ficar falando que o meu brinquedo eh melhor que o seu. isso aqui ja deu o que tinha que dar, quem entendeu o que foi falado, otimo. quem nao entendeu, leia novamente o topico. ah, e sugiro a algum moderador travar esse topico, pois discução assim nao leva a lugar nenhum, e ao invez de esclarecer duvidas de quem realmente precisa, só vai trazer confusao, discordia e tudo mais que se pode imaginar...