emotta

Gostei, nesse exemplo, qual é o conteudo da variavel "cert" em crypt:SetSigningCert(cert)

Pra que serve o CHILKAT?

dbusearea tem uma documentação completa desde a época no NG (Norton Guides) isso ainda nos anos 80. Essa eu realmente não entendi. Mas segue abaixo um manual completo e com exemplo da função dbusearea DbUseArea() Opens a database file in a work area. Syntax DbUseArea( [<lNewArea>] , ; [<cRddName>] , ; <cDatabase> , ; [<cAlias>] , ; [<lShared>] , ; [<lReadonly>] , ; [<cCodePage>] , ; [<nConnection>] ) --> NIL Arguments <lNewArea> If .T. (true) is passed for <lNewArea>, the function selects the next unused work area before the database is opened. The default value is .F. (false), which opens the database in the current work area. If the current work area is used, all files are closed before the new database is opened. <cRddName> <cRddName> is an optional character string with the name of the RDD to use for opening the database file. It defaults to the return value of RddSetDefault(). <cDatabase> This is a character string holding the name of the database file to open. It can include path and file extension. The default file extension is DBF. <cAlias> This is the symbolic alias name of the work area as a character string. It defaults to the file name of <cDatabase> without extension. <lShared> Specifying .T. (true) for <lShared> opens the database in SHARED mode. The default value depends on the SET EXCLUSIVE setting. If set to ON, <lShared> defaults to .F. (false). <lReadonly> Specifying .T. (true) for <lReadonly> opens the database in READONLY mode. The default value is .F. (false) which opens the file for read and write access. <cCodePage> This is a character string specifying the code page to use for character strings stored in the database. It defaults to the return value of HB_SetCodePage(). <nConnection> This parameter specifies a numeric server connection handle. It is returned by a server connection function which establishes a connection to a database server, such as SR_AddConnection() of the xHarbour Builder SQLRDD. When <nConnection> is passed, the function opens a database on the server. Return The return value is always NIL. Description DbUseArea() opens an existing database file named <cDatabase> in the current work area, or in the next unused work area when <lNewArea> is set to .T. (true). The file is searched in the following directories: first in the current directory, then in the SET DEFAULT directory and finally in all directories specified with SET PATH. If the file cannot be found, a runtime error is raised. When a database is to be accessed in a network, it should be opened in SHARED mode, since EXCLUSIVE usage of a database file prevents other work stations from accessing the file. Shared database access requires to lock a database before changes can be written to a file. Refer to RLock() and FLock() for information about record and file locks in shared database access. Info See also: CLOSE, DbCloseArea(), NetDbUse(), RddSetDefault(), Select(), SET DEFAULT, SET PATH, Set(), USE Category: Database functions Source: rdd\dbcmd.c LIB: xhb.lib DLL: xhbdll.dll Example // The example opens a database file using command // and function syntax. REQUEST DBFCDX PROCEDURE Main USE Customer ALIAS Cust NEW ? Alias() // result: CUST DbUseArea( .T., "DBFCDX" , "Orders", "Ord" ) ? Alias() // result: ORD CLOSE ALL RETURN

Gibaf, antes de fazer qualquer API o melhor é primeiro simular o funcionamento através do CURL, via linha de comando. Depois de funcionando no CURL vc parte para usar no (x)Harbour. Do jeito que você postou pode ser milhares de coisas, não da pra saber, principalmente pq vc não colocou quase nenhuma informação na sua pergunta. Então tente encontrar algum exemplo funcionando em CURL de todo processo primeiro, pq funcionando desta forma vc sabe que a API em si etá correta e ai basta converter a forma de uso pelo CURL para sua aplicação. Geralmente os desenvolvedores da API disponibilizam sempre exemplos de como se consumir pelo CURL.

