PC Toledo

De Paula,

Olha de novo o código eu removi funções que você não vai precisar.

Jairo Maia escreveu: Microvolution, substitua nesse exemplo que você postou esse bloco, por este:

Agora sim... depois de muita insistência de minha parte, e, às vezes ser mau interpretado, o autor do tópico (professor Jairo), bem como o professor asimoes, sem esquecer do JQuintas, Eolo, Toledo, etc... me perdoem se esqueci...
agora sim... estão começando a entender o que estava acontecendo...
não tinha nada a ver com o meu código em si... é questão de entender "essa coisa loka" de win_prn, que no manual que traduzi, não é a prática da coisa.
Lá no manual (guia de referência), não fala nada sobre essas {} que V.Sas. estão usando.
Vejam como já está ficando a impressão: Agora, parece que é uma questão de alinhar página para começar bem à esquerda e aproveitar toda a margem direita, ou seja, como no Word, eliminar as os espaços (esquerda, direita, etc).
Pois o relatório agora não está dando quebra de página.

Bom, quero entender e não somente ficar copiando e colando, pois novas situações virão e preciso aprender pra poder contribuir com outros que precisarem aqui no fórum.

asimoes escreveu:Olha de novo o código eu removi funções que você não vai precisar.

Prezado, como estou muito cansado e com os olhos e corpo todo doendo, hoje não vou testar o seu código, mas, amanhã (se Deus permitir) o farei, pois, as mudanças do professor Jairo estão começando a surtir efeito.

Agora, precisamos saber como eliminar as margens esquerda e direita.

asimoes escreveu:De Paula,
Olha de novo o código eu removi funções que você não vai precisar.

ah!... não aguentei dormir sem testar, pois V.Sa. tem me ajudado e muito...
mas, infelizmente, faltam essas funções no seu código: vlw pela boa vontade!

X:)
Gente, quero agradecer a todos e pela paciência!
Se eu fui rude ou mau interpretado por alguém aqui do fórum, me perdoe, pois, todos sabem, que o nosso cansaço mental e todo o desprendimento com essa área (programação) nos deixa com nervos à flor da pele.

Não estamos por encerrando nossa participação neste tópico, mas, já estamos no caminho de o encerrar. De acordo com a última postagem do professor Jairo (autor deste tópico) que entendeu o que realmente estava acontecendo, e, de acordo com minha última imagem postada, que o formulário (impressão) parou de dar quebra de linha (enter ou CR - como no antigo clipper), mas, ainda a impressão parece que faltava alguma coisa, e, com minha paciente (meia boca) tradução inglês/português do único guia de referência (gratuito) que encontrei da classe Win32Prn (do xharbour) pude ligar a peça que faltava do quebra cabeças (ou quase toda ela), que é a seguinte chamada ao método ":leftmargin". vejam com o array oPRN (no seu pode ser que esteja usando oPrinter, ou oPin, sei lá) : Vejam o resultado (na cor verde, pois minha impressora acabou a tinta preta) da impressão como eu queria desde o princípio de tudo: Ainda, faltam alguns detalhes, mas, acho que agora, já estou começando a entender (0,001%) do vosso conhecimento.
Até amanhã, se assim, o Criador permitir!
#-)

De Paula,

Quanto aos erros eu informei para você incluir hbnf.hbc no hbp. Tudo é uma questão de olhar com cuidado as informações que estamos te passando.

Parabéns.

boa tarde a todos e um ótimo domingo...
estou de volta por aqui!
Como disse ontem, ou melhor, "de madrugada", está quase tudo no fino.
Então fiz algumas comparações:
1 - o arquivo que é gerado antes de mandar pra impressora: 0001.tmp está tudo alinhadin din din din...
2 - o arquivo onde o professor Jairo sugere no MemoLine que se acrescente as funções PadC e alltrim, ainda está com um pequeno erro de configuração;
3 - fiz os testes com sem o alltrim () e não imprime nada;
4 - fiz os testes com o alltrim () e trocando o padC() para padL() onde pensava que o texto iria se alinhar à esquerda, mas, foi totalmente pra direita;
5 - então mudei pra padR() e mesmo assim, o resultado não foi o mais correto;
6 - com o acréscimo do métido :leftMargin a coisa realmente ficou top, como mostrei na última imagem na cor do relatório verde/branco, ficando apenas os DADOS DO CLIENTE e os DADOS DE SUA DÍVIDA centralizados.

