Usar StartTrhead com WVT é possível ?

[luizservulo]

Boa tarde pessoal,

Gostaria de saber se alguem tentou usar a WVT + xharbour 1.10 ou 1.20.01 utilizando-se das funções StartThread?

Luiz Servulo

[alaminojunior]

Eu uso funções como hb_openprocess() e demais, e não sei se é a mesma coisa, mas funciona.

[sygecom]

Luiz, o MT do xHarbour com todo o respeito esta uma Mer......cadoria. Se queres usar MT sem problemas é melhor pensar em migrar para Harbour, um simples e-mail co HB_SENDMAIL() que você enviar por três vez no xHarbour por MT já da uns GPF, já comuniquei esse erro a um tempo atrás...

[marcosgambeta]

Se queres usar MT sem problemas é melhor pensar em migrar para Harbour...

O Marcelo Lombardo, que é um desenvolvedor experiente, respondeu certa vez no news do xHarbour o seguinte:

Código: Selecionar todos

Assunto: Abrir Thread
De: "Renato Benedetti"
Data: Fri, 1 Feb 2008 19:33:26 -0200

Pessoal, estou utilizando um criterio não muito legal para criar thread no 
meu sistema.
Na realidade nem thread é:

eu gravo um .BAT contendo varios:
start /b /Min /low <Programa>

depois mando executar o BAT e ele sai abrindo várias janelas do meu sistema 
para executar os processos.

Existe alguma coisa mais inteligente no xHarbour do que esta 'besteira' que 
faço, herdada da programação do velho clipper ??

Como estou transportando meu sistema para rodar em Windows e Linux com 
Postgree, eu precisava abrir estas Threads no windows e no linux.

Abs,
Renato

Código: Selecionar todos

Assunto: Re: Abrir Thread
De: Marcelo Lombardo
Data: Sun, 03 Feb 2008 13:18:50 -0200

Renato,

Esse é um caminho muito perigoso. O MT no xHarbour não está legal. Já conversei com o Ron sobre uma rearquitetura total dessa etapa, de uma maneira muito mais simples de ser implementada e muito mais segura, mas ainda temos que amadurecer essa idéia. Enquanto isso, recomendo a vc ver os BACKGROUD TASKS que resolvem boa parte dos casos.

abs,

Marcelo

MT, no Harbour, está melhor implementada, mais estável e mais segura do que a implementação existente no xHarbour.

[sygecom]

É na verdade no meu ponto de vista tudo que estava de errado no xHarbour os desenvolvedores não repetiram o erro no Harbour o que é logico, mas fora o MT e uns detalhezinho a mais o xHarbour ainda é valido...

[Itamar M. Lins Jr.]

É na verdade no meu ponto de vista tudo que estava de errado no xHarbour os desenvolvedores não repetiram o erro no Harbour o que é logico, mas fora o MT e uns detalhezinho a mais o xHarbour ainda é valido...

Eu vejo diferente. Não será fácil fazer modificações no xharbour.org porquê ele está ligado, "infelizmente" ao xharbour.com qualquer modificação que em contrapartida force modificações nos produtos xharbour.com não serão feitas. Isso é a minha opnião e posso está equivocado mas depois de quase 3 anos sem movimentação no xharbour.org apenas cópias das implementações do harbour foram acrescentadas no xharbour.org.
Exemplo, NETRDD, IOMEM, etc, vejam que eles não portaram o hbmk2 que é superior ao hbmaker, RDDSQL necas, então é isso. A parte de comunicação serial do harbour, etc porquê ? Confitos de interesses comerciais.
Para ambiente linux, eu não usaria e nem indico o xHarbour. Não há ninguém lá com conhecimentos suficientes para fazer metade dos trabalhos que precisarão serem feitos e que na época foram feitos pelo Przmek, e nem clientes "$$$$" que compense isso.
Resumindo, para o xHarbour chegar perto do Harbour são necessárias muitas melhorias, e infelizmente não estão ocorrendo, pelo menos é que podemos constatar quando atualizamos ele via CVS.

Saudações,
Itamar M. Lins Jr.

[marcosgambeta]

É na verdade no meu ponto de vista tudo que estava de errado no xHarbour os desenvolvedores não repetiram o erro no Harbour o que é logico, mas fora o MT e uns detalhezinho a mais o xHarbour ainda é valido...

O xHarbour acabou servindo como um campo de testes para o Harbour. Há recursos que acabaram sendo adicionados ao Harbour, mas de uma forma superior (sem copiar o código do xHarbour, sem prejudicar a velocidade de execução, ampliando os recursos, etc...)

[marcosgambeta]

Não será fácil fazer modificações no xharbour.org...

Estou começando a pensar desta forma também:

1) A idéia de adotar o TBrowse do Harbour, escrito do zero pelo Przemek e bastante fiel ao do Clipper, gerou divisão entre os desenvolvedores.

2) Adotar o hbmk2, que seria uma solução superior ao hbmake, causaria outra divisão, pois o hbmake perderia seu status.

3) Os compiladores Pelles C, Visual C++ e BCC recebem atenção, mas outros como o MinGW acabam ficando de lado.

4) Com excessão da HWGUI, as outras bibliotecas gráficas são, com frequência, comentadas de forma negativa. E isto inclui a xHGTK, que foi compatível com o xHarbour desde o começo.

5) Debian e distribuições derivadas são sempre desaconselhadas.

Chega uma hora em que o ânimo de lutar pelo projeto começa a diminuir.

[Itamar M. Lins Jr.]

Ola!

2) Adotar o hbmk2, que seria uma solução superior ao hbmake, causaria outra divisão, pois o hbmake perderia seu status.

Ontem o hbmake deu seu último suspiro no core do Harbour, Viktor Szakats o removeu definitivamente.
Veja que o hbmk2 já tem cláusula para converter os arquivos do hbmake para o padrão dele, inclusive suporta arquivos do xMate também.
A HBIDE que está sendo criada vai usar o hbmk2 e o seu criador está procurando fazer um programa com as caracteristicas do xMate e isso é muito bom.


Saudações,
Itamar M. Lins Jr.

[sygecom]

Eu só lamento o pessoal do xHarbour não aceitar essa realidade, mas fazer o que. Quem sabe um dia o SQLRDD rode com Harbour....hare baba...