Não vejo vantagens técnicas de migrar para 64 bits, o maior problema que tínhamos em 16 bits era basicamente a quantidade de endereçamento de memória disponíveis para a aplicação. Quem aqui se lembra das fechadas inesperadas do sistema, que simplesmente era finalizado em qualquer mensagem ou alguma mensagem aleatória, sem qualquer motivo aparente. Basicamente isso acontecia pq a aplicação 16 bits tinha poucos espaços disponíveis e quando precisava alocar algo novo ou não conseguia encontrar um espaço ou dava conflito com outro espaço que já havia alocado para outra coisa. Então a migração para 32 bits era muito necessária e foi um alivio geral quando aconteceu. Graças ao (x)Harbour. Diferente do que muita gente pensa a migração de 16 para 32 bits não dobrou a capacidade, o calculo é feito de outra forma, mas uma maneira simples de explicar o aumento é o seguinte: Imagine que você tinha R$ 9,00, a mudança para 32 bits aumentou um digito e com isso você passou a ter R$ 99,00. Não é isso exatamente mas é essa a idéia. A mudança para 64 bits vai aumentar a disponibilidade desses endereços, além de outras coisas, mas isso não faz diferença alguma para nós que fazemos atualmente aplicações 32 bits. Qual a diferença de ter 1 bilhão de espaços para usar ou 10 bilhões sendo que não usamos nem 1 milhão?

A melhor maneira de obter dados é consumindo as apis que eles disponibilizam. Mas pelo que entendi vc quer ler dados de site, isso tb é possível, os buscadores fazem isso a décadas, a técnica tem até nome "crawling". Eu nunca trabalhei com isso mas não aconselho a entrar nessa, vc pode até conseguir ler dados mas qdo o site mudar alguma coisa vc terá que refazer seu algoritmo para ler corretamente as informações, imagino que a manutenção disso se tornará infernal com o tempo. Então tente obter informações via API como disse acima, o lado ruim é q vc depende deles disponibilizarem isso.

Marca, na verdade eu tive esse problema mas com diversos componentes e não somente com xBrowse. O problema me perseguiu por anos e em diversas versões do xharbour e fivewin. Melhorou um pouco quando fiz o que relatei acima, mas eventualmente voltava ocorrer. Por isso eu acho q deve ser algum bug que ocorre aleatoriamente em algumas circunstancias bem especificas, nunca consegui simular propositalmente esse problema, se conseguisse teria sido mais fácil resolver.

vc nunca passou por esse problema @kapiaba ?

Gibaf a única explicação sobre esse problema é que o garbage collector do xharbour entende que a variável da fonte não é mais necessária para o sistema e com isso limpa essa variável da memória. Se vc vincular a fonte explicitamente a dialog (of oDlg) isso não é para acontecer. Como te falei, por anos passei por esse problema e melhorou um pouco quando passamos a fazer isso mas infelizmente em alguns momentos aleatórios isso voltava a acontecer. Outra explicação é que o garbage collector do xharbour tem um bug ou algum bug do fivewin mesmo.

Kapiaba primeiro vc está perguntando pra quem? segundo, vc está perguntando o que? LOCAL ou PUBLIC o que?

Tenta no lugar o oWndMain colocar a mesma dialog do xbrowse

DEFINE FONT oFont NAME "Arial" SIZE 0,-12 BOLD Of oWndMain

Por anos passei por problema semelhante, eu não me lembro ao certo mas melhorou bastante qdo passei a vincular a fonte a window principal do sistema. Então na hora que vc cria a fonte faça o "of oWndMain" sendo o oWndMain a variável que contém sua window principal

está bem legal a tela... esse gerenciador de impressão ta a cara do protheus. Bem legal.

veja neste tópico http://www.pctoledo.com.br/forum/viewtopic.php?f=4&t=12228