Então, pelo que estou vendo, estamos perto de encerrar (da minha parte) esta questão, pois os dados do cliente e os dados de suas dívidas, não podem centralizar como o PadC e o Alltrim (eliminando os espaços left/right) estão fazendo... falta alguma "coisica de nada" para que o relatório fique como era (ou próximo) na impressora matricial.

visitem meu site e peguem o guia que traduzi todo em português da Win32Prn (xharbour) que é semelhante à nossa do harbour: http://www.mvinfo.wmx.net.br/programacao

... no aguardo... bom domingo a todos! )

Olá Microvolution,

Duas coisas a serem acertadas antes de testar:

1 - Altere essa linha que passei antes: Por essa: 2 - Altere também a definição Default (padrão) da margem esquerda usando o que você já sabe, a saber :LeftMargin, colocando inicialmente desta forma:Então ajuste para mais ou para menos para acertar a impressão. Tenha em mente que :LeftMargin tem que ser em pixels.

NOTA: Veja que alterei também a função HB_AnsiToOem() por HB_OemToAnsi(), na tentativa de corrigir a impressão de caracteres especiais (cedilha e caracteres acentuados).

Olá pessoal...
estou fascinado com tanto conhecimento que o pessoal aqui do fórum tem, sem exceção.
Não vou aqui citar o nome de todos nem de ninguém (por enquanto), para não ser injusto, apenas, mencionarei 2 colegas professores, que entenderam o que eu queria passar. Os demais, com toda a certeza, se também tivessem me entendido, conseguiriam soluções bem práticas e funcionais.
Mas, como disse, o nome de um deles é autor deste tópico, basta quem estiver lendo esta mensagem ou entrando aqui neste, pela primeira vez, voltar à página nº 1, e, o outro, só entrou neste tópico na 5ª página e o foi o último a dialogar comigo naquela página.

Agora, estou num dilema, o meu código foi consertado por um dos professores (era o que eu queria), já o outro professor me apresentou outro código diferente que também é muito funcional. Enfim, agora fiquei numa "saia justa" ou melhor, "cueca justa", :)Pos e portanto, pra quem não tinha a solução para os problemas, agora tenho duas opções totalmente distintas e muito bem funcionais.

Aos que estão procurando uma solução para impressão em ambiente windows 32 ou 64 bits e quer sair do set printer to, neste tópico temos 2 soluções de excelente bagagem.

Aos moderadores e ao Ilmo. Sr. Toledo - administrador, poderiam testar e destacar os códigos aqui, pois são de grande valia para os mais "leigos" como eu.

Por enquanto é só!

Antes de considerar resolvido ... pode querer melhorar as letras acentuadas.
Isso tem a ver com CODEPAGE.

Aqui eu não usava letras acentuadas, então foi mais fácil, simplesmente adotei a codepage do Windows PT-BR pra tudo.

Isso pode ser diferente na tela, no arquivo, na impressora, no PDF, no editor de código fonte, etc.

JoséQuintas escreveu:pode querer melhorar as letras acentuadas.

ah! sim, muito bem pensado professor.
Dá pra me explicar como isso funciona, pois, inclusive nesta GTWVG no vídeo o "ã" (letra A com o TIL) está saindo meio estranha.
Também, na impressão tem alguns caracteres que estão trocados.

Pode me dar mais informações?
agora já são 2h40... vou ter que sair pra descansar um pouco e pegar novamente às 8h.
#-)

pessoal, no post: , acabei de postar dúvidas quanto ao novo harbour 3.4.
Mas, ao atualizar para ele (usando a lib GTWVG - nao testei com HMG, por hora) apresentou erro na seguinte linha: Tive que "comentá-la" pra compilar por hora. O erro diz que o FUN_HB_ANSITOOEM é uma função não reconhecida.
Alguém sabe o que pode ser?
Aliás, conforme

Jairo Maia escreveu:1 - Altere essa linha que passei antes:
Expandir visualizacao
Ver codigo
1 oPrn:TextOut(HB_AnsiToOem(PadC(AllTrim(MemoLine(cText,254,n)),oPrn:MaxCol())),.t.)
Por essa:
Expandir visualizacao
Ver codigo
1 oPrn:TextOut(HB_OemToAnsi(RTrim(MemoLine(cText,254,n))),.t.)

não fiz essa mudança ainda... vou fazer pra ver se corrige esta atual mensagem de erro, acreditando que não possa ser isso o problema, pois antes de migrar p/ o harbour 3.4, no harbour 3.2, isso não acontecia.

como suspeitava, modifiquei e continuou o erro. Também tirei o HB_ do início e o erro foi o mesmo.

Vlw!

Microvolution, porque você precisa usar o Harbour 3.4 nesse momento? Não seria mais prudente você estabilizar seu sistema, colocá-lo em produção, depois tentar outros avanços?

Não sou nem de longe e nem quero ser exemplo a ninguém, mas conheço o Harbour 3.4, porém, ainda uso o Harbour 3.2. Mil desculpas, mas parece que você está tentando dar passos maior que suas pernas... (opinião meramente pessoal, porém, sincera).

Jairo Maia escreveu:(opinião meramente pessoal, porém, sincera).

prezado professor, lhe admiro muito, pois muito tem contribuído pra me ajudar.
Bom, fiquei muitos anos perdendo tempo sem fazer nada pra vender meu aplicativo (programa antigamente - se falava), num total de 18 anos, com apenas um único cliente me pagando e outros 2 que não me pagam nada, a não ser quando dá "pau" que é raro, com uma linguagem 100% clipper.
Então, em janeiro deste ano que se encerra é que consegui começar a entender este universo e migrei através da HMG 3.0.35.
No finalzinho deste ano, o amigo e professor JQuintas me abriu a mente a experimentar a GTWVG, que já migra tudo em modo gráfico com uma cara semelhante ao CONSOLE.
Aí comecei a fazer os testes e gostei, pois há possibilidade de implantar botões...
só que quando fui aprofundar um pouco mais, me esbarrei nalgumas funções que o Viktor Ska... fez exclusivamente para o harbour 3.4.

Foi aí que baixei.
Mas, tudo isso:
- sem perder a (HMG 3.0.xx, inclusive já baixei a 3.4.2);
- sem perder os módulos que estão funcionando no harbour 3.2 (como as funções que V.Sa. [Jairo] me passou);
- se eu quiser voltar a compilar no harbour 3.2, é só mudar o path lá no "variáveis de ambiente", pois as pastas estão intactas do jeito que funcionava antes.
- além do mais, como sei um pouquinho de delphi 7 (instalei o XE3), pois se for pra refazer os gráficos todos nas mãos, não vejo porque continuar com o harbour/gui, sendo que no delphi é tudo muito mais fácil. Aliás só não o fiz, porque meu aplicativo está no padrão DBFNTX e lá já tentei de tudo e só aceita no máximo DBFCDX. E pra mudar isso no meu aplicativo que está funcionando, ainda achei complicado demais.

Bom, mas, valeu a dica, é bom sempre ver, ouvir, todos os lados!
Um certo dia, o meu único cliente, comprou uma máquina win 7 e a coisa começou a piorar.
Então, se hoje, eu aprender a migrar e compilar em 64 bits, não hesitarei em aprender, a não ser que seja uma coisa muito difícil...
abraços!

Olá Microvolution,

microvolution escreveu:Então, se hoje, eu aprender a migrar e compilar em 64 bits, não hesitarei em aprender, a não ser que seja uma coisa muito difícil...

Essa é a questão. Fazer seu sistema inicialmente trabalhar em 32 ou 64 bits, nos Windows 7, 8 ou 10. Isso é a primeira etapa. familiarizar-se com o Harbour, depois avançar para uma lib gráfica como a GTWVG por exemplo.

Quanto a ser muito difícil, isso depende de cada um...

Obviamente usar o Harbour 3.4 será uma consequência natural para todos que hoje usam o Harbour, penso que isso é sem volta, mas fica mais fácil se tudo for passo-a-passo. Por exemplo, no 3.4 não existe Hb_OemToAnsi() e nem Hb_AnsiToOem(), chamam-se respectivamente Win_OemToAnsi() e Win_AnsiToOem().