Eu não falei para recriar a roda, o que eu disse é para criar uma classe para facilitar o uso e nessa classe usar uma PDF.LIB para gerar PDF, também pode ser essa HARUPDF (que eu já vi mas nunca usei). Sobre a printer.prg gerar PDF ela até gera, mas não da maneira correta. Ela simplesmente converte os wmf gerados na impressão para paginas PDF. Por este motivo que o PDF fica grande. Eu tomei essa decisão que sugeri a mais de 20 anos atrás e vejo que foi uma excelente alternativa, que me ajudou muito quando desenvolvi o sistema web em outra linguagem e utilizo a geração dos relatórios ainda em xHarbour e gerando PDF (e excel) na web. Estou sugerindo o que deu certo pra mim, o que não significa que não existam outras alternativas boas também. Mas no meu caso foi o que deu muito certo, então é o que eu recomendo.

se vai começar algo novo eu sugiro vc criar uma classe própria para interfacear o uso de uma PDF.LIB e gerar os relatórios em PDF.

Para celular recomendo react native. Mas se quiser uma solução pronta de controle de jornada, 100% web (cloud native), que permite marcação de ponto por celular ou reconhecimento facial via web e já adequado a portaria 671 (registrado no INPI) é só me procurar. Dê uma olhada: https://site.apontafacil.com.br

É só chamar SR_SETFILTER sem passar nenhum parâmetro. Exemplo: // para filtrar CLIENTES->(Sr_SetFilter("CODIGO > 1000")) // para saber o filtro cFiltro := CLIENTES->(Sr_SetFilter()) MsgStop(cFiltro) // vai exibir: CODIGO > 1000

gibaf, deixe sua duvida original e dps a resposta de como resolveu. Outras pessoas poderão ter a mesma duvida. Acho que assim ficaria melhor.

esse é um projeto descontinuado, é fria, nem perca tempo. A melhor forma de rodar o sistema em um mac seria alguma solução como essa do video abaixo. É gambiarra mas deve resolver. Nunca usei solução como essa, eu estava estudando essa possibilidade a alguns anos antes de reescrever parte do sistema para web usando outras linguagens. Mod_harbour ainda era um protótipo quando eu fiz a mudança. Se fosse hoje em dia eu separaria um tempo para estudar essa possibilidade, embora ainda não tenha visto nenhum projeto de fato funcional usando ele.

react.js no front, ruby on rails no backend e xharbour processando regras e negócio e relatórios em um controle de filas

Eu entendo que já era esperado algo assim devido ao boom na contratação de programadores nos últimos anos. As empresas estão enxugando o que contratou a mais, cortando custos e mantendo os programadores que elas consideram o melhor custo beneficio. Isso é uma questão mundial então aqui no Brasil não existe muito a ser feito. Outro problema é que se um programador que ainda está restrito ao mercado on premisse, ou seja, sistema desktop, deve se atualizar e aprender web e aplicativos. Ainda existe mercado para programador de linguagens antigas? Claro que sim, Cobol está aí pra provar, desde que eu comecei a programar, isso em 1993, eu ouço que Cobol está morto. O mesmo vale para Clipper, Delphi, (x)Harbour, etc. O problema é que se você se apegar somente a essas tecnologias mais antigas, está restringindo as opções. Hoje em dia quem domina Javascript (por exemplo) não fica desempregado. Existe uma gama gigante de empresas contratando profissional nessa tecnologia ou semelhantes. Eu ainda continuo com bastante coisa em xHarbour, mas não da pra fechar os olhos para novas linguagens e tecnologias. A alguns anos tive que aprender algumas novas linguagens e descobri como é árduo e dificil aprender uma linguagem de programação depois dos 40 anos. kkkk

Vc consegue fazer um fonte simplificado simulando o problema? A chance da função FILE estar bugada é praticamente zero, é possivel que esteja mas o mais provavel é que seu código esteja com algo errado. Se fizer um fonte simplificado pra simular o problema pode ser que vc mesmo já identifique o erro ou então postando aqui fica mais fácil de lhe ajudarmos.

comece pela opção dois e ataque ponto a ponto começando pelos pontos de maior lentidão. Depois de esgotada a alternativa 2 então vc analisa se é importante fazer a opção 1 e criar outros servidores (pois isso envolve custo) Se vc já começar pela opção 1 vai gastar dinheiro a toa.