Clipper On Line • Ver Tópico - WAPI v1.05 - Funções da API do Windows
Página 1 de 51

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 09 Ago 2006 03:53
por Maligno
Nem preciso dizer muito. É só ler o fonte:
http://buzinello.com/download/wapi.zip.

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

-----------------------------------
Nota de Moderação:
tópico movido da seção Clipper, pois seu conteúdo não se relaciona com aquela seção.

Aplicativos para Windows

MensagemEnviado: 09 Ago 2006 22:35
por Pablo César
Legal essas funções Paulo,

-REBOOT -> reinicializa o Windows
-POWEROFF -> desliga o Windows
-HIBERNATE -> coloca o Windows em estado de hibernação
-SUSPEND -> suspende o Windows
-FLASH -> faz o botão da taskbar piscar
-TASKBAR:<ON|OFF> -> torna invisível/visível o botão na taskbar
-TITLEBAR:<TEXTO> -> muda o texto na barra de título da janela
-BUTTONX:<ON|OFF|DEL> -> liga/desliga (ON|OFF) o botão X da janela ou (DEL) remove o ítem do menu de contexto da janela (neste caso, não será possível recolocar o ítem no menu)

Mas agora tenho uma sugestão. Acho que eu já fiz o seguinte questionamento:

Teria como ampliar o seu código fonte para verificar, se já existe uma janela (digamos com o mesmo TITLEBAR) e se for positivo, criar um arquivo (digamos: RODANDO.TXT) ?. Daí então, poderiamos rodar dentro do aplicativo Clipper para saber se ja não está rodando (minimizado), isto é, em multi-sessão.

Seria bom conseguir isto, claro que a sua presteza, sabendo que estaria sujeito a margem de erro. Mas a principio funcionaria. Me dê a sua opinião Sr. Paulo.

E obrigado pela sua participação aqui no FORUM.

sds :{

MensagemEnviado: 10 Ago 2006 02:26
por rrfsistemas
Não sei se vai ajudar muito mas, eu faço da seguinte forma no meu sistema em Visual Fox Pro, com a API do Windows. ;)

Não sei como vc vai adaptar este códogo...
Public _SISTEMA
_SISTEMA = "  SIADEM - Empresa v1.02 Demo"
Declare Integer FindWindow In WIN32API String, String
Declare Integer BringWindowToTop In WIN32API Integer
Declare Integer IsWindow In WIN32API Integer
janela = FindWindow(0, _SISTEMA)
If (IsWindow(janela)<>0)  && verifica se existe uma janela com o nome
   = BringWindowToTop(janela) && coloca a janela em cima de todas
   _Screen.Caption = _SISTEMA   
   = Messagebox('SISTEMA JÁ ESTÁ EM USO NESTA MÁQUINA !!!', 000, 'Atenção')
   Return
Endif
Release janela
Clear Dlls
CLEAR
Clear All
_SISTEMA = "  SIADEM - Empresa v1.02 Demo"
_Screen.WindowState = 2
lcOnShutdown="ShutDown()"
On Shutdown &lcOnShutdown
On Error ErrorHandler(Error(),Program(),Lineno())


Espero que ajude !! :xau

MensagemEnviado: 10 Ago 2006 04:54
por Maligno
rrfsistemas escreveu:Não sei se vai ajudar muito mas, eu faço da seguinte forma no meu sistema em Visual Fox Pro, com a API do Windows. ;)

Não sei como vc vai adaptar este códogo...
Public _SISTEMA
_SISTEMA = "  SIADEM - Empresa v1.02 Demo"
Declare Integer FindWindow In WIN32API String, String
Declare Integer BringWindowToTop In WIN32API Integer
Declare Integer IsWindow In WIN32API Integer
janela = FindWindow(0, _SISTEMA)
If (IsWindow(janela)<>0)  && verifica se existe uma janela com o nome
   = BringWindowToTop(janela) && coloca a janela em cima de todas
   _Screen.Caption = _SISTEMA   
   = Messagebox('SISTEMA JÁ ESTÁ EM USO NESTA MÁQUINA !!!', 000, 'Atenção')
   Return
Endif
Release janela
Clear Dlls
CLEAR
Clear All
_SISTEMA = "  SIADEM - Empresa v1.02 Demo"
_Screen.WindowState = 2
lcOnShutdown="ShutDown()"
On Shutdown &lcOnShutdown
On Error ErrorHandler(Error(),Program(),Lineno())


Bom, é a idéia que o colega teve. Mas não é a forma "canônica" para evitar múltiplas instâncias do mesmo programa, até porque, a barra de títulos, para muitos programas, é um meio dinâmico de informação ao usuário. Assim, em alguns casos o título pode mudar totalmente. Para uma solução mais segura, o que normalmente se utiliza é um objeto de sincronização de tarefas (semáforos de threads) chamado Mutex. O princípio é simples: uma vez que apenas uma tarefa pode ter a propriedade de um Mutex, podemos forçar para só exista uma instância de um mesmo programa rodando ao mesmo tempo. Veja o exemplo e, se achar interessante, adapte às suas necessidades.

}
HANDLE hMutex = CreateMutex(NULL,true,"RFFSISTEMAS_PROJ001");
if (GetLastError() == ERROR_ALREADY_EXISTS) {
   //
   // Mensagem de alerta ou o que quiser
   //
   if(hMutex) CloseHandle(hMutex);
   return 0;
}

//
//
// Neste ponto você dá continuidade ao seu programa
// Mas note que o Mutex continua ativo no sistema.
//
//

ReleaseMutex(hMutex);
CloseHandle(hMutex);
{

Vou verificar como o Mutex poderia ser utilizado no WAPI. Volto ao assunto depois. :)

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

Verificar se está aberta a janela WINDOWS

MensagemEnviado: 30 Ago 2006 21:12
por Pablo César
Maligno escreveu:Bom, é a idéia que o colega teve. Mas não é a forma "canônica" para evitar múltiplas instâncias do mesmo programa, até porque, a barra de títulos, para muitos programas, é um meio dinâmico de informação ao usuário. Assim, em alguns casos o título pode mudar totalmente.


Prezado colega Maligno,

Nesse caso também há outra solução. Já viu o WINTIT ?. Antes de executar meu aplicativo (através de arquivo de lote, BACTH) eu chamo o WINTIT para forçar que essa aplicação fique com o mesmo título na janela-WINDOWS.

Você ja conseguiu algo sobre essa minha idéia ?. Contamos com teu conhecimento em C, não esqueça por favor !.

Um clip-abraço
:xau :)Pos

Re: Verificar se está aberta a janela WINDOWS

MensagemEnviado: 01 Set 2006 02:55
por Maligno
Nesse caso também há outra solução. Já viu o WINTIT ?. Antes de executar meu aplicativo (através de arquivo de lote, BACTH) eu chamo o WINTIT para forçar que essa aplicação fique com o mesmo título na janela-WINDOWS.

Nunca ouvi falar.

Você ja conseguiu algo sobre essa minha idéia ?. Contamos com teu conhecimento em C, não esqueça por favor.

O problema não está no esquecimento (de fato, não esqueci). O problema está no tempo. :(
Mas, quanto a sua idéia, acho que tenho outra melhor. Uma lista de todas as janelas abertas. Você passa o nome de um arquivo e o programa lista nele os nomes das janelas abertas. Você procuraria pelo nome da sua aplicação e, existindo, você tem a opção de travar o programa, evitando uma segunda instância. E também ficaria fácil saber se um determinado programa está em execução (o Word, por exemplo). Seria uma opção a mais para a mesma função.
Aliás, um amigo que programa em Clipper também de me pediu para acrescentar uma outra função. Mas isso tudo só no final de semana. :)

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

Desafios CLIPPER x WINDOWS

MensagemEnviado: 01 Set 2006 09:14
por Pablo César
Prezado colega Maligno,

Agradeço seu interesse, e desculpe minha apelação.

O nome WINTIT, na verdade não era a função da LIB que modifica o título da janela em WINDOWS. WINTIT, é o nome da função que eu dei para chamar desde a linha de comando a função OL_95VMTITLE(VTIT). (desculpe, falha minha). Minha ãplicativo é simples:

WINTIT.PRG:
// Compilar com as LIBs: OSLIB e CPMI

PARAMETERS VTXT
VOK:=OL_95VMTITLE(VTXT)


Neste caso forço o nome toda vez que for chamado o meu sistema, chamando antes (dentro de uma BATCH) o WINTIT.EXE, forçando o título da aplicação, mantendo o nome que eu designei a minha aplicação, mesmo que o usuário tenha mudado nas propriedades do ícone.
Inclusive eu testei em todos as versões do WINDOWS, e me parece que funciona perfeitamente.

Quanto a sua outra idéia de listar os nomes das janelas abertas. Me permita fazer uma sugestão. Que essa listagem pode criar um arquivo texto, com o qual poderá ser lido e processar dentro da propria aplicação se está ativa o não. Mas de todas as formas Maligno, acho muito importante a sua contribuição a nossa comunidade. E já que estamos neste assunto, gostaria de solicitar mais uma idéia (que ja é bem conhecida de todos) para que você possa acrescer na sua biblioteca se for possível.

A outra função, que deixa a todos nós impossibilitados de manipular no Clipper é quando o usuário pressina ALT ENTER, mudando com isto a exibição de modo TEXTO ao modo JANELADO. Sei que tem duas indicações de utilizar as funções:

1. Usando CA-Tools as seguintes funções :

SetScrMode(6)
SetScrMode(3)

2. Outra opção usando a função FULLSCREEN() do colega Evolver:

www.sistemabr.com.br/clipper/fullscrn.zip

Mas, nestas opções não dá para alternar o modo de exibição de TEXTO para JANELADO e de JANELADO outra vez a sua forma original em TEXTO. Para isto, acho que se você pudesse ver se a execução atual está em modo TEXTO ou JANELADO, que grave em um arquivo dizendo qual é o modo. Daí então, no nosso proprio sistema, dariamos uma mensagem ao usuário para mudar o modo de exibição, indicando ao usuário que deve pressionar as telcas ALT ENTER. Estou insistindo muito com este assunto, porque tenho situações que preciso utilizar programas GUI que em DOS não posso fazer. E não quero que após executar um programa GUI, a minha tela anterior (em DOS), fique minimizada e com isto o usuário fique perdido.

Sei Maligno, que estou pedindo muito. Não quero lhe ofender, mas se você acha que para você desenvolver isso, deveria ser ressarcido. Eu estou disposto (sempre e quando não seja um milhão de $$$, hehehe). Desculpe a minha brincadeira, sei muito bem que a sua participação e contribuição aqui no FORUM sempre foi de forma construtiva e gratuita. O que engrandece a todos nós e ficamos muito agradecidos com a sua dedicação. Pooohh, parace que estou puxando saco, mas acho que deve ser falado. Pois é falado tantas besteiras as vezes e que coisas importantes devem ser ditas.

Bem vou deixar por aqui... senão o Maligno, daqui a pouco se cansa de mim... e não deixo trabalar nesse fim de semana. Boa sorte Maligno.

Um clip-abraço
:)Pos :* :{ -:]

MensagemEnviado: 03 Set 2006 20:56
por Maligno
Dando continuidade ao utilitário, fiz algumas alterações e uma inclusão de importância. As alterações: alguns nomes de switches foram trocados só pra melhorar a compreensão da finalidade destes (se já usou antes, verifique e altere seu código). O switch -FLASH recebeu um parâmetro para informar que quantidade de vezes se deve piscar. A inclusão: o switch -GETAPPINFO que é utilizado para criar um arquivo (nome no parâmetro) com uma lista de todas as janelas top-level dos programas em execução no Windows, semelhante a do Task Manager. O arquivo conterá handle e título (separados por vírgula) de cada janela (uma por linha, CR/LF no final, claro).
O fonte contém todos os detalhes necessários.

No ZIP eu incluí um programa de teste, que mostra como evitar que um mesmo programa seja executado duas vezes. O fonte é bem explicativo. Funciona no XP. Não pude testar em outro SO. Assim, agradeceria se alguém o testasse e desse um retorno.

Link: http://buzinello.com/download/wapi.zip

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


PS: No decorrer desta semana, novas inclusões/alterações serão feitas.

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 05 Set 2006 10:37
por Pablo César
Estimado colega Maligno,

Gostei muito da sua solução apresentada com o seu aplicativo WAPI.
E conforme você nos deu oportunidade a fazer comentários, eu gostaria de fazer alguma sugestões e comentários:

1.) O funcionamento do switch GETAPPINFO, está perfeito !. Muito bom !. E parabéns, Maligno !!!!.

2.) O funcionamento do switch SETAPPTITLE, não fica gravado no ícone da janela ativa. Funciona em momento da execução do WAPI, mas quando o WAPI é finalizado, o título original da janela, retorna. Faltaria que ele mudasse também no próprio ícone, onde acessamos pela "Propriedades" do mesmo. Dessa forma, forçariamos a que esse ícone, mantenha sempre o título ao qual o programador designou.

3.) Sobre o parametro "TIME" adicional do switch FLASH. Fiquei pensando em qual seria a sua utilidade. Pensei em algo que seria muito útil, mas requer mais uma implementação neste switch (outro parâmetro).
Agora, todos nós poderemos verificar se a janela com título XXX, está aberta ou não. Isto impedirá que o nosso aplicativo seja aberto multipla vezes. No meu sistema ja implementei e funciona perfeitamente, embora eu ainda use o OL_95VMTITLE("Título novo") da OSLIB. Mas eu gostaria ainda de avisar que com a janela piscando (aquela primeira que tinha sido aberta) e exibindo em tela, que outra janela está aberta. Claro que se fosse possível fazer piscar a janela com título XXX, digamos. Através de um parâmetro adicional. O parâmetro TÍTULO da janela. Assim como é feito no switch GETAPPINFO, que selecione a primeira janela com título indicado para pisque, chamando atenção do usuário.

4.) O switch SETTASKBAR, não funciona com o parâmetro "ON" ou "OFF". E sim funciona com "SHOW" e "HIDE". Nesta forma, a janela desaparece (como é mencionado no seu arquivo fonte .C). Nesse momento, a janela é abortada e cria uma tarefa chamada "WINOLDAP" com WIN98. Me pergunto: Para quê serviria esta opção ?. Também testei da seguinte maneira:

WAPI -SETTASKBAR:HIDE | WAPI -SETTASKBAR:SHOW

E desta forma, sim funciona. Só que a execução é momentânea.

5.) O switch SETBUTTONX:(ON ou OFF ou DEL), funciona bem. Acho que serviria para o cliente não fechar através do "X".

Mas estou muito contente e muito agradecido ao colega MALIGNO. Acho que todos nós estamos em dívida por compartilhar seus conhecimentos conosco, enriquecendo cada vez mais os recursos que podemos obter com o Clipper e aplicativos feitos na "linguagem C".

OBRIGADO MALIGNO ! :)Pos :{ :))

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 06 Set 2006 07:11
por Maligno
2.) O funcionamento do switch SETAPPTITLE, não fica gravado no ícone da janela ativa. Funciona em momento da execução do WAPI, mas quando o WAPI é finalizado, o título original da janela, retorna. Faltaria que ele mudasse também no próprio ícone, onde acessamos pela "Propriedades" do mesmo. Dessa forma, forçariamos a que esse ícone, mantenha sempre o título ao qual o programador designou.

Mas o WAPI é transiente. Ao finalizar, volta o título antigo. Se você executá-lo através do seu programa, o título permanecerá até que o seu programa termine. Não ocorre isso?

3.) Sobre o parametro "TIME" adicional do switch FLASH. Fiquei pensando em qual seria a sua utilidade. Pensei em algo que seria muito útil, mas requer mais uma implementação neste switch (outro parâmetro).

Entendeu agora porque GETAPPINFO inclui no arquivo o Handle das janelas? É através desse número que será possível (futuramente) interagir com outras janelas. Exemplo: estando o WordPad ativo e seu Handle sendo 123, você poderia fazer sua janela picar 10 vezes com o comando WAPI FLASH:10,123. Claro que isso também poderia ser feito para alertar o usuário que uma outra instância do seu programa já existe.

Agora, todos nós poderemos verificar se a janela com título XXX, está aberta ou não. Isto impedirá que o nosso aplicativo seja aberto multipla vezes. No meu sistema ja implementei e funciona perfeitamente, embora eu ainda use o OL_95VMTITLE("Título novo") da OSLIB.

Note que OL_95VMTitle() e OL_95AppTitle() não funcionam em kernel NT. Só Windows 98 pra baixo.

4.) O switch SETTASKBAR, não funciona com o parâmetro "ON" ou "OFF". E sim funciona com "SHOW" e "HIDE". Nesta forma, a janela desaparece (como é mencionado no seu arquivo fonte .C).

Pois é. Errei na documentação. Desculpe. Já consertei no fonte. O correto é SHOW/HIDE mesmo.

Nesse momento, a janela é abortada e cria uma tarefa chamada "WINOLDAP" com WIN98. Me pergunto: Para quê serviria esta opção ?. Também testei da seguinte maneira:
WAPI -SETTASKBAR:HIDE | WAPI -SETTASKBAR:SHOW

E desta forma, sim funciona. Só que a execução é momentânea.

Não tenho nenhum Windows 98 pra testar. Uso XP. Desconheço totalmente essa "WINOLDAP". Vou ver se consigo algum Windos 98 pra fazer o teste. Depois volto ao assunto.
Detalhe: no XP o efeito não é momentâneo. Uma vez que tenha tornado a janela DOS invisível, usando o WAPI diretamente na linha de comando, como teste, a janela não volta mais. Aí só "matando" a janela pelo Ctrl+Alt+Del. Se ela ficar invisível por meio do seu programa, ela desaparecerá por completo, não aparecendo nem mesmo na janela do "Task Manager". Assim, só o seu programa a tornará visível novamente, usando o SHOW. Um exemplo:

SwpRunCmd("WAPI -SetTaskBar:HIDE,0,".",".")
Millisec(5000)
SwpRunCmd("WAPI -SetTaskBar:SHOE,0,".",".")

Esse código de teste fará a janela do DOS sumir por 5 segundos. Depois volta ao normal.

5.) O switch SETBUTTONX:(ON ou OFF ou DEL), funciona bem. Acho que serviria para o cliente não fechar através do "X".

Exatamente. Mas lembre-se: ao usar o DEL, o comando de fechamento é excluído. A janela então, só será eliminada após o término do seu programa ou se o usuário apelar para Ctrl+Alt+Del.

Mas estou muito contente e muito agradecido ao colega MALIGNO. Acho que todos nós estamos em dívida por compartilhar seus conhecimentos conosco, enriquecendo cada vez mais os recursos que podemos obter com o Clipper e aplicativos feitos na "linguagem C".

É um prazer ajudar.

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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 06 Set 2006 09:52
por Pablo César
Citação: escreveu:Mas o WAPI é transiente. Ao finalizar, volta o título antigo. Se você executá-lo através do seu programa, o título permanecerá até que o seu programa termine. Não ocorre isso?


Não, não ocorre isso MALIGNO (pelo menos com WIN98).

Citação: escreveu:você poderia fazer sua janela picar 10 vezes com o comando WAPI FLASH:10,123. Claro que isso também poderia ser feito para alertar o usuário que uma outra instância do seu programa já existe.


Na função FlashTitleBar do seu código fonte está: HWND WHandle = GetForegroundWindow(). Estarias colocando mais um parâmetro ?.

Citação: escreveu:Note que OL_95VMTitle() e OL_95AppTitle() não funcionam em kernel NT. Só Windows 98 pra baixo.


Tens razão MALIGNO, testei no XP e o OL_95AppTitle() não funciona. Mas... estive comparando os OS e o que poderia ser feito. Como eu fisse: a modificação do título poderia ser feita no arquivo .PIF (do ícone do WIN98), porque o título dessa janela está escrito nesse arquivo .PIF (que poderia ser editado e gravado em baixo nível. Porém no caso do XP (não sei os outros), esse título está conforme o nome do arquivo .LNK (ícone do XP). Que renomeando esse arquivo .LNK você obterá o nome da janela para qual tenha sido mudado. Normalmente no WIN98 os ícones estão no \WINDOWS\DESKTOP e no XP normalmente estão no \DOCUME~1\XP\DESKTOP ou \documents and Settings\XP\Desktop.

Nesse caso, será que não poderias fazer algo para mudar no seu ícone também ?.

Citação: escreveu:Desconheço totalmente essa "WINOLDAP". Vou ver se consigo algum Windos 98 pra fazer o teste.


Esse "WINOLDAP" é uma parte do arquivo "winoa386.mod" (\WINDOWS\SYSTEM), que é para rodar componentes "Não-Windows" para modo 386. Segundo o que entendí ao pesquisa na WEB, veja:

http://www.xmission.com/~comphope/jargon/w/winoldap.htm

Mas eu acho que esta tarefa que fica e é adicional conforme a escução dessa opção do WAPI. Deveria ser eliminado, pois há relatos na WEB que diz trazer alguns inconvenientes na execução de outros sisemas (como deixar lento pela acumulação desses WINOLDAP e que também são considerado facilitadores para alocação de trojans, não sei se é veridico tudo isso). De todas formas, para quê poderia servir esta opção ??.

Gostaria que não esquecesse do meu outro pedido que poderia fazer parte deste seu utilitário WAPI, onde descrevo:

2. Outra opção usando a função FULLSCREEN() do colega Evolver:
www.sistemabr.com.br/clipper/fullscrn.zip que pudesse criar um arquivo indicando o tipo de exbição da janela.


Obrigado, mais uma vez MALIGNO pela sua atenção. Cabe dizer que a sua participação aqui no FORUM, sim é BEM VINDA, como assim a de todos que participam sem o fim de interesse somente pessoal. A linguagem que eu acho THE BEST, sem dúvidas é a LINGUAGEM C. É com ela que o Clipper (e todas as outras também), podem executar coisas imagináveis. Como eu gostaria poder aprender e dominar essa liguagem ! Você tem seus méritos e isso ninguem tira e eu agradeço humildemente sua colaboração.

Um clip-abraço
:)Pos :{

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 06 Set 2006 11:41
por Maligno
Não, não ocorre isso MALIGNO (pelo menos com WIN98).

Então vou ter que pesquisar depois como fazer esse título vingar. :(

Na função FlashTitleBar do seu código fonte está: HWND WHandle = GetForegroundWindow(). Estarias colocando mais um parâmetro ?.

É uma finalidade do Handle. :)

Como eu fisse: a modificação do título poderia ser feita no arquivo .PIF (do ícone do WIN98), porque o título dessa janela está escrito nesse arquivo .PIF (que poderia ser editado e gravado em baixo nível. Porém no caso do XP (não sei os outros), esse título está conforme o nome do arquivo .LNK (ícone do XP). Que renomeando esse arquivo .LNK você obterá o nome da janela para qual tenha sido mudado. Normalmente no WIN98 os ícones estão no \WINDOWS\DESKTOP e no XP normalmente estão no \DOCUME~1\XP\DESKTOP ou \documents and Settings\XP\Desktop.

Em suma: no XP funciona. No Windos 98 (pra baixo?) não funciona. Vou ter que pesquisar e arrumar outra estratégia. O estranho é que o MSDN diz que funciona. :(

Nesse caso, será que não poderias fazer algo para mudar no seu ícone também ?.

Aquela "Propriedades" que aparece no menu do ícone se refere às propriedades do atalho da janela. Não acho boa idéia mudar no arquivo. Mas tudo bem. Só preciso botar a mão num Windows 98 pra ver o que acontece. Mas acho que já tenho uma alternativa.

Mas eu acho que esta tarefa que fica e é adicional conforme a escução dessa opção do WAPI. Deveria ser eliminado, pois há relatos na WEB que diz trazer alguns inconvenientes na execução de outros sisemas (como deixar lento pela acumulação desses WINOLDAP e que também são considerado facilitadores para alocação de trojans, não sei se é veridico tudo isso). De todas formas, para quê poderia servir esta opção ??.

Não sei. Eu nunca nem ouvi falar. Só comecei a aprender a API do Windows agora, quando já estava no XP.

2. Outra opção usando a função FULLSCREEN() do colega Evolver:
www.sistemabr.com.br/clipper/fullscrn.zip que pudesse criar um arquivo indicando o tipo de exbição da janela.

Vou ver se é possível ler o status da janela DOS. Se fosse outro tipo de aplicação tudo bem.

A linguagem que eu acho THE BEST, sem dúvidas é a LINGUAGEM C. É com ela que o Clipper (e todas as outras também), podem executar coisas imagináveis. Como eu gostaria poder aprender e dominar essa liguagem !

É só querer. Literatura grátis tem aos montes. Compiladores tem aos quilos. Fontes de pesquisa às toneladas. Só depende de você. Trace seu objetivo e dedique-se a ele. Mesmo que seja apenas uma pequena parte do seu tempo. Se você se dedicar de verdade, um bom resultado será apenas conseqüência.

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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 06 Set 2006 12:33
por Pablo César
Caro MALIGNO,

Acho que as vezes o meu português, não é aquelas coisas... hehe
Deixa eu esclarecer mais a minhas colocações após a sua última mensagem:

Quando Pablo escreveu:Na função FlashTitleBar do seu código fonte está: HWND WHandle = GetForegroundWindow(). Estarias colocando mais um parâmetro ?.


Eu quis dizer quer você vai ter que colocar um terceiro parâmetro na sua função FlashTitleBar() para que aceite o Handle da janela que quer ser piscada.

Quando Maligno escreveu:Em suma: no XP funciona. No Windos 98 (pra baixo?) não funciona. Vou ter que pesquisar e arrumar outra estratégia. O estranho é que o MSDN diz que funciona.


Na verdade você entendeu errado. Eu disse que:
Tens razão MALIGNO, testei no XP e o OL_95AppTitle() não funciona.. Você tinha razão, as funções do OSLIB não funcionam em kernel NT, embora para Windows 98 pra baixo, SIM.

Por esta razão eu sugerí para ti:
Que na sua aplicação WAPI, fizesse averificação do OS que estaria sendo usado para poder alterar nas "Propriedades do Ícone". Claro que isto difere para cada versão. Daí então eu esclarecí para cada situação de versão do OS poderia ser feito:

1.) No Windows 98 e pra baixo:

Modificação do título poderia ser feita no arquivo .PIF, que "normalmente" estaria na pasta "\WINDOWS\DESKTOP". Escrevendo dentro do arquivo .PIF. Lá dentro está gravado o título da janela.

2.) No Windows XP:
Porém o título está definido de acordo o proprio nome do arquivo .LNK (ícone do XP). Que renomeando esse arquivo .LNK, passa a mudar o título da janela. Normalmente esses arquivos de ícones estão no \DOCUME~1\XP\DESKTOP (forma MS-DOS) ou \documents and Settings\XP\Desktop (padrão WINDOWS, nome longo).

Quando Maligno escreveu:Aquela "Propriedades" que aparece no menu do ícone se refere às propriedades do atalho da janela. Não acho boa idéia mudar no arquivo.


Sei que nesta minha sugestão estou forçando mesmo a questão de manter o nome da janela para o nome ORIGINAL e~fazer com que funcione os sistemas "NON-WINDOWS". Mas é básicamente isso, o que a função OL_95AppTitle() da OSLIB faz. Claro que teria que adaptar para o caso do XP e ME.

Desejo boa sorte sobre "o status da janela DOS". Eu sempre quis aprender C++, acho que o C da Microsoft seria o mais conveniente para o Clipper e não o do BORLAND. Mas este é outro assunto que irei precisar ajuda do colega, se for do seu agrado.

Obrigado, + 1 vez :)Pos

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 06 Set 2006 16:35
por Maligno
Acho que as vezes o meu português, não é aquelas coisas... hehe
Deixa eu esclarecer mais a minhas colocações após a sua última mensagem:

Talvez eu que esteja meio devagar hoje. Estou trabalhando há umas 20 horas direto. A gente acaba ficando meio "aéreo".

Eu quis dizer quer você vai ter que colocar um terceiro parâmetro na sua função FlashTitleBar() para que aceite o Handle da janela que quer ser piscada.

É isso mesmo. Não só o switch FLASH, mas qualquer outro switch que permita alguma interação com outra janela.

Que na sua aplicação WAPI, fizesse averificação do OS que estaria sendo usado para poder alterar nas "Propriedades do Ícone". Claro que isto difere para cada versão. Daí então eu esclarecí para cada situação de versão do OS poderia ser feito:

Sim. Se o efeito muda para cada SO, nada mais natural que haja um recurso para cada SO. Ou pelo menos, um para kernel NT e outro para os demais. Mas, as propriedades a que você se refere residem num PIF. O que eu não quero é alterar PIF. Não é o caminho mais conveniente. Mas lembre-se de que eu comentei que já havia pensado em algo. Acho que deve resolver. Mas antes, eu preciso arrumar um Windos 98. :)

Sei que nesta minha sugestão estou forçando mesmo a questão de manter o nome da janela para o nome ORIGINAL e~fazer com que funcione os sistemas "NON-WINDOWS". Mas é básicamente isso, o que a função OL_95AppTitle() da OSLIB faz. Claro que teria que adaptar para o caso do XP e ME.

Eu sei o que a OSLib faz. Ela usa um recurso simples, através da ativação de uma interrupção chamada Multiplex, em Assembly. Veja o fonte. É simples de tudo. É isso que pode ser feito, caso seja detectado um kernel não-NT. Mas vou ver se consigo uma alternativa melhor. Depois de ver o Win98.

Desejo boa sorte sobre "o status da janela DOS". Eu sempre quis aprender C++, acho que o C da Microsoft seria o mais conveniente para o Clipper e não o do BORLAND. Mas este é outro assunto que irei precisar ajuda do colega, se for do seu agrado.

Prefiro da Borland, que tem um compilador que consegue excelentes otimizações. Tem o GCC também. Muito bom. Mas nem dá pra dizer qual é melhor. Empatam. Mas isso não importa muito. Se o código C/C++ estiver dentro do padrão ANSI (as duas linguagens são padronizadas mundialmente), qualquer compilador decente vai compilar sem problema.

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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 08 Set 2006 14:53
por Pablo César
Caro colega MALIGNO,

Me permita fazer outra solicitação ao seu aplicativo WAPI:

Haveria possibilidade de colocar na fila de impressão do WINDOWS um arquivo ?. Talvez utilizando o SIMPLEX do BCC ++ ?.

Pois assim que trabalha o aplicativo USB apresentado pelo Heveraldo que é compilado com BCC++ e xHarbour em modo TEXTO, ele utiliza uma técnica que muito simples, de colocar o arquivo de impressão na fila de impressão do proprio WINDOWS.

Eu solicitei encarecidamente para os colegas que "dominam" xHarbour, para disponibilizar esse recurso em arquivo OBJ ou criação de uma LIB, mas não tive respostas.

Aí pensei... , o seu aplicativo WAPI, está ficando muito bom com todas estas implementações e ainda melhor se você pudesse disponibiliza-lo em uma OBJ ou LIB para ser usada dentro dos nosso aplicativos.

Isto é possível ou estou fantasiando ???

Pense bem nessa idéia, você está realmente ajudando a TODOS que programamos em Clipper e de forma generosa e sem interesse financeiro. O que certamente, muita gente deve estar incomodada com isso.

Um grande abraço

:)Pos :{

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 09 Set 2006 04:58
por Maligno
Haveria possibilidade de colocar na fila de impressão do WINDOWS um arquivo ?. Talvez utilizando o SIMPLEX do BCC ++?.

SIMPLEX??? Não conheço. Que ser isso?
Mas é sempre possível colocar um arquivo qualquer na fila de impressão do Windows. Vou pesquisar.

Pois assim que trabalha o aplicativo USB apresentado pelo Heveraldo que é compilado com BCC++ e xHarbour em modo TEXTO, ele utiliza uma técnica que muito simples, de colocar o arquivo de impressão na fila de impressão do proprio WINDOWS.

Pra você me pedir uma coisa dessas, imagino que você tenha percebido o mesmo problema que eu percebo: o tamanho do EXE. Em XHarbour esse programa deve ter ficado bem maior que o WAPI. Nunca vi o programa, mas funciona bem, não?

Aí pensei... , o seu aplicativo WAPI, está ficando muito bom com todas estas implementações e ainda melhor se você pudesse disponibiliza-lo em uma OBJ ou LIB para ser usada dentro dos nosso aplicativos.

Isto é possível ou estou fantasiando ???

Possível não é. Pelo menos da forma tradicional, quando você inclui um objeto qualquer no seu script de encadeamento. Mas, por outro lado, é possível embutir o arquivo WAPI.EXE dentro do programa clipper, por meio de um objeto. Uma vez que o arquivo WAPI.EXE é bem pequeno, isso é fácil de fazer.
O esquema funciona assim: você converte o arquivo, através de uma técnica especial, em um conjunto de dados binários; cria um objeto com isso e, por meio de uma função especial, extrai o conteúdo original para um arquivo com o mesmo nome ou outro nome qualquer. Se você tiver funções que abstraiam esse trabalho, de rápido que é, dará a impressão de que é uma função Clipper autêntica.
Esse esquema eu tenho pronto e está funcional. Veja na minha página. Procure na tabela de cor salmão pelo título "Resources no Clipper". Vai precisar de um compilador Assembly. Tem lá também.

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

SIMPLEX

MensagemEnviado: 09 Set 2006 09:26
por Pablo César
Eu tinha visto algo na WEB sobre um método algoritmo:

http://www.mat.ua.pt/io/Documentos/Acet ... /frame.htm

O SIMPLEX refere-se a forma que é compilado no xHarbour fazendo omissão realizada no "hbapi.h", com SET HB_LEX=SIMPLEX. Mas de todas formas, eu não conheço a fundo este tema, ora porque refere-se ao xHarbour e não está aqui essa questão.

Desculpe MALIGNO pela minha dedução precipitada. Você tinha me explicado da função MULTIFLEX em ASSEMBLY e como ví a compilação do xHarbour com SIMPLEX, pensei que fosse alguma função que fazia parte do BCC++.

Maligno escreveu:Mas é sempre possível colocar um arquivo qualquer na fila de impressão do Windows. Vou pesquisar.


OBA ! Esperamos que você consiga, caro colega ! Boa sorte !

:)Pos :|<

Re: SIMPLEX

MensagemEnviado: 10 Set 2006 10:57
por Maligno
Mais duas inclusões no aplicativo WAPI: reprodução de sons wave provenientes de arquivos wave ou de eventos do sistema, configurados pelo Painel de Controle (Sons). E por fim, a impressão de arquivos. Aliás, o enfileiramento do conteúdo de um arquivo no spooler de impressão do Windows. Não testei muito bem. Quase nem uso impressora e a minha não está lá essas coisas. Além do que, não é USB. Mas, acredito que a impressão funcionará perfeitamente em qualquer tipo de impressora, inclusive remota.
Mas é bom lembrar que, como é coisa nova, algumas alterações poderão ser feitas, como a inclusão de um argumento no MEIO dos demais, informando, por exemplo, uma certa quantidade de cópias a imprimir. Logo, a lista de argumentos poderá mudar.

E uma alteração: os argumentos de switches, quando houver mais de um, deverão ser separados por ponto-e-vírgula.

A relação atualizada dos switches:
---------------------------------------------------------
    -REBOOT
    -POWEROFF
    -HIBERNATE
    -SUSPEND
    -FLASH:<times[;handle>]
    -PLAYSOUND:<source>
    -SETTASKBAR:<HIDE|SHOW>
    -GETAPPINFO:<filename>
    -SETAPPTITLE:<title>
    -SETBUTTONX:<ON|OFF|DEL>
    -PRINT:<printerName;inputFile;reportTitle;resultFile>

Os detalhes de cada switch podem ser obtidos do arquivo fonte. Detalhe: WAPI agora tem um arquivo de cabeçalho com algumas constantes que poderão ser utilizadas no Clipper. São mensagens de erros e os identificadores de sons fixos dos eventos do Windows.

Futuro:
No decorrer desta semana vou fazer o switch para obter a lista de impressoras instaladas no Windows e, atendendo o pedido de um amigo, um mecânismo para ler e escrever no Registry do Windows.
Vou também montar uma LIB para embutir o WAPI no Clipper, para que não seja necessário mais nada, além do programa Clipper.
Tudo isso, claro, quando o tempo permitir. :)

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

MensagemEnviado: 10 Set 2006 19:08
por Maligno
Agora são dois arquivos, mas o de demos ainda não contém uma demonstração do switch de impressão.

http://buzinello.com/download/wapi.zip
http://buzinello.com/download/wapi_demos.zip (contém os EXE prontos)

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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 11 Set 2006 08:14
por Pablo César
LEGAL MALIGNO !!!!

Pooohhh fiquei muito contente, com mais essas implementações. Pena que ahora tenho que sair, mas irei testar logo que eu voltar (tou animadissimo !). Será que a questão de colocar som através do WAPI, irá funcionar em background ? E será que pode ser interrompido a reprodução do som em andamento ?. Porque se ele funcionasse em background iria ser possível rodar o nosso aplicativo sem ser afetado pelo som.

Mas a questão da impressão através do WAPI, abre sem dúvidas uma possibilidade de impressão nos programas feito em CLIPPER, em USB, LEXMARK, sinal de fumaça (como disse o nosso colega... hehe). Poooh estou muito contente e realmente muito agradecido MALIGNO, pela sua contribuição, você é um GENIO ! Legal, mesmo. Algum dia, terei o prazer de conhecé-lo pessoalmente, ja que moramos no mesmo estado.

Obrigado MALIGNO, mais uma vez, a nossa comunidade agradece com muito respeito e reconhecimento.

Um clip-abraço, colega. :{

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 11 Set 2006 10:29
por Maligno
Será que a questão de colocar som através do WAPI, irá funcionar em background ? E será que pode ser interrompido a reprodução do som em andamento ?.

A função de reprodução de som, sabe-se lá porque, só funciona no modo síncrono. É um mistério. Vou pesquisar mais um pouco depois. Acho que deve ter solução pra isso.

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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 11 Set 2006 11:05
por Pablo César
Caro MALIGNO,

Gostei muito da nova opção PRINT, e funcina muito bem. Agora irei pra casa de uma amiga onde tem impressora USB em XP. Mas aparentemente, sem nenhum inconveniente. Inclusive testei da seguinte forma:

WAPI -PRINT:"Epson LX-810";CLIENTES.PRN;"Listagem de clientes";RESULTA.TXT

O 1º parametro "Epson LX-810", está conforme descrito no WIN.INI, ja no meu sistema eu leio este nome que foi dado pelo WINDOWS. Mas como você disse, irá impementar mais uma opção para que crie em arquivo os nomes das impressoras que estão cadastradas. Isso será também de grande ajuda.

WAPI -PRINT:LPT1;CLIENTES.PRN;"Listagem de clientes";RESULTA.TXT

Nesta opção também funcionou sem problemas.

Porém se ficar faltando algum parametro, não imprime (é claro). Mesmo que nao queira passar o 4º parametro (criação de arquivo de resultado de impressão).

Quanto a questão do switch PLAYSOUND, ele não está funcionando em background. Bom seria que funcionasse para que não ficasse o sistema travado (em espera de final de execução).

Testei também o switch FLASH e funciona também OK.

Por enquanto, a questão do switch SETAPPTITLE e do status da janela DOS, aguardo anciosamente.

Obrigado, mais uma vez MALIGNO.
:)Pos :{ -:]

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 17 Set 2006 14:18
por Maligno
Recapitulando:

-FLASH:<times[;handle>]
-GETAPPINFO:<filename>
-GETDEFPRINTER:<fileName>
-GETHDINFO:<fileName>
-GETPRINTERS:<fileName>
-HIBERNATE
-MYHANDLE:<filename>
-PLAYSOUND:<source>
-POWEROFF
-PRINT:<printerName>;<inputFile>;<reportTitle>;<resultFile>
-REBOOT
-SETAPPTITLE:<title>
-SETBUTTONX:<ON|OFF|DEL>
-SETTASKBAR:<HIDE|SHOW>
-SUSPEND


Nem vou explicar muita coisa, pois os detalhes estão no fonte. Só quero observar alguns detalhes:

1) -PRINT agora imprime para a impressora "default". É só trocar o nome por #.

2) Pois agora também há um switch para descobrir qual é a impressora default: -GETDEFPRINTER. Também vou alterar -GETPRINTER para indicar na lista de impressoras, qual é a default. Mas fica pra semana que vem.

3) Quando não quiser gerar algum arquivo de resultado, basta informar NUL como o nome do arquivo, em qualquer switch. Não só no de impressão.

4) Adicionei -GETHDINFO. Talvez alguém se lembre que eu tenho um outro utilitário, chamado HDI, que fornece dados sobre o modêlo, número de série (de fábrica) e versão do HD instalado como o principal da máquina. Esse switch faz a mesma coisa, mas evita o uso de um outro utilitário só pra isso.

5) -SETAPPTITLE está de rosca. Pesquisei por toda a Net e nada de resolver isso. Mas se eu não resolver pelo WAPI diretamente, já sei como resolver pela LIB que vou fazer. De qualquer forma, sem solução não ficará.

6) -PLAYSOUND continua no modo síncrono. Mas eu troquei um switch de compilação e tornei o WAPI um programa GUI sem janela. Assim, sua instância morre quando terminar a música, liberando o programa DOS de imediato.

7) -MYHANDLE retorna o handle da janela da instância do WAPI. Eu fiz só pra teste, mas mantive no fonte.

8) Esqueci de dizer, e só depois que me dei conta que não é tão óbvio: o WAPI pode executar vários comandos na mesma linha de comando. Exemplo:

wapi -FLASH:3 -PRINT:#;wapi.c;"WAPI source code";NUL -FLASH:3 -PLAYSOUND:dance.wav


Isso fará a janela do DOS piscar três vezes, imprimirá o fonte do WAPI na impressora default e sem criar um arquivo de resultado, piscará mais três vezes e, finalmente, tocará uma música.

---

O esquema de ler/gravar no registry do Windows ainda não ficou pronto, mas no decorrer desta semana eu faço, juntamente com uma biblioteca Clipper com funções de embutimento do WAPI e abastração de todos os comandos, para facilitar o uso.

Uma lembrança: o WAPI não está totalmente pronto. Assim, é bem possível que alguns switches sofram mudanças em parâmetros e/ou arquivos de resultados tenham suas estruturas modificadas. Portanto, pra botar em uso final, é melhor esperar que eu faça a LIB dele. Daí sim, nada será alterado de forma que exija uma reestruturação do seu programa. Com as funções de abstração, tudo ficará mais fácil ainda.

Outra coisa: esta semana foi bem tumultuada pra mim. Não tive muito tempo de testar tudo com o rigor que eu gostaria. Assim, bugs podem existir. Daí é só dizer. :)

Os links:
http://buzinello.com/download/wapi.zip
http://buzinello.com/download/wapi_demos.zip


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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 18 Set 2006 10:41
por Pablo César
Caro colega MALIGNO,

Vão ser muito úteis essas implementações novas no WAPI.
Testei o WAPI com os swtiches e veja meus comentários:

-GETDEFPRINTER, funciona OK. Mas sugiro que este resultado seja incluso no switch GETPRINTERS, apenas mostrando com um asterisco na frente do nome da impressora indicando que essa é a "Padrão" para não ter que utilizar dois switches para ver as impressoras.
-GETHDINFO, que bom esta opção também, pois eu não tinha se me ocorrido, mas é muito importante, para ser utilizado para proteção de uso do software. Se bem que você mencionou de fazer uma outra opção de gravar no REGISTRO do WINDOWS e que em conjunto a esta nova opção poderia ser útil na instalação dos sistema feito em Clipper. Você teria alguma sugestão para este caso de REGISTRO no WINDOWS o quê poderia ser gravado ?.

Os switches GETHDINFO e MYHANDLE e me deram como resultado no arquivo apenas o valor: -53, é dizer não funcionou com o meu WIN98 (também não sei dizer se é por causa disto).

Você faz referência ao ler os arquivo WAPI.h para tratar dos resultados, mas onde estariam disponíveis para download os arquivos de diretrizes que é mencionado no seu arquivo WAPI.C ?

O switch PLAYSOUND, está melhor que antes porque ele carrega na memória o conteúdo a ser tocado e libera em poucos segundos ao menos.

Sobre a questão da tela do DOS em modo "JANELADO" ou "INTEIRA", também seria uma questão a ser resolvida.

Realmente toda esta contribuição dada por você será lembrada por todos que programam em linguagem DOS e que não possuem esses recursos.

É incrível ver que muitos dos nossos colegas que fizeram tantas declarações sobre seus conhecimentos, nenhum deles tenha tido a capacidade de elaborar (vamos dizer: uma futura LIB) que desmistifique muitas das limitações em que o Clipper se encontra. Eu sou grato MALIGNO e acho que TODOS nós devemos reconhecer seu conhecimento técnico, sua dedicação e seu companheirismo conosco. Obrigado, mais uma vez.

Um clip-abraço :)Pos :)) :{ :xau

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 18 Set 2006 11:52
por Maligno
-GETDEFPRINTER, funciona OK. Mas sugiro que este resultado seja incluso no switch GETPRINTERS, apenas mostrando com um asterisco na frente do nome da impressora indicando que essa é a "Padrão" para não ter que utilizar dois switches para ver as impressoras.

No meu post anterior comentei que era exatamente isso o que iria fazer. :)

-GETHDINFO, que bom esta opção também, pois eu não tinha se me ocorrido, mas é muito importante, para ser utilizado para proteção de uso do software. Se bem que você mencionou de fazer uma outra opção de gravar no REGISTRO do WINDOWS e que em conjunto a esta nova opção poderia ser útil na instalação dos sistema feito em Clipper. Você teria alguma sugestão para este caso de REGISTRO no WINDOWS o quê poderia ser gravado ?.

Uma infinidade de coisas. Vamos fazer assim. Deixa eu terminar o acesso ao Registry. Depois você abre um novo tópico apenas sobre essa questão. Assim, não estaríamos discutindo agora sobre aquilo que ainda é vaporware. :)

Os switches GETHDINFO e MYHANDLE e me deram como resultado no arquivo apenas o valor: -53, é dizer não funcionou com o meu WIN98 (também não sei dizer se é por causa disto).

Pra usar o -GETHDINFO você precisa de três coisas: HD que tenha SMART, BIOS com SMART habilitado e driver no SO para recuperar informações do HD. Para esse último caso, e no win98, há um driver: SMARTVSD.VxD, que deve(ria) residir no diretório \WINDOWS\IOSUBSYS. Eu estive testando esse recurso, mas usando uma VM win98 pelo VMWare. Não funcionou, mas também não corri muito atrás, por falta de tempo. No XP funciona muito bem, desde que os dois primeiros requisitos sejam satisfeitos, claro.

Você faz referência ao ler os arquivo WAPI.h para tratar dos resultados, mas onde estariam disponíveis para download os arquivos de diretrizes que é mencionado no seu arquivo WAPI.C ?

Você não me entendeu. Eu disse que você pode incluir no seu programa Clipper o arquivo WAPI.H, pois este possui as constantes que o programa usa. Esse arquivo evitará que você tenha que manipular números diretamente. É isso.

Sobre a questão da tela do DOS em modo "JANELADO" ou "INTEIRA", também seria uma questão a ser resolvida.

Ainda não pude ver nada relacionado a isso. Mas não esqueci. :)

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

WAPI.H

MensagemEnviado: 18 Set 2006 13:55
por Pablo César
OK, Maligno. Desculpe a minha ansiedade, pareceria que estou te cobrando como se eu tivesse direito.

Porém a inclusão do WAPI.H, desculpe mas não entendí ainda. Como eu poderia fazer um include se não possuo o WAPI.H para ver os resultados dos códigos. Veja que esse arquivo não está incluso no ZIP que você disponibiliza pra nós. Poderia me explicar melhor, por favor ?.

sds

Re: WAPI.H

MensagemEnviado: 18 Set 2006 16:09
por Maligno
Opa! Me desculpe. Falha minha. Eu esqueci de incluir os arquivos H. Já corrigi e subi o pacote de novo. :)

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

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 18 Set 2006 16:10
por MARINI
Maligno escreveu:2) Pois agora também há um switch para descobrir qual é a impressora default: -GETDEFPRINTER. Também vou alterar -GETPRINTER para indicar na lista de impressoras, qual é a default. Mas fica pra semana que vem.


Beleza Maligno pela sua colaboração.
Estava estudando isto e reparei que se:

wapi -GETAPPINFO:TESTE.TXT

cria o arquivo TESTE.TXT com as informações, mas

wapi -GETPRINTERS:TESTE.TXT e
wapi -GETDEFPRINTER:TESTE.TXT não cria nada.

Sabe me dizer o motivo?

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 18 Set 2006 19:18
por Pablo César
MARINI escreveu:wapi -GETPRINTERS:TESTE.TXT e
wapi -GETDEFPRINTER:TESTE.TXT não cria nada. Sabe me dizer o motivo?


Qual é a sua versão do WINDOWS ?. No meu WIN98, essas duas switches, funcionou perfeitamente.

Mas de todos modos, vale a pena esperar o colega MALIGNO finalizar esta questão porque ele tem intenções de unificá-las num só switch.

Viu, MARINI que legal ?. Até que enfim alguem se manifestou !!!.
Parece que muitos estão preocupados em querer se sobre-sair dos outros com aquele tópico que só ficam desmerecendo o nosso CLIPPER.

E a criação do WAPI sem dúvidas é uma das melhores CONTRIBUIÇÕES ao CLIPPER que surgiu neste FORUM. Como gostaria que os outros colegas que dissem que sabem outras linguagens, possam algum dia ajudar ao pobre CLIPPER.

Um CLIP-ABRAÇO
:)Pos

Re: WAPI.H

MensagemEnviado: 18 Set 2006 19:51
por Pablo César
Maligno escreveu:Opa! Me desculpe. Falha minha. Eu esqueci de incluir os arquivos H. Já corrigi e subi o pacote de novo.


OK, MALIGNO, não dá para ficar bravo contigo... Mais agora, ja pensou se você fica bravo, hehe (uma brincadeirinha, tá ?). Mas voltando ao assunto por exemplo do switch PLAYSOUND, está dando erro com a seguinte sintaxe:

WAPI -SOUNDPLAY:1

Teoricamente, era para tocar o primeiro evento do meu WIN98 (inclusive está definido esse evento). E está dando o seguinte erro, seja com 1,2,3, etc...:

WAPI causou uma falha de página inválida no
módulo WINMM.DLL em 0197:bfdf8a4b.


E inclusive toca sempre o mesmo som do evento de iniciar o Windows.

Será que o meu WINDOWS está dando pau ?. Alguem mais poderia testar pra nós ?

Um clip-abraço :(

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 19 Set 2006 00:55
por Maligno
MARINI escreveu:wapi -GETPRINTERS:TESTE.TXT e
wapi -GETDEFPRINTER:TESTE.TXT não cria nada.

Sabe me dizer o motivo?

Realmente não. Já testei com XP e acabei de testar (de novo) com o Win98 (máquina virtual) e funcionou sem problemas. Mais pra frente vou testar com Win95 (também virtual). Acredito que vá funcionar.
Sem querer ser chato, mas tem certeza de que emitiu o comando corretamente? É a única forma que imagino que poderia fazer dar errado. Às vezes eu mesmo esqueço do hífen ou do dois-pontos.

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

Re: WAPI.H

MensagemEnviado: 19 Set 2006 01:00
por Maligno
Pablo César escreveu:WAPI -SOUNDPLAY:1

Teoricamente, era para tocar o primeiro evento do meu WIN98 (inclusive está definido esse evento). E está dando o seguinte erro, seja com 1,2,3, etc...:

WAPI causou uma falha de página inválida no
módulo WINMM.DLL em 0197:bfdf8a4b.


E inclusive toca sempre o mesmo som do evento de iniciar o Windows.

Os eventos de som devem estar configurados no Painel de Controle. Se não estiverem configurados, não sai som algum. :)
Pena que no meu Win98 (virtual) não consegui instalar minha placa de som. Mas deve funcionar. Vou testar num Win98 real. Mas acredito que não tem problema algum.

Será que o meu WINDOWS está dando pau ?. Alguem mais poderia testar pra nós ?

Quanto a este erro, infelizmente, acho que seu Windows está com pau.
Mas antes de reinstalar, vou te mandar por eMail o WINMM.DLL do meu Win98. Substitua-o e tente de novo. Se ainda assim der esse erro, não há muito o que fazer, a não ser reinstalar. Aliás, quando eu usava Win98, periodicamente tinha que reinstalar por cima dele, sem formatar. Só isso já resolvia os problemas.

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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 19 Set 2006 07:42
por Pablo César
Maligno escreveu:Sem querer ser chato, mas tem certeza de que emitiu o comando corretamente? É a única forma que imagino que poderia fazer dar errado. Às vezes eu mesmo esqueço do hífen ou do dois-pontos.
Eu também sem querer substimar ao colega MARINI, mas outra causa poderia ser também a falta de impressora cadastrada no WINDOWS ?.

sds

Re: WAPI.H

MensagemEnviado: 20 Set 2006 00:51
por Maligno
Pablo César escreveu:WAPI -SOUNDPLAY:1

Teoricamente, era para tocar o primeiro evento do meu WIN98 (inclusive está definido esse evento). E está dando o seguinte erro, seja com 1,2,3, etc...:

WAPI causou uma falha de página inválida no
módulo WINMM.DLL em 0197:bfdf8a4b.

Falei cedo demais. :)
Consegui configurar minha placa de som no meu Windows 98 virtual e deu o mesmo problema que no seu Windows. Muito esquisito. Mas já foi resolvido. Troquei a forma de acesso aos eventos de sons e acho que ficou até melhor. Baixe o ZIP atualizado:

http://buzinello.com/download/wapi.zip

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

PLAYSOUND

MensagemEnviado: 20 Set 2006 07:46
por Pablo César
OK, agora sim !. Sem erro.

:)Pos

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 21 Set 2006 08:21
por MARINI
MARINI escreveu:wapi -GETPRINTERS:TESTE.TXT e
wapi -GETDEFPRINTER:TESTE.TXT não cria nada.

Sabe me dizer o motivo?


Agora, nesta nova versao está criando os arquivos de retorno.
Todavia, qualquer dos 2 comandos acima somente retorna a impressora padrão. Pelo que está anotado na pagina 2 o GETPRINTERS será alterado para informar todas as impressoras cadastradas.

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 21 Set 2006 09:52
por Maligno
MARINI escreveu:
wapi -GETPRINTERS:TESTE.TXT e
wapi -GETDEFPRINTER:TESTE.TXT não cria nada.

Sabe me dizer o motivo?


Agora, nesta nova versao está criando os arquivos de retorno.

Mas eu não alterei nada com relação a criação desses arquivos. Se bem que o que importa é que agora está funcionando. :)

Todavia, qualquer dos 2 comandos acima somente retorna a impressora padrão.

-GETPRINTERS: deveria listar todas as impressoras.

Pelo que está anotado na pagina 2 o GETPRINTERS será alterado para informar todas as impressoras cadastradas.

Já lista todas. A alteração era somente para informar qual delas é a default. O que, aliás, já está pronto. Só não subi ainda o ZIP novo.

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

WAPI - getprinters

MensagemEnviado: 21 Set 2006 10:01
por Pablo César
Engraçado MARINI, para mim funciona perfeitamente. Mas é claro, como disse o MALIGNO, só faltaria estar disponível pra nós a indicação de quais das impressoras é a "padrão" listada no arquivo criado.

Será que você não está matando o arquivo anteriorrmente criado ?? Qual é a versão do seu WINDOWS ?. Esperemos atualização do WAPI, baixe-lo e tete novamente. Porque em todas as versões do WAPI, ele funcionou.

sds -:]

Re: WAPI - getprinters

MensagemEnviado: 04 Out 2006 05:22
por Maligno
Primeiramente me desculpem pela demora em dar uma resposta às funções que ainda faltavam. Mas nos últimos dias fiquei muito preso a vários outros serviços. E quase não tive tempo pra trabalhar no WAPI, inclusive nos finais de semana.

Inclui agora as funções de leitura, escrita e apagamento no Registry do Windows. Uma nova lista dos switches que já temos, em ordem alfabética (com * nos novos):

*  -DELETEREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
   -FLASH:<times>[;<handle>]
   -GETAPPINFO:<resultFile>
   -GETDEFPRINTER:<resultFile>
   -GETHDINFO:<resultFile>
   -GETPRINTERS:<resultFile>
   -HIBERNATE
   -MYHANDLE:<resultFile>
   -PLAYSOUND:<source>
   -POWEROFF
   -PRINT:<printerName>;<inputFile>;<reportTitle>;<resultFile>
*  -READREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
   -REBOOT
   -SETAPPTITLE:<title>
   -SETBUTTONX:<ON|OFF|DEL>
   -SETTASKBAR:<HIDE|SHOW>
   -SUSPEND
*  -WRITEREGISTRY:<fullKeyPath>;<entryName>;<value>;
                  <valueType>;<resultFile>


Uma observação a respeito dos comandos do Registry: agora que lembrei que não comentei no fonte (depois eu atualizo) que fiz o WAPI trabalhar apenas com dois tipos básicos de dados: caractere e numérico, tanto para leitura quanto para escrita, a exceção, claro, do comando de apagamento, onde o tipo de dado não importa.

De resto, descobri que não há meio de resolver o problema do título das janelas nos Windows 9X/Me. Não pelo WAPI. Mas será resolvido pela LIB que vou montar a partir de agora. Por meio dela o WAPI será embutido no programa Clipper através dos resources que já fiz há um bom tempo. Mas ela será, principalmente, uma camada extra de código para abstrair e facilitar o uso desses comandos.

Link: http://buzinello.com/download/wapi.zip

Leia o fonte para conhecer os detalhes dos novos comandos.
Só pra lembrar: bug-reports e sugestões serão sempre bem-vindos. :)

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


PS: Junto a esta LIB, com o tempo, seguirão também as funções que escrevi ao longo dos anos. Todas prontas e testadas há muito tempo. Mas serão incluídas na LIB só após a documentação estar pronta. Ou seja, conforme o tempo permitir.

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 04 Out 2006 09:05
por Pablo César
Caro colega MALIGNO:

A.) O switch -MYHANDLE, ainda está retornando o código -53 (_ERROR_SMART_IDENTIFY).

1.) Este erro realmente pertenceria a esta opção ?. Visto que a função do switch -MYHANDLE é definida no código fonte como: "Cria e carrega arquivo (o conteúdo anterior será perdido) com o handle da janela atual"

2.) "Cria e carrega arquivo...", carrega o arquivo ? Para quê esta finalidade ?

B.) E o swicth -GETDEFPRINTER, não estaria redundante por existir na opção do outro switch -GETPRINTERS ?.

C.) Poderias detalhar a sua sintaxe de como poderia ser utilizado o WAPI.EXE para ser convertido em OBJ ou LIB, através do seu aplicativo "clprsrc1" ?

Obrigado, pelas suas contribuições e seguirei acompanhando este processo de elaboração do WAPI que está ficando muito BOM !. E abrirei um novo tópico, questionando a utilidade de gravação no REGISTRY do WINDOWS.

Ump clip-abraço ! :)Pos

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 06 Out 2006 05:46
por Maligno
A.) O switch -MYHANDLE, ainda está retornando o código -53 (_ERROR_SMART_IDENTIFY).

Certeza??? O switch -MYHANDLE não retorna código de erro. Retorna apenas o handle da janela atual, que é sempre um número positivo.

2.) "Cria e carrega arquivo...", carrega o arquivo ? Para quê esta finalidade ?

Para informar o número do handle da janela. Acho que você pode ter se confundido. Carregar não é um verbo ligado apenas à leitura, propriamente. Você pode criar o arquivo e carregá-lo com dados (inserir nele) que depois serão lidos.

B.) E o swicth -GETDEFPRINTER, não estaria redundante por existir na opção do outro switch -GETPRINTERS ?.

Sim e não. -GETPRINTERS dá a lista toda. Mas eu posso querer saber apenas qual é a impressora default. É uma opção a mais. Melhor sobrar do que faltar. :))

C.) Poderias detalhar a sua sintaxe de como poderia ser utilizado o WAPI.EXE para ser convertido em OBJ ou LIB, através do seu aplicativo "clprsrc1"?

Bom, eu acho que as instruções que constam no README do ZIP deveriam ser suficientes. O que exatamente você não entendeu?
Quanto ao WAPI você não precisa se preocupar. Eu vou embutí-lo na LIB que está sendo montada.

Obrigado, pelas suas contribuições e seguirei acompanhando este processo de elaboração do WAPI que está ficando muito BOM !. E abrirei um novo tópico, questionando a utilidade de gravação no REGISTRY do WINDOWS.

Já vi lá. Responderei algo. ;-)

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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 07 Out 2006 09:09
por Pablo César
Caro colega MALIGNO,

Respondendo as questões anteriores:

Certeza??? O switch -MYHANDLE não retorna código de erro.
Na verdade, neste swicth o WAPI no está escrevendo resultado algum no arquivo. Pelo menos isto acontece comigo no WIN98. O valor mencionado na minha postagem anterior de -53, era resultado de outro teste e pensei que o resultado do MYHANDLE iria sobrescrever o anterior.

Bom, eu acho que as instruções que constam no README do ZIP deveriam ser suficientes. O que exatamente você não entendeu?
Bem na verdade li e re-li o README.TXT, mas terei que executar passo a paaso para entender melhor. Ficam duas dúvidas entorno:

1.) Programas externos podem ser linkados juntamente com MEU_PROGRAMA_CLIPPER. Porém poderiam ser executados dentro do MEU_PROGRAMA_CLIPPER ?

2.) Se eu quisesse gerar um OBJ apartir do EXE, teria que converter primeiro em .ASM e depois compilar com TASM ?

Eu conseguí LINKAR MEU_PROGRAMA_CLIPPER (DEMO) com o MYTEST.OBJ que ja existia (não fui eu que gerei, ja estava no ZIP). Ficou fácil chegar ao resultado final, gerando novamente os arquivos .COM e o arquivo SUCESSO.TXT.

Quanto ao WAPI você não precisa se preocupar. Eu vou embutí-lo na LIB que está sendo montada.
Fico mais tranquilo, pois terei que executar passo a passo seguindo seu README.TXT. Mas como você mesmo menciona... para o programador de pouca (ou nenhum) fluência em Assembly, o processo todo poderá parecer um tanto intimidador

Mas claro que se a gente não mete as caras, nunca vamos saber se tem agua na piscina... hehe :)Pos

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 07 Out 2006 15:59
por Maligno
Na verdade, neste swicth o WAPI no está escrevendo resultado algum no arquivo.

Acabei de testar no meu Win98 virtual e funcionou perfeitamente. Será que vcê não poderia estar confundindo um arquivo com outro? Sabe como é: arquivo vai, arquivo vem. Eu mesmo já fiz muitas confusões com isso. :)

1.) Programas externos podem ser linkados juntamente com MEU_PROGRAMA_CLIPPER. Porém poderiam ser executados dentro do MEU_PROGRAMA_CLIPPER ?

Os programas externos não são linkados. Eles são transformados em um bloco fonte assembly, em valores hexa, compilados e embutidos no Clipper dentro de uma função.

2.) Se eu quisesse gerar um OBJ apartir do EXE, teria que converter primeiro em .ASM e depois compilar com TASM ?

Um objeto binário é um arquivo que contém o resultado da compilação de um arquivo fonte. Nele, além do código objeto, você terá também referências a símbolos externos (outras funções, variáveis, etc) que serão resolvidos em link-time, para depois serem ligados a outros arquivos objeto para, enfim, formarem um novo EXE. Exatamente por isso, você não pode gerar um objeto a partir de um executável. Não sei se entendi bem essa sua pergunta, mas descrevi como é que funciona.
Agora, se você está falando em como o "resources" funciona: o arquivo EXE é "convertido" em um fonte Assembly. O código binário puro é convertido em texto para esse fonte. O resultado, você "cola" no ponto que destaquei no fonte "padrão". Depois, é só rodar o TASM e pronto, você terá um objeto que poderá ser linkado junto com seu programa Clipper, da maneira como você sempre fez.

Eu conseguí LINKAR MEU_PROGRAMA_CLIPPER (DEMO) com o MYTEST.OBJ que ja existia (não fui eu que gerei, ja estava no ZIP). Ficou fácil chegar ao resultado final, gerando novamente os arquivos .COM e o arquivo SUCESSO.TXT.

Desculpe, mas não entendi o que tem a ver.

Fico mais tranquilo, pois terei que executar passo a passo seguindo seu README.TXT. Mas como você mesmo menciona... para o programador de pouca (ou nenhum) fluência em Assembly, o processo todo poderá parecer um tanto intimidador

Pelo menos no caso do WAPI eu vou fazer a LIB e você não terá de se preocupar. Mas poderá também utilizar o "resources" com quaisquer outros arquivos que quiser. No WAPI vai ficar fácil depois pra você desfrutar de seus benefícios:

PlaySound("SystemSart")   // reproduz o WAV da inicialização
aPrinters = GetPrinters() // recupera a lista de impressoras


Pra você vai funcionar assim. Não fica mais fácil? Pois é esse o principal benefício das funções de abstração. Com essa camada extra de código conseguimos tornar tudo muito mais simples e direto.

Mas claro que se a gente não mete as caras, nunca vamos saber se tem agua na piscina... hehe :)Pos

Isso é verdade. :))

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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 07 Out 2006 20:47
por Pablo César
Caro colega MALIGNO, lamentavelmente, não funciona comigo en puro WIN98. Você poderia dizer que pode ser a minha máquina, mas aqui eu tenho outra que está zeradinha com WIN98, recentemente instalado. E não funciona também, simplesmente não cria arquivo algum.

PlaySound("SystemSart")   // reproduz o WAV da inicialização
aPrinters = GetPrinters() // recupera a lista de impressoras


Puxa, já imaginei tudo isso graças a criação de uma LIB. Na verdade, espero que DEUS me dê a chance de poder ver o WAPI.LIB antes de morrer. Desculpe MALIGNO, isso não estou querendo dizer que você está demorando muito. Ora porque estou super-ancioso para ver outros resultados, como o nome (titulo) da janela ativa, ver se a aplicação está rodando em modo janelado ou janela inteira (seria outro GRANDE PARADIGMA, resolvido no CLIPPER).

Mas estou depositando muita fé em seu projeto e fico muito agradecido MALIGNO. Pena que o pessoal, anda com poucas idéias ultimamente. Mas com certeza lembrarão de você até o CLIPPER acabar...

Um clip-abraço
:)Pos :{ :xau

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 08 Out 2006 02:59
por Maligno
Caro colega MALIGNO, lamentavelmente, não funciona comigo en puro WIN98. Você poderia dizer que pode ser a minha máquina, mas aqui eu tenho outra que está zeradinha com WIN98, recentemente instalado. E não funciona também, simplesmente não cria arquivo algum.

Desculpe, mas você me obriga a fazer a pergunta padrão: tem certeza de que emitiu o comando corretamente? Se der erro em algum argumento, o WAPI não informa nada.
Eu faço essa pergunta porque logo que vi sua mensagem, abri meu Win98 virtual e testei. Funcionou certinho. E eu uso o VMware, que emula o Windows 98 muito bem. Amanhã vou testar num HD que tenho encostado aqui, que está com o Windows 98 SE.

PlaySound("SystemSart")   // reproduz o WAV da inicialização
aPrinters = GetPrinters() // recupera a lista de impressoras


Puxa, já imaginei tudo isso graças a criação de uma LIB.

Essas duas funções já existem. Acabei de fazer. Ficou muito legal. Simples, rápido e invisível. Funciona de um jeito que até dá a impressão de que foi feito em Clipper mesmo.

Na verdade, espero que DEUS me dê a chance de poder ver o WAPI.LIB antes de morrer. Desculpe MALIGNO, isso não estou querendo dizer que você está demorando muito.

Poxa! Ainda bem. :)))))))
Infelizmente o tempo anda escasso. A vida segue e a gente tem compromissos pra cumprir. Mas uma hora a gente chega lá.

Ora porque estou super-ancioso para ver outros resultados, como o nome (titulo) da janela ativa, ver se a aplicação está rodando em modo janelado ou janela inteira (seria outro GRANDE PARADIGMA, resolvido no CLIPPER).

O esquema do nome da janela, como eu disse, será resolvido pelo Clipper mesmo. Pelo WAPI não vai dar pé. O tempo que eu ainda poderia gastar atrás de literatura não compensa o esforço pra uma coisa que posso resolver de um modo alternativo.
Agora conseguir saber como está rodando a janela é uma coisa complicada. Acho que descobrir como fazer isso vai dar um trabalhão. Mas vamos ver. Às vezes posso estar enganado.

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

WAPI - MYHANDLE

MensagemEnviado: 08 Out 2006 13:12
por Pablo César
Já sei o que está errado no switch -MYHANDLE:nome_arquivo, na verdade o que está errado é a sintaxe descrita no seu código fonte que indicava fazer dessa forma. Porém verificando mais detalhadamente a função está sendo declara como GETMYHANDLE. Era essa a diferença, eu estava me guiando pela sintaxe descrita no inicio do seu código fonte, seria só questão de corregir no seu código-fonte. Testei em WIN98 e em WINXP, e funciona perfeitamente. Desculpe minha falta de atenção.

Sorry, -:]

Re: WAPI - MYHANDLE

MensagemEnviado: 08 Out 2006 13:47
por Maligno
Eta! E você ainda tinha postado como escreveu na linha de comando. Nem reparei nisso, senão já o teria alertado. :)
Você que me desculpe pela falha no help. Passou batido. :)

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

Re: WAPI - MYHANDLE

MensagemEnviado: 09 Out 2006 04:32
por Maligno
Já sei o que está errado no switch -MYHANDLE:nome_arquivo

Você veja como são as coisas. Como eu tinha dito, fui colocar meu HD velho na máquina, pra rodar o Win98SE real. Não é que eu testei do mesmo jeito errado que você? Acho que é cansaço. :))
Aí fui "consertar" o bug. Nada de nada. Depois vi que estava usando o comando de forma errada. Mas aí descobri um bug de verdade no switch -GETAPPINFO. E consertei.
Moral da história: fui tentar matar um passarinho, acabei matando um urubu. :)))))

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

Waitng for your WAPI

MensagemEnviado: 16 Out 2006 18:20
por Pablo César
Caro colega MALIGNO,

Nem precisa a gente pedir desculpas, ora porque nós sabemos bem como é fazer softwares.

Mas não tou escrevendo por causa disso, e por... tou com saudades... :( :'( , sei que vai me dizer. Eu também estou saturado. Mas essa LIB que estás criando, será um SUCESSO !. E sempre tou entrando pra ver novidades quanto ao WAPI.

Espero que o amigo esteja bem.

Um clip-abraço
:)Pos

Re: Waitng for your WAPI

MensagemEnviado: 17 Out 2006 05:04
por Maligno
Mas não tou escrevendo por causa disso, e por... tou com saudades...

:)))))
Tudo bem. Eu entendo. São as expectativas quanto à LIB.
O chato da história é que minha máquina deu pau no sábado e só na segunda consegui descobrir o problema. Placa de vídeo. Troquei e estou desde ontem de manhã reinstalando tudo. Ou seja: tudo o que poderia ter feito no final de semana não foi feito. Fiquei completamente travado. Minha vida volta ao normal só na terça à tarde, com todo meu serviço atrasado. :((
São 6 da manhã quando escrevo esta mensagem. Estou há umas 20 horas mexendo na máquina. Quer carma!!! :)
Mas vou tentar entregar alguma coisa amanhã. E também pro Marchiore. Disse pra ele que ia mexer no código de comunicação IPX que me mandou. Parei tudo. :(
Aliás, fiz mais um switch: -SETSTARTBUTTON, para tornar invisível o botão "Iniciar" do Windows. Testado no XP e 98.

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

MensagemEnviado: 17 Jan 2007 12:28
por Maligno
Depois de longo tempo com diversos problemas (máquina, (MUITO) trabalho, família, etc), finalmente tenho a biblioteca WAPI.LIB pronta. As funções de abstração (e apoio) estão listadas abaixo. O pacote WAPI.ZIP já se encontra na minha área de download. Ele contém um arquivo README.TXT que descreve as funções com mais detalhes. Leitura obrigatória para quem for utlizar esta biblioteca.

WAPI.LIB v1
--------------------------------------------------------------------
AppOrigin() -> character
DeleteWReg(<cKeyPath>,<cEntry>) -> logic
DirOrigin() -> string
ExistFPath(cPath) -> logic
FlashTBar(<nTimes>,[<nWHandle]>) -> nil
GetAppsInfo() -> array
GetDefPrinter() -> array
GetHDInfo() -> array
GetMyHandle() -> numeric
GetPrinters() -> array
HibernatPC() -> nil
MakeFPath(<cPath>) -> numeric
PlayWave(<cSource>)
PowerOffPC() -> nil
PrintFile(<cPrtName>,<cRptFile>,[<cRptTitle>]) -> logic
RandNum() -> numeric
ReadRetFile(<cFile>,<cBuffer>) -> logic
ReadWReg((<cKeyPath>,<cEntry>) -> array
RebootPC() -> nil
RetMax(<x1>,<x2>) -> (character | numeric | array)
RetMin(<x1>,<x2>) -> (character | numeric | array)
RunWAPICmd(<cCommand>) -> logic
SetAppTitle(<cTitle>,[<nHandle>]) -> nil
SetButtonX(<nCond>) -> nil
SetStartBt(<nCond>) -> nil
SetTaskBut(<nCond>,[<nHandle>]) -> nil
SuspendPC() -> nil
ThisPath() > string
UniqFName(<cPath>,[<cPrefix>],[<cExtens>],[<lAddPath>]) -> character
WAPIError(<nErrorCode>) -> numeric
WAPIExeDir(<cNew>) -> character
WAPITimeOut(<nNew>) -> numeric
WAPITmpDir(<cNew>) -> character
WriteWReg(<cKeyPath>,<cEntry>,<cDataType>,<xData>) -> logic
--------------------------------------------------------------------

Todas as funções foram testadas no Windows XP, e quase todas numa máquina virtual Windows 98. Acredito que esteja tudo funcionando perfeitamente. Mas, na eventualidade de alguém encontrar algum bug, basta informar por eMail.
Fico devendo, por enquanto, um bom programa de demonstração. Farei conforme o tempo permitir.

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

Re: Waitng for your WAPI

MensagemEnviado: 18 Jan 2007 03:41
por Stanis Luksys
Maligno escreveu:Aliás, fiz mais um switch: -SETSTARTBUTTON, para tornar invisível o botão "Iniciar" do Windows. Testado no XP e 98.


Maligno, sabe me dizer se ocultando o botão desabilita a tecla winkey?

Eu fiz uns testes (com a API em conjunto com funções da MiniGUI) para esconder e para desabilitar, funciona beleza, mas como é engraçado ver o menuzinho subindo sem existir botão... E pior que o que eu procurava era justamente desdabilitar a tecla e não necessariamente o botão.

Se você souber de alguma coisinha da API (do registro não serve pq precisa fazer logoff) que desabilita a maldita, não pra sempre né, mas enquanto o programa roda, por favor da um alô aí...

Mas num esquenta a cabeça não... não tem pressa isso.

Boa sorte com a nova placa e vamos trabalhar! hehe

Valeu!

Re: Waitng for your WAPI

MensagemEnviado: 18 Jan 2007 09:20
por Maligno
Maligno, sabe me dizer se ocultando o botão desabilita a tecla winkey?

Não, a função continua disponível. Para desabilitá-la de vez, é necessário manter um hook no teclado, através de uma DLL (uma limitação da API).
Vi a thread a respeito do WKeyKill. É aquilo lá mesmo. O ruim desse programa é que se a aplicação Clipper der pau, a tecla WinKey permanecerá bloqueada. Se você executá-la de novo, imagino que a WinKey será desabilitada, ao invés de habilitada. Ou seja, é feita a comutação de ON para OFF e OFF para ON. Estou certo?

Boa sorte com a nova placa e vamos trabalhar! hehe

Troquei dois capacitores e salvei a placa. Mas acabei trocando a máquina toda por um Pentium Dual. Agora sim. :)

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

MensagemEnviado: 18 Jan 2007 10:23
por Maligno
Maligno escreveu:finalmente tenho a biblioteca WAPI.LIB pronta. As funções de abstração (e apoio) estão listadas abaixo.

Esqueci de dizer que uma das melhorias mais significativas foi ter colocado o utilitário WAPI.EXE dentro do programa Clipper, através da minha função de embutimento. Isso torna desnecessário distribuir o programa como um arquivo à parte. E o acesso a ele, além de transparente, é muito rápido, pois é um programa bem pequeno.

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

WAPI.LIB

MensagemEnviado: 19 Jan 2007 06:58
por Pablo César
Bem vindo caro colega Paulo !!!

Depois de três longos meses !. Pena que nestes semanas estarei meio que de férias e não estou tendo a oportunidade de testar a nova biblioteca. Porém tenho feito testes (em Win 98 e Win XP) em dois argumentos e tenho algumas indagações, baseado nos resultados obtidos sob o Win98.

1. Sei que na sua documentação menciona de poder fazer alteração opcional para o uso do BLINKER/RTLINK. Em muitos dos meus programas, ainda uso o RTLINK. Haveria como fazer com que faça o reconhecimento interno na propria LIB ?.

2. Compilei em 5.3 e com Blinker os PRGs APPSINFO e APPTITLE (da pasta APP). Ao rodar tais funções no WINXP não há demora na execução, mas em WIN98 fica lento a sua execução (de 3 a 4 segundos). E o engraçado que notei algo muito interessante. Quando copiei os executáveis APPSINFO e APPTITLE para uma outra pasta onde já continha o antigo WAPI.EXE (aquele de versão anterior), os programas não davam o resultado algum.

3. No arquivo APPTITLE.prg falta indicar o #Include "wapi.h" porque acusa o uso do KARGS_SEP e outras definições contidas no wapi.h.

4. O APPTITLE, funcionou muito bem no WINXP mas no WIN98, não funciona corretamente. O que tenho notado, que diferentemente ao da função OL_95VMTITLE() da OSLIB.LIB (lembrando um pouco da minha msg anterior), o APPTITLE modifica somente o nome do processo e não muda no arquivo-de-atalho, onde se encontra a descrição/nome da janela. E notei que no WIN98, que após de atribuir ao processo o novo TITULO, TAMBÉM abre um novo processo com o novo TITULO. Esse novo processo e inclusive não pode ser finalizado. Tudo isto foi observado através do gerenciador de tarefas do proprio Windows.

Lembrando um pouco de outras necessidades para sua preciosa contribuição. Duas funções que estariam pendentes e que ja foram solicitadas anteriormente. Só para constar:

a.) Uma função que detecte se o sistema atual está sendo executado no modo TEXTO ou JANELADO.
b.) Você tem mencionado que iria incluir também uma função que indique qual é o WINDOWS utilizado. Sei que existe o COMANDO "VER" do proprio WINDOWS, para quando rodo este comando externo no WINXP, ele não me dá a verdadeira versão. Deve-se isto porque o WINXP emula o MS-DOS.

Quero também deixar em claro, que eu reconheço muito bem Paulo, sua grandiosa contribuição e fico muito, mas muito agradecido pela sua contribuição. Sei que aqui no FORUM muitos se desprendem dos seus direitos e aportam com muito entusiasmo valiosas idéias. E que tudo o que estou indicando, não é para criticar porque me ache no direito de faze-lo. Faço para que possamos abrir um debate desta valiosíssima biblioteca e voce Paulo não é obrigado a nada. pode ser visto claramente, que você está colocando a disposição de TODOS com seu código e documentação, de forma clara e livre. Também agradeço que os exemplos aportados estão sendo usados pelo proprio recurso que o Clipper nos oferece.

Obrigado mais uma vez, prezado colega Paulo Buzinello (Maligno). O outro dia passaram o filme e não tem como não lembrar da personagem do MALIGNO e você Paulo. Parabéns e muito obrigado. E se você me permitir Paulo, continuarei fazendo algumas críticas/sugestões para que esta biblioteca fique EXCELENTE !.

Um clip-abraço,

Pablo :)) :{ :)Pos

MensagemEnviado: 19 Jan 2007 12:02
por Maligno
1. Sei que na sua documentação menciona de poder fazer alteração opcional para o uso do BLINKER/RTLINK. Em muitos dos meus programas, ainda uso o RTLINK. Haveria como fazer com que faça o reconhecimento interno na propria LIB ?.

Confesso que não havia pensado nisso. Talvez por quê já estou muito acostumado com o BLinker. Mas já resolvi. Alterei a função executora da linha de comando para tentar utilizar a função SwpRunCmd(). Se ela não existir, o comando será automaticamente executado através do RUN. Só que se for utilizado outro linker, será observada uma mensagem de erro pelo símbolo indefinido. Mas é só ignorar.

2. Compilei em 5.3 e com Blinker os PRGs APPSINFO e APPTITLE (da pasta APP). Ao rodar tais funções no WINXP não há demora na execução, mas em WIN98 fica lento a sua execução (de 3 a 4 segundos). E o engraçado que notei algo muito interessante. Quando copiei os executáveis APPSINFO e APPTITLE para uma outra pasta onde já continha o antigo WAPI.EXE (aquele de versão anterior), os programas não davam o resultado algum.

Acabei de testar as duas funções numa máquina virtual Win98. A velocidade está normal, apesar de ainda haver o problema da troca de título no Win98.
Agora, quanto a não funcionar ao mover seus programas de teste, há uma explicação possível: o utilitário WAPI precisa ser extraído para algum diretório, caso ainda não exista uma cópia dele. Mas o diretório precisa existir num drive válido. Não seria isso?

3. No arquivo APPTITLE.prg falta indicar o #Include "wapi.h" porque acusa o uso do KARGS_SEP e outras definições contidas no wapi.h.

Falha nossa! :) Mas já resolvido.

4. O APPTITLE, funcionou muito bem no WINXP mas no WIN98, não funciona corretamente. O que tenho notado, que diferentemente ao da função OL_95VMTITLE() da OSLIB.LIB (lembrando um pouco da minha msg anterior), o APPTITLE modifica somente o nome do processo e não muda no arquivo-de-atalho, onde se encontra a descrição/nome da janela.

Essa nunca foi a idéia. A intenção é apenas e tão somente modificar o título da barra da janela. Nada será alterado no arquivo-de-atalho.

E notei que no WIN98, que após de atribuir ao processo o novo TITULO, TAMBÉM abre um novo processo com o novo TITULO. Esse novo processo e inclusive não pode ser finalizado. Tudo isto foi observado através do gerenciador de tarefas do proprio Windows.

Não pude ver isso. Meu gerenciador de tarefa da VM do Win98, quando executado, trava tudo. Mas se não abre outra janela à parte, tudo bem. Isso fica invisível mesmo. Agora, se esse outro processo não morre com a morte da janela DOS, aí pode ser um problema, pois se o programa for executado continuamente, poderia ser aberto um novo processo para cada execução, acumulando processos "lixo". Verifique se é isso o que ocorre. Mas, a princípio, não deveria. Até porque, o utilitário WAPI.EXE é transiente. Ele interpreta e executa o argumento da linha de comando e cai fora.

a.) Uma função que detecte se o sistema atual está sendo executado no modo TEXTO ou JANELADO.

Isso vai ser complicado de fazer. Pesquisei (um pouco, admito), mas ainda não encontrei uma luz.

b.) Você tem mencionado que iria incluir também uma função que indique qual é o WINDOWS utilizado. Sei que existe o COMANDO "VER" do proprio WINDOWS, para quando rodo este comando externo no WINXP, ele não me dá a verdadeira versão. Deve-se isto porque o WINXP emula o MS-DOS.

No meu XP, o comando VER solta: "Microsoft Windows XP [versão 5.1.2600]".

E se você me permitir Paulo, continuarei fazendo algumas críticas/sugestões para que esta biblioteca fique EXCELENTE !.

Toda crítica construtiva é sempre bem-vinda. Fique à vontade. :)

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

WAPI.LIB

MensagemEnviado: 19 Jan 2007 19:24
por Pablo César
Maligno escreveu:Acabei de testar as duas funções numa máquina virtual Win98. A velocidade está normal, apesar de ainda haver o problema da troca de título no Win98.


Deve ser isso, Paulo. A sua na verdade estaria emulando o Win98, sendo que todo seu gerenciamento de memória (o que proporciona maior agilidade nos processos) se dá pelo WINXP. Mas puramente em WIN98 tarda de 3 a 4 segundos, isto não é de morrer, mas não acontece o mesmo no WINXP que fica em menos de um segundo +/- (isto num PENTIUM 4, 2.6GB).

Maligno escreveu:Agora, quanto a não funcionar ao mover seus programas de teste, há uma explicação possível: o utilitário WAPI precisa ser extraído para algum diretório, caso ainda não exista uma cópia dele. Mas o diretório precisa existir num drive válido. Não seria isso?


Não. Nãe seria isso. Vou te explicar detalhadamente o ocorrrido.
Digamos que num diretório eu tenha uma outra versão do WAPI.EXE. Aquela ultima que você apresentou a três meses atrás(por exemplo), da qual você tinha apresentado a função SETAPPTITLE sem criar vetores. E depois copie o APPTITLE.EXE (programa originado pelo teu exemplo APPTITLE.PRG) e rodar ele nessa pasta. Não irá ter o resultado que deveria. Pois mesmo que na criação do executável tenha sido linkado o WAPI.LIB o programa irá interpretar primeiro o WAPI.EXE do diretório corrente. Então a solução é simplesmente deletar esse WAPI.EXE (que seria uma versão anterior) daí sim o programa funciona legal (mostrando o conteúdo dos vetores, digamos).

Maligno escreveu:Essa nunca foi a idéia. A intenção é apenas e tão somente modificar o título da barra da janela. Nada será alterado no arquivo-de-atalho.


Entendo que isso de mudar o arquivo-de-atalho, seria uma solução que pareceria "KAMIKASE", porém eu acho que este seria a segunda medida a ser tomada após mudar o nome do processo. Porque enquanto você muda o processo que está rodando e o usuário fecha e abre novamente, bye bye a mudança do título. Eu acho importante esta função, para que o usuário não modifique a descrição do atalho, pois com ela de forma FIXA (com nome imutável, vamos dizer), eu poderei identificar se aquela determinada sessão de nome TAL está ativa ou não. Mas se o usuário fica troca de nome, ou até deletado o atalho (que isso´acontece) e cria um novo com decrição de nome "parecido", não conseguirei identificar se a janela está ativa ou não. Isto seria uma medida radical, para forçar o nome da janela e depois verificar se a janela está aberta outra vez, isto é para evitar abertura do sistema em multi-sessão.

Maligno escreveu:Agora, se esse outro processo não morre com a morte da janela DOS, aí pode ser um problema, pois se o programa for executado continuamente, poderia ser aberto um novo processo para cada execução, acumulando processos "lixo". Verifique se é isso o que ocorre.


Bem não sei como aconteceu, tentei reproduzir essa questão mas não acontece. O nome da janela acontece quando um aplicativo-DOS está em execução. Mas apena no Prompt-MSDOS, não acontece. O processo fica até alguem sair. Na experiência anterior que me aconteceu da abrir um novo processo (digamos "garbage"), eu quis finalizá-lo mas deixava, na hora que queria matar o processo ativava a janela de desligar o computador.

Maligno escreveu:Isso vai ser complicado de fazer. Pesquisei (um pouco, admito), mas ainda não encontrei uma luz.


Pois é, meu nobre colega, eu não domino a sua tão preciada linguagem C. Mas acredito que se você ler o código fonte do autor "Dave Pearson" que é de dominio público, no qual no WIN95 consegue alternar a exibição em FULL SCREEN, talvez você consiga encontrar o "caminho das pedras". Acho que valerá a pena você dar uma olhada no código fonte do DAVE:

 * File......: AUTYIELD.C
* Author....: Dave Pearson
*/

#include <extend.api>
#pragma optimize("lge", off)

/*  $DOC$
*  $FUNCNAME$
*      OL_WinFullScreen()
*  $CATEGORY$
*      Functions
*  $ONELINER$
*      Force a DOS window into full screen mode.
*  $SYNTAX$
*      OL_WinFullScreeen() --> NIL
*  $ARGUMENTS$
*      None.
*  $RETURNS$
*      Nothing.
*  $DESCRIPTION$
*      This function can be used to force your application into full
*      screen mode when running under MS Windows. It should work
*      correctly for Windows 3.x and Windows 95.
*  $EXAMPLES$
*      OL_WinFullScreen()
*      alert( "Boo!" )
*  $SEEALSO$
*
*  $END$
*/

CLIPPER OL_WinFull/*Screen*/( void )
{
    _asm {
        Mov AX, 0x168B;
        Mov BX, 0;
        Int 0x2F;
    }
    _ret();
}


Maligno escreveu:No meu XP, o comando VER solta: "Microsoft Windows XP [versão 5.1.2600]".


Pois é, mas isso na linha de comando do DOS. Mas experimenta fazer um PRG que chame através do RUN o comando VER, e verás que o resultado não é o mesmo rodando no WINXP.

Maligno escreveu:Toda crítica construtiva é sempre bem-vinda. Fique à vontade. :)
Obrigado, Paulo. Minhas observações espero que sejam de ajuda no somente pra nós dois como também pro resto. E é um prazer debater questões em público, pois geralmente enriquecem com novas idéias dos outros participantes.

Mas pelo visto, ninguém se pronuncia neste tópico (a salvo os colegas: Stanis Luksyse, rrfsistemas e MARINI). Deve ser que somente nós estamos interessados neste projeto, hehehe...

Um grande Clip-abraço, colega ! :D

Re: WAPI.LIB

MensagemEnviado: 20 Jan 2007 00:04
por Maligno
A sua na verdade estaria emulando o Win98, sendo que todo seu gerenciamento de memória (o que proporciona maior agilidade nos processos) se dá pelo WINXP. Mas puramente em WIN98 tarda de 3 a 4 segundos, isto não é de morrer, mas não acontece o mesmo no WINXP que fica em menos de um segundo +/- (isto num PENTIUM 4, 2.6GB).

Não. O emulador tem de ser (e é) fiel ao alvo da emulação. Se não fosse assim, seria uma falha terrível da empresa (VMWare). Deve ser outro motivo. Quando for possível, vou levar o programa de teste para um Win98 real, em algum cliente. Só pra tirar a dúvida.

Não. Nãe seria isso. Vou te explicar detalhadamente o ocorrrido.
Digamos que num diretório eu tenha uma outra versão do WAPI.EXE. ...

Ah, sim agora entendi. E já sei o que é. Removendo o WAPI antigo funciona. O que ocorre é o seguinte: há um diretório onde o WAPI deve ser "descarregado". O diretório default (acredito que você não tenha alterado) é o corrente. Se neste diretório já existir o arquivo WAPI.EXE, nada será feito e esse arquivo é que será utilizado. É isso. Basta remover o WAPI antigo ou redefinir o diretório de "descarga".

Entendo que isso de mudar o arquivo-de-atalho, seria uma solução que pareceria "KAMIKASE", porém eu acho que este seria a segunda medida a ser tomada após mudar o nome do processo. Porque enquanto você muda o processo que está rodando e o usuário fecha e abre novamente, bye bye a mudança do título.

Porque? Basta executar o programa novamente, recolocando o título. É como aquele programa de teste que fiz (UNIQUE.EXE). Ao executá-lo, o título é trocado. Ao encerrar e executar de novo o título retorna, como antes. Não é isso?

Bem não sei como aconteceu, tentei reproduzir essa questão mas não acontece. O nome da janela acontece quando um aplicativo-DOS está em execução. Mas apena no Prompt-MSDOS, não acontece. O processo fica até alguem sair. Na experiência anterior que me aconteceu da abrir um novo processo (digamos "garbage"), eu quis finalizá-lo mas deixava, na hora que queria matar o processo ativava a janela de desligar o computador.

Não estou entendendo mais nada. Quando isso ocorria, uma outra janela era aberta? Que função você utilizava no momento? A de troca de título?

acredito que se você ler o código fonte do autor "Dave Pearson" que é de dominio público, no qual no WIN95 consegue alternar a exibição em FULL SCREEN, talvez você consiga encontrar o "caminho das pedras". Acho que valerá a pena você dar uma olhada no código fonte do DAVE:

Eu já conheço essa função há um bom tempo. Ela utiliza uma interrupção chamada Multiplex, que não funciona em 32 bits. Isso nem é mais problema. Eu uso uma função que faz uma comutação para modo gráfico e em seguida para modo texto. Funciona em qualquer Windows, que eu saiba. Postei o link para um colega há algum tempo.

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

Re: Waitng for your WAPI

MensagemEnviado: 20 Jan 2007 02:34
por Stanis Luksys
Maligno escreveu:O ruim desse programa é que se a aplicação Clipper der pau, a tecla WinKey permanecerá bloqueada. Se você executá-la de novo, imagino que a WinKey será desabilitada, ao invés de habilitada. Ou seja, é feita a comutação de ON para OFF e OFF para ON. Estou certo?


Maligno,

Exatamente, no entanto para que isso ocorra precisaríamos de um .bat, ou até um .com... Só que este artifício é um daqueles que eu mais procuro evitar em meus programas. E também não gosto de usar programas de terceiros, mesmo que sejam livres. Quer dizer, quando é bom usar eu gosto, não gosto mesmo é de enviar pro cliente... ;=)

No caso, eu testei no Windows 98 e tinha funcionado uma vez, desabilitou a tecla quando desabilitou o botão, mas enviei pro cliente e no XP dele não funcionou. Ainda assim tinha o problema de que se o programa desse pau, ele ficava sem 'iniciar' (hehe), mas bastava entrar e sair de novo (quando saía é que habilitava o botão). De qualquer forma dar pau de encerrar mesmo meu sistema é razoavelmente 'raro', já não desenvolvo mais nada em clipper há muito tempo mas já passei horas e horas corrigindo bugs, e ainda deve ter alguns... hehe

Não me lembro bem como eu tinha feito naquela ocasião (era bem parecido com o exemplo que eu indiquei lá no link, mas em C e sem minigui). Por fim, na época deixei isso de lado, e só fui me interessar novamente quando surgiu este tópico aqui no fórum. Sabe como é, gostamos de desafios, e principalmente de conhecimento.

Mudando de assunto vou aproveitar para parabeniza-lo pela iniciativa do WAPI, e a você e ao Pablo pela discussão de alto nível que vêm levando aqui quase que "solitários". Saibam que tenho acompanhado desde o inicio recebendo as notificações a cada novo post por e-mail.

Se eu estivesse bem envolvido com Clipper como antigamente, com certeza estaria testando tudo, é ruim demais ver as tecnolgias evoluirem e se sentir amarrado a gambiarras. Mas como não é o caso, e infelizmente tempo não é nosso forte, fico devendo a mim e a vocês testar todos os recursos e fazer parte do WAPI beta team. :=))

Valeu aí!!

Boa sorte!

Re: Waitng for your WAPI

MensagemEnviado: 20 Jan 2007 11:35
por Maligno
Stanis Luksys escreveu:
Maligno escreveu:O ruim desse programa é que se a aplicação Clipper der pau

Exatamente, no entanto para que isso ocorra precisaríamos de um .bat, ou até um .com... Só que este artifício é um daqueles que eu mais procuro evitar em meus programas. E também não gosto de usar programas de terceiros, mesmo que sejam livres. Quer dizer, quando é bom usar eu gosto, não gosto mesmo é de enviar pro cliente... ;=)

Exatamente pra evitar esse aborrecimento é que eu inventei o embutimento no Clipper. O próprio WAPI, embutido, é utilizado como se fosse uma simples função nativa do Clipper. No caso do WKeyKill, eu faria o mesmo, ao invés de usar um batch.

No caso, eu testei no Windows 98 e tinha funcionado uma vez, desabilitou a tecla quando desabilitou o botão, mas enviei pro cliente e no XP dele não funcionou.

Testei no meu XP Pro e funcionou como esperado. Deveria ter funcionado no do seu cliente. Isso é estranho. Até porque, esse programa, salvo engano, utiliza uma função da API chamada SetWindowsHookEx(), que é compatível do Windows 95 até o XP (provavelmente o Vista também), de acordo com o MSDN.

Ainda assim tinha o problema de que se o programa desse pau, ele ficava sem 'iniciar' (hehe), mas bastava entrar e sair de novo (quando saía é que habilitava o botão).

Isso é simples de resolver. Se eu fosse fazer, montaria o "hook" para receber, como argumento de inicialização, o handle (windows) da janela que o invocou. Monitorando a janela por esse "handle", ao perceber a "morte" desta, o "hook", solidário, se "suicidaria", mas depois de restaurar o acesso às teclas desativadas. O chato da história é que a DLL teria de ser reescrita, claro. Mas isso resolveria o problema de forma automática, sem que o usuário tivesse que entrar e sair do programa de novo só para recuperar a WinKey.

Mudando de assunto vou aproveitar para parabeniza-lo pela iniciativa do WAPI, e a você e ao Pablo pela discussão de alto nível que vêm levando aqui quase que "solitários". Saibam que tenho acompanhado desde o inicio recebendo as notificações a cada novo post por e-mail.

Obrigado. Meu interesse no WAPI aumentou depois que, infelizmente, tive que regredir e fazer diversas atualizações num sistema grande que ainda tenho em Clipper. Mas daqui pra frente, não há muito o que fazer, além de um demo decente e aparar algumas arestas.

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

MensagemEnviado: 20 Jan 2007 12:22
por Clipper
Gostaria de aproveitar para agradecer e parabenizar o Maligno (leia-se Benigno) pela ótima lib e pelo tempo gasto em ajudar aos colegas !

Valeuuuuuuuuuuuuuuuuuu !!!! :)Pos :{ -:]

Obrigado em nome de todos do fórum !

Marcelo

WAPI.LIB

MensagemEnviado: 20 Jan 2007 16:17
por Pablo César
Maligno escreveu:Não. O emulador tem de ser (e é) fiel ao alvo da emulação...
Eu gostaria de exemplificar e espero não dar a impressão de ser grosseiro no exemplo por ser breve na idéia:

A impressão que eu tenho dessa emulação (mesmo sem conhece-la) é como um fusca rodar num free-way. A idéia é de passar que o fusca irá continuar sendo fusca porém andará que melhor performace num estrada boa que numa não asfaltada. Mas este assunto não deveria se extender, porque eu mesmo não conheço essa emulação, ora porque na minha máquina utilizo dois HDs (WIN98 num e WINXP no outro) e seleciono na hora de inicializar através do SETUP. Mas que há uma grande diferença na execução do aplicativo entre o WINXP e WIN98... há.

Maligno escreveu:Porque? Basta executar o programa novamente, recolocando o título.
Tudo bem, porém está sujeito a ser driblado pelo usuário na hora de execução.

Maligno escreveu:Ao executá-lo, o título é trocado. Ao encerrar e executar de novo o título retorna, como antes. Não é isso?
Eu até iria abrir mão, porque também acho que se usuário quer sacanear... também assim é demais !!!. Mas é que no WIN98 esta função não está funcionando corretamente. Ela as vezes funciona momentaneamente e mesmo ainda a sessão não te sido fechada, retorna o nome do título original. Eu poderia usar a função do Dave OL_95VMTITLE() que roda bem em 95 e 98. Porém... preciso saber a versão do WINDOWS. E essa outra questão (da versão do Windows) não é tão simples assim.

Existem vários motivos em que nos vemos com a necessidade de saber a versão do WINDOWS para trabalhar de forma diferenciada conforme cada versão. E a criação de uma função em C seria o mais recomendado, porque o uso do comando do sistema operacional VER, não funciona em todas a situações.

Por exemplo: se você criar um arquivo .BAT e colocar VER > VERWIN.TXT, e for executado... você verá que não conterá resultado alguna nesse arquivo (teste feito em WIN98). Porém se na linha de comando você digitar VER > VERWIN.TXT daí sim terá o conteúdo de acordo a versão do WINDOWS. Esquisito, não é ?. Também se for rodar o VER através do RUN e executar o programa irá criar o arquivo com a versão de emulação no WINXP (versao 5.00). Veja tópico dos nosso colegas: http://www.pctoledo.com.br/forum/viewto ... ao+windows

Maligno escreveu:Não estou entendendo mais nada. Quando isso ocorria, uma outra janela era aberta? Que função você utilizava no momento? A de troca de título?
Isso me ocorreu uma vez e não conseguí reporduzir o mesmo caso e nem tentei mais (usando o APPTITLE). Eu tinha aberto duas sessões de PROMPT-MSDOS e quando accionei o gerenciador de tarefas vi que estava os dois PROMPT-MSDOS e mais uma tarefa com o nome que eu tinha dado para uma das janelas. Mas não abriu nenhuma janela extra, simplesmente foi uma traefa que inclusive não conseguí finalizar (tive que resetar).

Maligno escreveu:...utiliza uma interrupção chamada Multiplex, que não funciona em 32 bits... Postei o link para um colega
Essa solução seria o WinFullScr() que você postou para WCARDOSO (sobre ICONE NO XP) ?. Mas lembre que a minha sugestão não seria alternar o modo de exibição através do WAPI (que acho isto muito mais dificil) e sim identificar se a sessão está em modo TEXTO ou JANELADO escrevendo o resultado num arquivo texto.

Maligno, quando você menciona: "Ela utiliza uma interrupção chamada Multiplex, que não funciona em 32 bits. Isso nem é mais problema." Você quer dizer que em WIN98 você conseguiria detectar se está em modo texto ?.

Bem me disculpe se estou um pouco (bastante) insistente. E espero ter respondido as suas dúvidas sobre as minhas colocações.

Um clip-abraço,

Pablo :)Pos

WAPI.LIB ==> COMANDO VER

MensagemEnviado: 20 Jan 2007 17:40
por Pablo César
Corrigindo... O que eu disse que ao rodar o VER dentro do arquivo BATCH, não daria certo. Não é assim. dá certo sim. O teste que eu fiz e não deu certo foi dentro de um BATCH mas com uma condição, daí sim não funciona. Para quem quer saber usei:

IF NOT EXIST C:VERWIN.TXT VER > C:VERWIN.TXT

Mas desta forma não funcina, cria arquivo mas em branco.

Desculpem o meu equivo.

Um clip-abraço

:xau

MensagemEnviado: 20 Jan 2007 18:51
por sygecom
Primeiro Gostaria de parabenizar o Maligno e a todos que estaum colaborando por essa otima ferramenta.......

Tche, atraves dessa WAPI.LIB eu consigo imprimir em impressoras USB ?? Se sim como faço isso....????

Jah baixei o pacote jah dei uma olhada nos exemplos de impressão mas a unica coisa q consigo é enviar o arquivo para a fila de impressão....mas acreditem se quiser ele não imprime e nem sai da fila de impressão.

Jah toh passando a usar diversas das funções dessa LIB...como a do X das janelas,Titulo da Janela,Tela cheia e alguns Sons...

Mais uma vez parabens Maligno...por se dedicar a essa ferramenta.... -:] -:] -:]
Abraços

Re: WAPI.LIB

MensagemEnviado: 22 Jan 2007 01:15
por Maligno
Pablo César escreveu:A impressão que eu tenho dessa emulação (mesmo sem conhece-la) é como um fusca rodar num free-way.

Tudo bem que não queira estender a discussão sobre emulação, mas apenas para deixar mais claro: os emuladores que existem (eu uso o VMWare) são fiéis a extremo. Se rodam Linux, o comportamento será de Linux, sem nada a mais nem a menos. No Windows 98 (com o XP como host) tudo funciona perfeitamente (com as devidas limitações naturais) como num Windows 98 real. A velocidade, claro, reduz-se um pouco. E para o seu caso, que utiliza dois HDs, se tiver um processador relativamente rápido, aconselho a utilização de um emulador. E não só para fins de teste, como normalmente é. Tenho também uma máquina XP emulada, que utilizo para visitar sites de cárater "duvidoso". Na eventualidade de alguma "contaminação" apenas gravo uma máquina "virgem" em cima da contaminada. É bem prático.

Mas é que no WIN98 esta função não está funcionando corretamente. Ela as vezes funciona momentaneamente e mesmo ainda a sessão não te sido fechada, retorna o nome do título original. Eu poderia usar a função do Dave OL_95VMTITLE() que roda bem em 95 e 98. Porém... preciso saber a versão do WINDOWS. E essa outra questão (da versão do Windows) não é tão simples assim.
Existem vários motivos em que nos vemos com a necessidade de saber a versão do WINDOWS para trabalhar de forma diferenciada conforme cada versão. E a criação de uma função em C seria o mais recomendado, porque o uso do comando do sistema operacional VER, não funciona em todas a situações.

Se esse era o problema, problema resolvido. Modifiquei o WAPI para informar os dados acerca da versão do sistema operacional. Com o switch "-GETWINDOWSINFO:<resultFile>" você obtém todas as informações necessárias. A função de abstração se chama GetWinInfo(). Leia o \WAPI\LIB\README.TXT na parte que se refere às funções do diretório \LIB\OS. Agora a função SetAppTitle() testa a plataforma em operação. Se for kernel NT, ela utiliza o WAPI, da mesma forma como estava fazendo até agora. Porém, se não for NT, ele passa a utilizar a função OL_95AppTitle(), da OSLib que, evidentemente, terá de ser incluída no seu script de linkedição. Fiz uma nova versão do demo UNIQUE.EXE. Testei no meu Win98 virtual e funcionou corretamente.

Código exemplo de uso da função GetWinInfo():

#include "macros.ch"

WAPIExeDir(".")   // extrai WAPI.EXE para a pasta corrente
EraseWAPI(_kTRUE) // função nova: se TRUE, o WAPI.EXE será
                     apagado depois de utilizado.
clear

aInfo := GetWinInfo()
? "Platform: " + aInfo[1]
? "ID......: " + aInfo[2]
? "Pack....: " + aInfo[3]
? "Version.: " + aInfo[4]
?

/*
Saída para o meu XP real
---------------------------------
Platform: NT
ID......: Windows XP Professional
Pack....: Service Pack 2
Version.: 5.1.2600

Saída para o Windows 98 virtual
---------------------------------
Platform: 9X
ID......: Windows 98 SE
Pack....: A
Version.: 4.10.67766446
*/


Mas lembre que a minha sugestão não seria alternar o modo de exibição através do WAPI (que acho isto muito mais dificil) e sim identificar se a sessão está em modo TEXTO ou JANELADO escrevendo o resultado num arquivo texto.

Eu só comentei a respeito desta função porque foi esta cujo código você postou. :)

Maligno, quando você menciona: "Ela utiliza uma interrupção chamada Multiplex, que não funciona em 32 bits. Isso nem é mais problema." Você quer dizer que em WIN98 você conseguiria detectar se está em modo texto ?.

Sinto muito, mas não foi isso o que eu quis dizer. Quanto ao problema que eu disse estar resolvido, eu quis dizer sobre o caso da comutação para tela cheia através da função WinFullScr(). Não tem nada a ver com checagem de modo.

Teste a nova versão da LIB. Aliás, já vá direto para o teste com o demo UNIQUE. Acho que agora vai dar certo. Mas atente para um detalhe: no Windows 98 o título da aplicação é prefixado com a string "Prompt do MS-DOS - ". Resolvi isso modificando o bloco de código que faz a pesquisa na matriz de títulos que o UNIQUE obtém. Leia o fonte se tiver dúvida.

Relembrando os links:
http://buzinello.com/download/wapi.zip
http://buzinello.com/download/wapi_demo.zip (UNIQUE)


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

MensagemEnviado: 22 Jan 2007 01:37
por Maligno
sygecom escreveu:Tche, atraves dessa WAPI.LIB eu consigo imprimir em impressoras USB ?? Se sim como faço isso....????

Sim, é possível. Mas apenas no modo RAW (você é quem deverá formatar o texto). Testei com uma HP LaserJet 1022 USB. Para fazer isso é muito simples. Direcione sua impressão para um arquivo e execute a função de impressão. Supondo que seu arquivo se chama REPORT.TXT:

if PrintFile("HP LaserJet 1022","REPORT.TXT","TITULO NO SPOOLER")
   ? "Impressão (modo RAW) encaminhada para o spooler.
   ?
   quit
end
? "Houve um erro qualquer..."
? "Basta verificar o retorno da função WAPIError()."
?


Alternativamente, para imprimir na impressora default, troque o nome da impressora para um simples "#". Os SETs são para ajustar o título automático. Neste caso, será algo como "clipper.report@21/01/2007,12:34".

set date british
set century on
PrintFile("#,"REPORT.TXT")


Jah baixei o pacote jah dei uma olhada nos exemplos de impressão mas a unica coisa q consigo é enviar o arquivo para a fila de impressão....mas acreditem se quiser ele não imprime e nem sai da fila de impressão.

Estranho. Infelizmente não consegui desligar o redirecionamento automático para o spooler, para imprimir diretamente para a impressora. Nem acho vantagem, mas para efeito de teste apenas. Tentou em outra máquina?

Jah toh passando a usar diversas das funções dessa LIB...como a do X das janelas,Titulo da Janela,Tela cheia e alguns Sons...

Já fico feliz de saber que está aproveitando. Aliás, falando em som, está aí uma coisa que não gostei muito. Não foi possível tocar um WAVE em modo assíncrono. O retorno ao Clipper só ocorre depois do som terminar de tocar. Para sons curtos o problema não chega a incomodar tanto. Mas quando a duração aumenta muito, fica meio chato. Pra resolver isso, vou ter que criar um modo de operação diferente para o WAPI. É uma mudança meio radical. Vou precisar de um tempo maior.

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

MensagemEnviado: 22 Jan 2007 10:40
por sygecom
Buenas...
Sim, é possível. Mas apenas no modo RAW (você é quem deverá formatar o texto). Testei com uma HP LaserJet 1022 USB. Para fazer isso é muito simples. Direcione sua impressão para um arquivo e execute a função de impressão. Supondo que seu arquivo se chama REPORT.TXT:


Tche, tentei de tudo que é jeito....mas nem com reza braba o arquivo vai para a fila de impressão.....abaixo segue um exemplo de como eu faço hj nas impressora matricial...
EXEMPLO 01

SET DEVICE TO PRINT
IF NA TELA="S"
   SET PRINT TO USB.TXT
ELSE
   SET PRINT TO LPT1
ENDIF
@ prow()+1,00     SAY "IMPRIMINDO"
@ prow()+1,00     SAY "IMPRIMINDO"
@ prow()+1,00     SAY "IMPRIMINDO"

SET PRINTER TO
set device to screen
NETCANCEL("LPT1")

IF TELA="S"
   EDICAO("USB.TXT")  // VISUALIZAR O ARQUIVO TEXTO NO VIDEO
ENDIF
return

Obs: o que seria impressão em MODO RAW ???

No exemplo Abaixo o arquivo vai para a impressora HP-PSC-1410 diz que esta imprimindo mas não imprime nd e não aceita cancelar a impressão da impressora.(Peguei o exemplo abaixo no PRINT1.PRG)

FUNC TESTE
local cFile := UniqFName(WAPITmpDir())
local cBuff
local nRet

cPrtName="HP1410"

set date british
set century on

cRptTitle="clipper.report@"+DtoC(Date())+","+Time()

PRIVATE cRptFile:="USB.TXT"
     
WAPIError(_kERROR_NONE)

if cPrtName=_kVOID .or. cRptFile=_kVOID .or. !File(cRptFile)
   WAPIError(_kERROR_PARAMETERS)
   return _kFALSE
end

if RunWAPICmd("-PRINT:"+Quote(cPrtName )+_kARGS_SEP+;
                        Quote(cRptFile )+_kARGS_SEP+;
                        Quote(cRptTitle)+_kARGS_SEP+;
                        Quote(cFile    )            )
   if !ReadRetFile(cFile,@cBuff)
      return _kFALSE
   end
end
nRet := Val(cBuff)
WAPIError(nRet)
 
return (nRet=_kERROR_NONE)


Obs.:
Esse Exemplo Abaixo nem se quer aparece na Impressora o arquivo !!!!
PrintFile("#","USB.TXT")


Referente ao SOM vc tem toda a razão ele retarda os sistema na hora da execução do som....mas no meu caso eu toh usando somente uns sons pequenos e não esta atrapalhando em nd......

Abraços e No que eu poder Ajudar prende o grito.....e mais uma vez parabens !!!

MensagemEnviado: 22 Jan 2007 11:02
por Maligno
o que seria impressão em MODO RAW ???

É quando o conteúdo é transmitido sem que seja feita qualquer alteração por parte do dispositivo que o transmite.

No exemplo Abaixo o arquivo vai para a impressora HP-PSC-1410 diz que esta imprimindo mas não imprime nd e não aceita cancelar a impressão da impressora.(Peguei o exemplo abaixo no PRINT1.PRG)

Pelo que entendi o arquivo vai para o spooler, mas a impressora não dá sinal de vida. Se for isso, o trabalho do WAPI está sendo feito como esperado. O problema está em passar do spooler para a impressora. Daí eu não sei o que dizer. Você pôde testar em outra máquina?

Esse Exemplo Abaixo nem se quer aparece na Impressora o arquivo !!!!
PrintFile("#","USB.TXT")

Bom, se não vai para o spooler, aí sim há um erro. Tentou pegar uma lista de impressoras instaladas? Use a função GetPrinters() para uma lista completa e GetDefPrinter() para saber qual está configurada como default.

Aliás, qual Windows você está usando? Nos meus testes usei o XP Pro e tudo funciona corretamente. As funções contidas na LIB funcionaram. Assim, procure evitar adaptá-las para seus testes. Você pode acabar esquecendo alguma coisa e elas podem deixar de funcionar. Ao invés isso, apenas chame-as como indicado: PrintFile("HP1410","USB.TXT"), por exemplo. Aliás, um lembrete: não se incomode em remover os espaços entre nomes de impressoras. O WAPI não se perderá nisso.

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

MensagemEnviado: 22 Jan 2007 11:32
por sygecom
Buenas...
Você pôde testar em outra máquina?


Posso sim....vou agora a tarde em um cliente e já testo por lah...

Bom, se não vai para o spooler, aí sim há um erro. Tentou pegar uma lista de impressoras instaladas? Use a função GetPrinters() para uma lista completa e GetDefPrinter() para saber qual está configurada como default


Peguei a lista de Impressoras e coloquei num DBF deu tudo certo....consegui achar a impressora padrão....mas igaul não funciona quando mando imprimir pelo comando PrintFile("cPrtName","USB.TXT")

Aliás, qual Windows você está usando?

Eu toh usando o Windows XP-Pro.

. Aliás, um lembrete: não se incomode em remover os espaços entre nomes de impressoras. O WAPI não se perderá nisso.

Obrigado pelo Lembrete.....eu já tinha visto no README...mas é que eu Tirei os espaço em branco para Testar mesmo......não querendo duvidar do WAPI.LIB mas....a Anciedade de ver funcionar é grande....hehehehe.......

No Final da Tarde eu volto e falo aqui como foi os teste em outra maquina com outra impressora !!!

Abraços !!!

MensagemEnviado: 22 Jan 2007 11:42
por Maligno
Peguei a lista de Impressoras e coloquei num DBF deu tudo certo....consegui achar a impressora padrão....mas igaul não funciona quando mando imprimir pelo comando PrintFile("cPrtName","USB.TXT")

Acho que você quis dizer: PrintFile(cPrtName,"USB.TXT"), sem as aspas, não é? :)

Tente também PrintFile(GetDefPrinter()[1],"USB.TXT"), que tem o mesmo efeito (pra mim, pelo menos) que PrintFile("#","USB.TXT"). Aliás, o efeito é o mesmo, mas os caminhos são diferentes.

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

MensagemEnviado: 22 Jan 2007 12:23
por sygecom
Acho que você quis dizer: PrintFile(cPrtName,"USB.TXT"), sem as aspas, não é? :)


Desculpa me passei nas aspas estou fazendo conforme esta acima e não teve jeito !!!

Tente também PrintFile(GetDefPrinter()[1],"USB.TXT"), que tem o mesmo efeito (pra mim, pelo menos) que PrintFile("#","USB.TXT"). Aliás, o efeito é o mesmo, mas os caminhos são diferentes.


Tche...realmente não sei o que esta acontecendo mas fiz desse outro modo e tb..não deu certo....acho que pode ser algo aqui na minha maquina com essa impressora....(NO WINDOWS FUNCIONA TUDO CERTO),.agora a tarde toh indo em um cliente e vou testar de tudo que é jeito lah !!! Mas caso não de certo por lah eu não vou me descançar em quanto não ver isso funcionando....desde já agradeço pelo sua nobre paciencia e desculpa alguma coisa !!

Abraços !!!

MensagemEnviado: 22 Jan 2007 14:28
por sygecom
Maligno

Toh no meu cliente e aqui tem uma Epson LX-300 , aqui funcionou perfeitamente no modo abaixo:

FUNC TESTE  // IMPRIMIR EM USB
local cFile := UniqFName(WAPITmpDir())
local cBuff
local nRet

SELE 1
USE C:\IMP ALIAS IMP SHARED // ARQUIVO ONDE ESTA GRAVADO A IMPRESSORA PADRÃO

SELE IMP
cPrtName=IMP

set date british
set century on

cRptTitle="clipper.report@"+DtoC(Date())+","+Time()

PRIVATE cRptFile:="USB.TXT"   // CAMINHO DO ARQUIVO
     
WAPIError(_kERROR_NONE)

if cPrtName=_kVOID .or. cRptFile=_kVOID .or. !File(cRptFile)
   WAPIError(_kERROR_PARAMETERS)
   return _kFALSE
end

if RunWAPICmd("-PRINT:"+Quote(cPrtName )+_kARGS_SEP+;
                        Quote(cRptFile )+_kARGS_SEP+;
                        Quote(cRptTitle)+_kARGS_SEP+;
                        Quote(cFile    )            )
   if !ReadRetFile(cFile,@cBuff)
      return _kFALSE
   end
end
nRet := Val(cBuff)
WAPIError(nRet)
 
return (nRet=_kERROR_NONE)


Agora no modo mais simples que é chamando a função PrintFile(GetDefPrinter()[1],"USB.TXT") ou PrintFile(cPrtName,"USB.TXT") não tem jeito...mas isso não é problema pq peguei a função TESTE e fiz dela padrão nas impressão do meu sistema......até aqui sem stress....agora me diz uma coisa....não querendo ser chato..mas existe alguma possibilidade de imprimir em modo CONDENSADO pela WAPI.LIB ???

Abraços......e Obrigado por Tudo !!! -:] -:] -:]

MensagemEnviado: 22 Jan 2007 16:38
por Maligno
Agora no modo mais simples que é chamando a função PrintFile(GetDefPrinter()[1],"USB.TXT") ou PrintFile(cPrtName,"USB.TXT") não tem jeito...

Que cois mais esquisita. Um nome de impressora é sempre um nome de impressora. Não importa se o nome vem de uma função ou de um DBF. Se for o nome certo, tem que imprimir. Você tentou ver no seu cliente qual é o resultado da função GetDefPrinter()? Aliás, qual é o nome da impressora?

existe alguma possibilidade de imprimir em modo CONDENSADO pela WAPI.LIB ???

Tecnicamente sim. Mas eu não quero vincular o WAPI ao código de nenhuma impressora. Senão acabaria virando gambiarra. O melhor seria fazer uma LIB à parte, para abstração dos comandos de impressão. Nada difícil.

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

MensagemEnviado: 22 Jan 2007 16:40
por Maligno
NO WINDOWS FUNCIONA TUDO CERTO

O que você quer dizer com isso? Você está tentando usar no DOS puro?

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

MensagemEnviado: 22 Jan 2007 17:12
por sygecom
O que você quer dizer com isso? Você está tentando usar no DOS puro?

Desculpa.....falha minha....eu quiz dizer q para eu imprimir fora do meu sistema em CLIPPER tudo Imprime certinho.....ex: arquivos em EXCEL,WORD e ETC...a impressora funciona perfeitamente...

Que cois mais esquisita. Um nome de impressora é sempre um nome de impressora. Não importa se o nome vem de uma função ou de um DBF. Se for o nome certo, tem que imprimir. Você tentou ver no seu cliente qual é o resultado da função GetDefPrinter()? Aliás, qual é o nome da impressora?

Estranho mesmo !!! Mas acredito que a questão não esta no nome da impressora......estou pegando o nome da impressora e a porta do resultado de GETPRINTERS() e gravando num DBF soh para ter cadastrado as impressora do windows no meu sistema em CLIPPER....Obs:A Impressora no meu cliente é uma LX-300.

Tecnicamente sim. Mas eu não quero vincular o WAPI ao código de nenhuma impressora. Senão acabaria virando gambiarra. O melhor seria fazer uma LIB à parte, para abstração dos comandos de impressão. Nada difícil.


Tche, por exemplo no meu caso tenho relatorios que vão alem das 80 colunas e mando imprimir no condensado(EM IMPRESSORA LX-300) para sair tudo nos conforme.....não querendo torrar sua paciencia...existe alguma maneira de eu poder resolver essa questão de impressão condensado usando a WAPI.LIB ex : gera um arquivo RTF ou WORD jah na fonte correta para imprimir pequeno e depois enviar o arquivo para o SPOOLER....vc sugere alguma coisa.....

Mais uma vez Obrigado.....mas vc esta colaborando e muito a todos aqui no forum......

MensagemEnviado: 22 Jan 2007 17:47
por Maligno
eu quiz dizer q para eu imprimir fora do meu sistema em CLIPPER tudo Imprime certinho.....ex: arquivos em EXCEL,WORD e ETC...a impressora funciona perfeitamente...

Ah, bom. Agora eu entendi. :)

Estranho mesmo !!! Mas acredito que a questão não esta no nome da impressora......estou pegando o nome da impressora e a porta do resultado de GETPRINTERS() e gravando num DBF soh para ter cadastrado as impressora do windows no meu sistema em CLIPPER....Obs:A Impressora no meu cliente é uma LX-300.

Pois é super-estranho. Veja o que você está fazendo: ao invés de informar o nome da impressora pela função que pega o nome da impressora default, você pega o nome da impressora default, grava no DBF e o recupera para informar a função. Você apenas e tão somente alongou o caminho. Do primeiro modo deveria funcionar. Afinal de contas, como eu disse antes: nome é sempre nome, string é sempre string.

existe alguma maneira de eu poder resolver essa questão de impressão condensado usando a WAPI.LIB ex : gera um arquivo RTF ou WORD jah na fonte correta para imprimir pequeno e depois enviar o arquivo para o SPOOLER....vc sugere alguma coisa.....

Note: você usará o WAPI apenas para a tarefa final: direcionamento de conteúdo para a impressora. Mas o conteúdo terá de ser trabalhado por você. Minha sugestão é aquela que eu disse: funções de abstração. Exemplo:

function Condensed(lCond)
return if(PrinterOut()="LASER", Chr(1)+Chr(2)+bla bla bla,
       if(PrinterOut()="DESKJ", Chr(3)+Chr(4)+bla bla bla,
       if(PrinterOut()="MATRI", Chr(5)+Chr(6)+bla bla bla, ...)))
...
// Na montagem do relatório
function ReportTST()
PrinterOut("LASER")
@ PRow()+1,0 say Condensed(_kON) + "Abstração" + Condensed(_kOFF)
@ PRow()+1,0 say bla bla bla...
...
...

Depois de montada esta camada de abstração, qualquer relatório ficará fácil. É como se você criasse seus próprios drivers de impressão. Basta comutar para esta ou aquela impressora que toda a formatação mudará de acordo com as características da impressora escolhida.
Note: não envie um RTF ou DOC diretamente para o spooler, que você só conseguirá visualizar brorroscas incompreensíveis, já que nenhuma impressora "interpreta" documentos desses tipos. E se o WAPI é quem fosse interpretar um RTF ou DOC, ele teria de conhecer as características de cada impressora. Por isso que eu digo que é muito mais negócio montar uma LIB de abstração das características de cada impressora com a qual se trabalha.

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

WAPI.LIB

MensagemEnviado: 22 Jan 2007 20:12
por Pablo César
Acho que ja achei o defeito na hora de mandar imprimir e nada pela função PRINT. Testei em WIN98 e WINXP e a mesma conclusão. Se bem que não utilizei a LIB, usei direto o WAPI.EXE. O erro está em que deve ser passado os quatro parâmetros, senão ele não funciona. Isto é, tem que chamar por exemplo:

WAPI -PRINT:"Epson LX-300";"RECIBO.TXT";"Teste do banner";"RESULTA.TXT"

Só tem um inconveniente no WIN98. Mesmo passando todos os parâmetros, o banner (rôtulo) na fila de impressão não aparece sempre. Imprime, mas não coloca nada na fila de impressão. Embora consiga colocar de novo o banner, quando faço uma espécie de reset no comando. Isto é, mando imprimir sem os quatros parametros, mas quando coloco os quatro parametros, daí sim imprime e aparece o banner na fila de impressão. Acho que deve ser, que alguma coisa fica residente ou como se a sucessiva impressão ignorasse o banner na fila de impressão. Melhor dito, banner e tda descrição da fila de impressão. Mas imprime sempre que for passado os quatro parametros. No WINXP, não tem problema desse tipo, sempre aparece na fla de impressão. Mas também tem que ser passado os quatros paramentos da função PRINT.

Aproveitado aqui esta ocasião, gostaria de te perguntar MALIGNO, se no WINDOWS (creiria através das DLLs) que acompanha cada impressora, se te como saber quais seriam os comandos para fazer por exemplo: condensado, enfatizado, expandido. Tem como ?. Porque como você disse pro nosso colega SYGECOM, que: "melhor seria fazer uma LIB à parte, para abstração dos comandos de impressão". Seria muito bom isso para TODOS NÓS !!!!.

Também aproveito para acusar outro problema. Agora com a função APPTITLE rodando no WINXP (versão: 5.1.2600) no arquivo gerado, me aparece: 9X,Windows 95,,4.0.950. Estaria se perdendo na versão do WINDOWS ?.

Bem espero ter ajudado. Um clip-abraço e obrigado MALIGNO pela paciência que você tem conosco. Hoje reí muito quando:

SYGECOM escreveu:NO WINDOWS FUNCIONA TUDO CERTO?

e você MALIGNO escreveu:O que você quer dizer com isso? Você está tentando usar no DOS puro?


me rachei de rir, porque eu estava acompanhando entusiasmado o caso do colega SYGECOM e também pensei o mesmo !! KAKAKAKAKA

Mais uma vez, um clip-abraço !
:)Pos :xau

Re: WAPI.LIB

MensagemEnviado: 22 Jan 2007 20:30
por Maligno
O erro está em que deve ser passado os quatro parâmetros, senão ele não funciona.

Sim. O WAPI exige os quatro parâmetros, mas usando a função PrintFile() você só precisa informar dois, que ela cuida de passar os demais. Não faz diferença.

Só tem um inconveniente no WIN98. Mesmo passando todos os parâmetros, o banner (rôtulo) na fila de impressão não aparece sempre. Imprime, mas não coloca nada na fila de impressão.

Esse Windows 98 é um carma. :(
Infelizmente não consegui imprimir pelo Windows 98 virtual. Ainda não estou conseguindo acessar nada do virtual para o host. Só do contrário.

Aproveitado aqui esta ocasião, gostaria de te perguntar MALIGNO, se no WINDOWS (creiria através das DLLs) que acompanha cada impressora, se te como saber quais seriam os comandos para fazer por exemplo: condensado, enfatizado, expandido. Tem como ?

Não. Você precisa de documentação. Aliás, nesse exato minuto acabei de falar por chat com o pessoal da HP. Consegui os dados da PCL5e. Caso alguém queira, é só clicar aqui.

Porque como você disse pro nosso colega SYGECOM, que: "melhor seria fazer uma LIB à parte, para abstração dos comandos de impressão".

Sem dúvida, acho que o melhor caminho é usar uma interface para montar o relatório. Em um nível mais alto, tudo ficará mais prático e transparente.

Também aproveito para acusar outro problema. Agora com a função APPTITLE rodando no WINXP (versão: 5.1.2600) no arquivo gerado, me aparece: 9X,Windows 95,,4.0.950. Estaria se perdendo na versão do WINDOWS ?.

APPTITLE ou GETWINDOWSINFO? :))
No Windows 95 eu não testei, mas o retorno que falta é referente ao "service pack"; algo relevante apenas para os Windows de kernel NT. O que mais nos interessa é o código da plataforma. No presente caso, "9X".
Agora, se o caso for de você estar tentando ver uma coisa e acabar com um resultado totalmente diferente, a resposta só pode ser uma: o arquivo de resultado não está sobregravando o antigo. Dica: não teste o WAPI diretamente. Utilize as funções de abstração. Assim, todos os arquivos de resultados serão temporários e, logo, únicos. Não haverá meio de fazer esse tipo de confusão.

me rachei de rir, porque eu estava acompanhando entusiasmado o caso do colega SYGECOM e também pensei o mesmo !!

Pois é. Foi um susto ocasionado pela confusão de termos. :)

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

WAPI.LIB

MensagemEnviado: 23 Jan 2007 08:10
por Pablo César
Maligno escreveu:a função PrintFile() você só precisa informar dois
Tá certo você, EU lí o PRINTFIL.PRG, você declara os outros 2 parametros que faltariam. porém estaria forçando o nome do arquivo (temporário) para o qual iria gravar o resultado do enfileramento. E esse arquivo por ser temporário o colega SYGECOM não cosegue acessar. Eu aconselharia, a fins de testes que usasse o WAPI.EXE com os quatro parametros e ver se acontece.

Maligno escreveu:Esse Windows 98 é um carma. :(
Pois é !. E lamentavelmente ele ainda é um WINDOWS muito usado por aqui. Quer um conselho MALIGNO, ponha dois HD o segundo com WIN98 puro.

Maligno escreveu:Não. Você precisa de documentação
Ummm, mas qual seria o processo de impressão nas linguagens for WINDOWS para imprimir. Elas precisam do DLL de cada impressora, não é ?.

Maligno escreveu:o melhor caminho é usar uma interface para montar o relatório
Elas (linguagem for WINDOWS) também utilizam a criação de arquivos ou podem imprimir diretamente ?.

Maligno escreveu:APPTITLE ou GETWINDOWSINFO? :))
Ops, errei no nome da função, quiz dizer GETWINDOWSINFO, sorry.

Maligno escreveu:No Windows 95 eu não testei, mas o retorno que falta é referente ao "service pack"
Não é no WIN95 que estou testando... é no WIN98 como eu disse: "rodando no WINXP (versão: 5.1.2600)", mas não seria a falta do "service pack" com respeito a minha versão do WINDOWS ?. Porque tenho certeza ABSOLUTA, que não é questão do arquivo gerado que não esteja sobre-escrevendo. Esse erro ja foi cometido anteriormente, mas desta vez me certifiquei disso.

Um clip-abraço :)Pos

Re: WAPI.LIB

MensagemEnviado: 23 Jan 2007 09:44
por Maligno
Quer um conselho MALIGNO, ponha dois HD o segundo com WIN98 puro.

Nem pensar. :)

Ummm, mas qual seria o processo de impressão nas linguagens for WINDOWS para imprimir. Elas precisam do DLL de cada impressora, não é ?.

Não. Você tanto pode imprimir diretamente, embutindo os códigos de controle e formatação, (coisa que quase ninguém faz) como pode utilizar um gerador de relatórios (mais prático).

Elas (linguagem for WINDOWS) também utilizam a criação de arquivos ou podem imprimir diretamente?.

Normalmente se utiliza um gerador de relatórios. Estou começando a usar um bom gerador chamado FastReport, no BCB. Ele faz de tudo: acessa bancos de dados, imprime desenhos, bordas, códigos de barras, etc. Nesse tipo de ambiente de programação a regra principal é aumentar a produtividade e perder menos tempo com o trivial.

Não é no WIN95 que estou testando...

Mas você escreveu na outra mensagem "9X,Windows 95,,4.0.950". De onde você tirou isso? Inclusive, a versão 4.0 é referente a Windows 95. Não me diga que isso veio do WAPI. Se veio, seu Windows está completamente doido, pois é ele quem informa isso. No meu Windows 98, tanto em linha de comando, executando o WAPI diretamente, quanto pela função de abstração, o que me retorna é "9X,Windows 98 SE, A ,4.10.67766446".

...é no WIN98 como eu disse: "rodando no WINXP (versão: 5.1.2600)", mas não seria a falta do "service pack" com respeito a minha versão do WINDOWS ?. Porque tenho certeza ABSOLUTA, que não é questão do arquivo gerado que não esteja sobre-escrevendo. Esse erro ja foi cometido anteriormente, mas desta vez me certifiquei disso.

Os dados da versão são informados pela API do Windows (claro). Não vejo como seu Windows poderia informar algo tão errado. Trocar Windows 98 por Windows 95? É uma coisa imcompreensível.

Falando em problemas, testou o UNIQUE?

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

WAPI.LIB

MensagemEnviado: 23 Jan 2007 10:58
por Pablo César
Maligno escreveu:pode utilizar um gerador de relatórios (mais prático).
Esse gerador é fácil de conseguir e podemos usar junto com o nosso sistema em Clipper ?.

Maligno escreveu:Mas você escreveu na outra mensagem "9X,Windows 95,,4.0.950". De onde você tirou isso?
Sim, esse foi o resultado do WAPI no arquivo e repito foi rodado em WINXP, no WIN98 não nenhum problema com a versão. O problema está rodando no XP e é esse o resultado: "9X,Windows 95,,4.0.950"

Eu tinha dito escreveu:Não é no WIN95 que estou testando... é no WIN98 como eu disse:
Perdão, mencionei é no WIN98 sendo que eu devia ter dito é no WINXP, desculpe tou ficando louco com a versão do WINDOWS. Mas acredite, a questão toda é no meu WINXP talvez, mas eu estou com antivirus (tou limpo) não sei se isso acontece com outro colega, seria bom alguém mais opinar em outro XP.

Maligno escreveu:Falando em problemas, testou o UNIQUE?
Testei sim, legal. Eu ja tinha conseguido o mesmo resultado. Mas agora veja que tenho outra questão... Estou implementando na minha rotina APPSINFO. Estou querendo usar o FLASH após detectar que o PROGRAMA está sendo executado em outra sessão. Porém quando passo o número do HANDLE através do RunWapiCmd(), o FLASH não pisca o "botão da taskbar" que deve, e sim, da janela atual. Creio eu, porque o parametro HANDLE é CARACTER e para recebimento do HANDLE dentro da função FLASHTITLEBAR() teria que ser NUMERICO. Eu estou passando em forma de caracter, porque é a única forma de passar parametro (tudo caracter) no comando RunWapiCmd(). Pergunto eu: será que você não deveria transformar todos os parametros das outras funções para que sejam sempre passadas em modo CARACTER ? Ou será que estou falando abobrinhas... ? Digo isto, pela questão de concatenação no comando do RunWapiCmd() feito pelo usuário.

Até mais. :D

Re: WAPI.LIB

MensagemEnviado: 23 Jan 2007 15:08
por Maligno
Esse gerador é fácil de conseguir e podemos usar junto com o nosso sistema em Clipper?.

Sem a menor chance. Ele é totalmente vinculado ao ambiente Delphi/C++.

Maligno escreveu:Mas você escreveu na outra mensagem "9X,Windows 95,,4.0.950". De onde você tirou isso?
Sim, esse foi o resultado do WAPI no arquivo e repito foi rodado em WINXP, no WIN98 não nenhum problema com a versão. O problema está rodando no XP e é esse o resultado: "9X,Windows 95,,4.0.950"

Piorou! No XP a versão é 5.1.

Perdão, mencionei é no WIN98 sendo que eu devia ter dito é no WINXP, desculpe tou ficando louco com a versão do WINDOWS. Mas acredite, a questão toda é no meu WINXP talvez, mas eu estou com antivirus (tou limpo) não sei se isso acontece com outro colega, seria bom alguém mais opinar em outro XP.

Como eu disse: piorou. Vamos esperar que mais alguém teste no XP. Vou tentar ver em outro XP também. Mas isso é informação trazida pela API do Windows. Jamais deveria aparecer como Windows 95. Não entendo.

Pergunto eu: será que você não deveria transformar todos os parametros das outras funções para que sejam sempre passadas em modo CARACTER? Ou será que estou falando abobrinhas... ? Digo isto, pela questão de concatenação no comando do RunWapiCmd() feito pelo usuário.

Para efeito de teste tudo bem, mas veja que a RunWAPICmd() é de uso interno da LIB e tudo já está ajustado para ser feito da maneira mais fácil e coerente. Não há nenhum motivo para mexer nisso agora. Além do que, se você usar apenas as funções de abstração não terá problema algum. É só fornecer os argumentos conforme instruído no help.
O WAPI.EXE sempre retorna tudo como caractere, já que tudo vem num arquivo texto. Mas alguns ítens são convertidos para número. GetAppsInfo() retorna uma matriz, onde o handle é numérico. FlashTBar() recebe o handle como numérico. Não tem erro. Se o FlashTBar() está fazendo piscar a janela atual ao invés de outra, só vejo duas hipóteses: você está se confundindo e está passando o handle da janela atual, pois se no utilitário WAPI você passar um handle errado, nenhuma janela piscará. Experimente usar FlashTBar(3,123456). Nada acontecerá.
A segunda hipótese é que você, usando o RunWAPICmd() diretamente (o que eu não acho ser uma boa idéia), está separando os argumentos com vírgula, ao invés de ponto-e-vírgula. Aí sim, mesmo passando um handle válido, fará piscar sempre a janela atual. É isso?

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

WAPI.LIB

MensagemEnviado: 23 Jan 2007 16:26
por Pablo César
Maligno escreveu:Piorou! No XP a versão é 5.1.
Lamentavelmente é bem pior. Pois é no WINXP que está dando esse resultado.

Por favor galera !! Quem fizer testes com o -GETWINDOWSINFO, favor postar seu resultado, mas coloque a versão do seu WINXP (utilize o comando VER).

Maligno escreveu:está separando os argumentos com vírgula, ao invés de ponto-e-vírgula. Aí sim, mesmo passando um handle válido, fará piscar sempre a janela atual. É isso?
You are right man ! Tinha razão, eu coloquei vírgula em lugar de ponto-e-vírgula. É muito comum esse tipo de erro. Very sorry !. Corrigí o meu fonte e ficou uma beleza !.

Quanto a:
Pablo escreveu:será que você não deveria transformar todos os parametros das outras funções para que sejam sempre passadas em modo CARACTER?. Digo isto, pela questão de concatenação no comando do RunWapiCmd() feito pelo usuário.


Maligno escreveu:Não há nenhum motivo para mexer nisso agora.


Eu estava errado ao pensar que o 2º parâmetro devia ser passado em modo caracter. Não tem problemas. A função FLASH da biblioteca está OK.

Ficam pendentes:

-GETWINDOWSINFO -> Em WINDOWS XP (versão: 5.1.2600)
-PRINT -> Rótulo de impressão em WIN98
-Uma função que detecte se o sistema atual está sendo executado no modo TEXTO ou JANELADO. Por falar desta outra função. Escreví pro Dave para saber se podia me dar uma luz. Ele entendeu a questão mas disse que não sabia como fazer. Mas deixei em aberto que se soubesse algo me comunicasse.

Desculpe insistir neste ponto:
Maligno escreveu:Depois de montada esta camada de abstração, qualquer relatório ficará fácil. É como se você criasse seus próprios drivers de impressão. Basta comutar para esta ou aquela impressora que toda a formatação mudará de acordo com as características da impressora escolhida.

Por isso que eu digo que é muito mais negócio montar uma LIB de abstração das características de cada impressora com a qual se trabalha.

Você tanto pode imprimir diretamente, embutindo os códigos de controle e formatação, (coisa que quase ninguém faz) como pode utilizar um gerador de relatórios (mais prático).


Então, Pablo escreveu:Esse gerador é fácil de conseguir e podemos usar junto com o nosso sistema em Clipper?.


Maligno escreveu:Sem a menor chance. Ele é totalmente vinculado ao ambiente Delphi/C++.


:( :'(

Você sabe como a biblioteca do TEXTO RICO funciona ? Será que ele não converte comandos de cada impressora segundo seu drive de impressão (DLL da impressora) ?.

http://www.caclipperwebsite.com/clipper_usb_tr.shtml

Coloquei so site, mas não é para fazer propagando para alguém. Seria para levantar a hipótese que há possibilidade de interpretação de comandos de impressão de acordo cada impressora. Mas também nã sei se esse produto tem o cadastro de algumas impressoras e que deva ser adicionado para cada nova impressora que surgir no mercado. Gostaria a opinão de você e do pessoal que tenha usado esse produto.

Um Clip-abraço

:)Pos

Re: WAPI.LIB

MensagemEnviado: 23 Jan 2007 17:38
por Maligno
Tinha razão, eu coloquei vírgula em lugar de ponto-e-vírgula. É muito comum esse tipo de erro. Very sorry !. Corrigí o meu fonte e ficou uma beleza !.

Exatamente por isso que eu insisto em que se utilize as funções de abstração para os testes, ao invés de utilizar o WAPI diretamente. Elas existem não só para facilitar, mas também para minimizar erros desse tipo. :)

Ficam pendentes:

-GETWINDOWSINFO -> Em WINDOWS XP (versão: 5.1.2600)
-PRINT -> Rótulo de impressão em WIN98
-Uma função que detecte se o sistema atual está sendo executado no modo TEXTO ou JANELADO. Por falar desta outra função. Escreví pro Dave para saber se podia me dar uma luz. Ele entendeu a questão mas disse que não sabia como fazer. Mas deixei em aberto que se soubesse algo me comunicasse.

Se houver meio de fazer isso através da API do Windows, será difícil encontrar. Não procurei mais, por falta de tempo. Vamos ver mais pra frente.

Você sabe como a biblioteca do TEXTO RICO funciona ? Será que ele não converte comandos de cada impressora segundo seu drive de impressão (DLL da impressora) ?.

Não conhecia. Vi o site agora. Me parece bem claro o que ele faz: monta um Rich Text e manda pra um programa qualquer imprimir.
Tudo na vida tem preço. Ao passo em que você não mais dependerá de conhecer os comandos dessa ou daquela impressora, você se verá sempre dependente de um programa Windows para interpretar e direcionar a impressão para o spooler. No meu caso particular (relatórios simples), me basta um conjunto de funções de abstração dos comandos básicos de impressão. No máximo para 2 ou 3 impressoras distintas.
Minha opinião: se você, em dado momento, for precisar de relatórios mais sofisticados, talvez seja hora de começar a pensar em mudar para um ambiente de programação verdadeiramente Windows.

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

WAPI.LIB

MensagemEnviado: 23 Jan 2007 19:43
por Pablo César
Maligno escreveu:talvez seja hora de começar a pensar em mudar para um ambiente de programação verdadeiramente Windows.
Dou inteira razão Maligno, acontece que tem certo programas em Clipper, que estão rodando, são muito bons, mas a tecnologia vem atropelando sem pedir licença e não gostamos de refazer nada. Mas que para alcançar alguns resultados que o Clipper, ja não mais oferece, nós somos obrigado a iventar... (como você sempre diz) => GAMBIARRAS.

Outra LIB que ja venho algum tempo querendo adquirir é o PAGE SCRIPT, mas a idéia de importar asusta muito a gente (por questão de impostos). Eu estaria disposto a pagar mas.. o frete ? mas o imposto de importação ? sei lá. Mas de todas formas dê uma olhada neste também:

https://www.lpcshop.com/cgi-win/shop/pr ... LIP&CASE=1

Enquanto tivermos oportunidade de dar um pouco de vida ao nosso tão desgastado Clipper, nós continuamos criando "GAMBIARRAS". Mas é gostoso programar em Clipper, ainda.

Um Clip-abraço, e esperemos mais novidades.

A você colega Maligno. Um grande abraço. Eu pelo menos, estou em dívida contigo. Deus te abenço e abençoe todos que ajudam os outros e por puro prazer e bondade, abrem mão e retribuem com idéias, com dedicação.

sds/Pablo :)Pos :{ :xau -:] :* :)) :D

Re: WAPI.LIB

MensagemEnviado: 24 Jan 2007 10:17
por Maligno
Mas que para alcançar alguns resultados que o Clipper, ja não mais oferece, nós somos obrigado a iventar... (como você sempre diz) => GAMBIARRAS.

É como dizem: "a necessidade é a mãe da gambiarra". :)))
Mas ainda assim, há muita gente que se contenta com os remendos e se acomoda. Esse é o maior perigo. Até porque, é muito mais fácil desenhar um contorno do que uma nova vida.

Outra LIB que ja venho algum tempo querendo adquirir é o PAGE SCRIPT, mas a idéia de importar asusta muito a gente (por questão de impostos). Eu estaria disposto a pagar mas.. o frete ? mas o imposto de importação?

Mas não é por download? Então não tem frete nem imposto.

Enquanto tivermos oportunidade de dar um pouco de vida ao nosso tão desgastado Clipper, nós continuamos criando "GAMBIARRAS". Mas é gostoso programar em Clipper, ainda.

Isso é bastante discutível (e polêmico). Mas se te dá prazer, quem sou eu pra contestar. :))

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

MensagemEnviado: 24 Jan 2007 13:56
por rochinha
Maligno

Voce disse nao estar conseguindo acessar alguns recursos externos a sessao virtual.

Dentro do diretorio de instalacao do VPC existem alguns .BAT que configurar algumas coisinhas e copiam arquivos e DLLs para o SYSTEM32 de uma olhadinha.

MensagemEnviado: 24 Jan 2007 15:01
por Maligno
Dentro do diretorio de instalacao do VPC existem alguns .BAT que configurar algumas coisinhas e copiam arquivos e DLLs para o SYSTEM32 de uma olhadinha.

Obrigado, Rochinha. Mas eu comentei que uso o VMWare. Não gostei muito do VPC.

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

MensagemEnviado: 24 Jan 2007 15:59
por sygecom
Maligno:

Baixei a WAPI.LIB atualizada e fui compilar e deu problema.....

 WAPI.LIB(APPTITLE)  :  'OL_95APPTI'  :  unresolved external


Toh usando o Windows xp com SP2...antes de eu baixar estava dando certo o que sera que pode ser ???


Abraços

MensagemEnviado: 24 Jan 2007 16:08
por Maligno
 WAPI.LIB(APPTITLE)  :  'OL_95APPTI'  :  unresolved external

Minhas desculpas. Não atualizei o README. Vou fazer isso.

O que ocorre é que, para fazer a função SetAppTitle() funcionar no Windows 98, foi necessária uma adaptação que utiliza essa função da OSLib. Se você não utiliza Windows 98, apenas ignore o erro e gere o executável normalmente (BLINKER EXECUTABLE NODELETE). Caso contrário, inclua a OSLib no seu script.

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

MensagemEnviado: 24 Jan 2007 16:48
por sygecom
Se você não utiliza Windows 98, apenas ignore o erro e gere o executável normalmente (BLINKER EXECUTABLE NODELETE). Caso contrário, inclua a OSLib no seu script.


Coloquei esse comando no meu SCRIPT e não resolveu ......

O sistema compila com o erro mas esta danda problema ainda quando uso o SETAPPTITLE("SISTEMA DO LEO") !!!

Aguardo um Retorno...Abraços !!!

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

MensagemEnviado: 24 Jan 2007 17:04
por Maligno
Coloquei esse comando no meu SCRIPT e não resolveu ......

Leu o novo README (parágrafo DEPENDÊNCIAS)?
Incluiu a LIB OSLib e CPMI? As duas são necessárias.

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

MensagemEnviado: 24 Jan 2007 18:11
por sygecom
Blz....Maligno.....Baixei e dei uma lida e agora fungo......Abraços e desculpa tah charopeando.....

Clip-Abraços

MensagemEnviado: 25 Jan 2007 15:20
por rochinha
Amiguinhos

"..isto aqui ta muito bom, isto aqui ta bom demais..."

Minha contribuição:

   PrinterSetup()
   PRNcPort   := PrnGetName()
   PRNcFile    := "notafisc.txt"
   PRNcSTAT := IsPrint(PRNcPort)
   FErase( PRNcFile )
   if PRNcSTAT = "Impressora OK"
      WaitRun( "notafisc.exe "+strzero(PN->IDPEDIDO), 7 )
      if file( PRNcFile )
         WaitRun( [WAPI -PRINT:"]+PRNcPort+[";]+PRNcFile+[;"Impressao";RESULTA.TXT], 7 )
      endif
   else
      MsgStop( "Impressora nao conectada" )
   endif


O codigo postado esta sendo usado em um aplicativo Fivewin e com exito fez o que outros exemplos não fizeram. Meu aplicativo executa um pequeno .EXE com a definição de uma nota fiscal de um cliente especifico( nota totalmente fora de padrões ) e gera a saida em .TXT com 156 colunas.

Usando comandos como COPY /B, NOTEPAD arquivo e outros estava obtendo falhas estranhas.

Vim acompanhando o tópico abaixo e pude fazer um teste com o famoso WAPI. As outras funções fazem parte do Fivewin e Harbour.

IsPrint.PRG
function IsPrint( QuePrinter )
   LOCAL nStatus
   DEFAULT QuePrinter := "LPT1:"
   nStatus := PrnStatus( QuePrinter )
   if     nStatus <        1 ; return "Impressora OK"
   elseif nStatus =        1 ; return "Impressora Pausada"
   elseif nStatus =        2 ; return "Impressora com Erro"
   elseif nStatus =        4 ; return "Impressora Deletando"
   elseif nStatus =        8 ; return "Impressora em Modo Bandeja"
   elseif nStatus =       16 ; return "Impressora Sem Papel"
   elseif nStatus =       32 ; return "Impressora em Modo Manual"
   elseif nStatus =       64 ; return "Impressora com Problema no Papel"
   elseif nStatus =      128 ; return "Impressora OffLine"
   elseif nStatus =      256 ; return "Impressora com IO Ativo"
   elseif nStatus =      512 ; return "Impressora Ocupada"
   elseif nStatus =     1024 ; return "Impressora Imprimindo"
   elseif nStatus =     2048 ; return "Impressora Memoria Lotada"
   elseif nStatus =     4096 ; return "Impressora Nao Instalada"
   elseif nStatus =     8192 ; return "Impressora Aguardando"
   elseif nStatus =    16384 ; return "Impressora Processando"
   elseif nStatus =    32768 ; return "Impressora Inicializando"
   elseif nStatus =    65536 ; return "Impressora em Atencao"
   elseif nStatus =   131072 ; return "Impressora Toner Baixo"
   elseif nStatus =   262144 ; return "Impressora Sem Toner"
   elseif nStatus =   524288 ; return "Impressora PAGE_PUNT"
   elseif nStatus =  1048576 ; return "Impressora Intervencao do Usuario"
   elseif nStatus =  2097152 ; return "Impressora Sem Memoria"
   elseif nStatus =  4194304 ; return "Impressora Tampa Aberta"
   elseif nStatus =  8388608 ; return "Impressora Servidor Desconhecido"
   elseif nStatus = 16777217 ; return "Impressora POWER_SAVE"
   endif

WAPI.LIB

MensagemEnviado: 25 Jan 2007 20:53
por Pablo César
Caro colega Maligno,

Voltando ao assunto sobre:
SyGeCom escreveu:existe alguma possibilidade de imprimir em modo CONDENSADO pela WAPI.LIB ???

Maligno escreveu:Tecnicamente sim. Mas eu não quero vincular o WAPI ao código de nenhuma impressora. Senão acabaria virando gambiarra. O melhor seria fazer uma LIB à parte, para abstração dos comandos de impressão. Nada difícil.


Lí um tópico do colega JMARCELO sobre como imprimir em impressoras USB em condensado. E o colega Wagner Nunes, explicou que o PRWIN dele transforma dentro de um arquivo gerado com comandos EPSON e que converte os comandos para a impressora instalada no WINDOWS seja USB HP3220, o que for (feito em xHarbour ???). Explica pro colega que: "não adianta tentar, estas impressoras não tem fontes padrão na memória o que impossibilita a impressão de programas MS-DOS...".

Eu acredito que é assim mesmo.´Só não entendí em tópico anterior você disse: "Não. Você precisa de documentação.", isso quando eu perguntei a você:
Pablo escreveu:gostaria de te perguntar MALIGNO, se no WINDOWS (creiria através das DLLs) que acompanha cada impressora, se te como saber quais seriam os comandos para fazer por exemplo: condensado, enfatizado, expandido. Tem como ?


Será que seria possível fazer uma nova função para converter a impressão ?

sds/Pablo *-)

Re: WAPI.LIB

MensagemEnviado: 26 Jan 2007 07:07
por Maligno
Confirmo: você precisa conhecer a documentação (os códigos de impressão) a respeito de cada impressora para adaptar seu relatório corretamente. O que o programa do Wagner faz, como ele mesmo disse, é converter os comandos padrão da Epson embutidos no seu relatório, para que estes se adaptem à impressora selecionada para imprimir. É uma abordagem válida, embora eu não goste dela. Se você tiver, como eu disse antes, uma boa biblioteca que lhe permita atender às características de cada impressora (abstração), você consegue fazer isso no seu próprio programa, com a vantagem de poder adaptá-la a uma possível necessidade especial, sem ficar travado pela abordagem feita por um programa externo. Realmente não vejo necessidade de incluir essa conversão no WAPI, pois essa tarefa pode ser melhor feita fora dele. A boa notícia é que é uma coisa simples de fazer. Se for bem feita, fica ótimo.

"não adianta tentar, estas impressoras não tem fontes padrão na memória o que impossibilita a impressão de programas MS-DOS...".

Não entendi o que você quis dizer com esta frase. Ela não faz sentido, pois ela trata de duas coisas bem distintas. Toda impressora tem fontes internas, armazenadas no BIOS. E isso nada tem a ver com o fato dela imprimir ou não em DOS. O que dita essa limitação é apenas e tão somente a interface de comunicação, desde que o software acompanhe essa limitação. Ou seja, mesmo USB, existindo um driver feito especialmente para isso, o DOS imprimiria normalmente por essa interface. Isso não existe (que eu saiba) não por uma limitação técnica, mas por uma (in)conveniência comercial. Nenhum fabricante tem interesse em DOS.

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


PS: Se não me falha a memória, e respondendo à sua pergunta, o Wagner comentou, em certa ocasião, que fez o PRWin em Delphi.

MensagemEnviado: 26 Jan 2007 09:10
por sygecom
Maligno, Qual seria as chance de vc fazer uma caridade para todos desse forum e desenvolver essa tal LIB de (abstração de características de impressoras) para todos aqui no forum passar a usar no bom e velho clipper....não quero ser chato....mas toh sendo cara-de-pau eu sei......mas quero que saiba q adimiro muito o que jah fez por esse forum......e que caso vc esteja se sentindo prejudicado de alguma certa forma..eu me disponho a pagar pelo desenvolvimento dessa LIB...

Grande Abraço...... -:] :xau

MensagemEnviado: 26 Jan 2007 10:01
por Maligno
sygecom escreveu:Maligno, Qual seria as chance de vc fazer uma caridade para todos desse forum e desenvolver essa tal LIB

Chance zero. :)
Não é por uma questão de pagamento pelos serviços. É por falta de tempo mesmo. Mas se serve de consolo, estou fazendo um sub-sistema de impressão com esse esquema de abstração (o cliente já está pagando bem pra isso). Não é nada completo porque é pra um cliente só (meu último programa Clipper - assim espero) e ele usa apenas HP (deskjet/laser) e Epson LX. Até funcionava bem com outro esquema que eu tinha, mas o infeliz comprou algumas impressoras HP/PCL e eu não pude ampliar a coisa do jeito que precisava. Ficou mais barato refazer.
Portanto, como é coisa simples, vou contemplar apenas os códigos realmente necessários para atender as minhas necessidades. Mas nada impede que esse esquema possa ser ampliado e/ou adaptado posteriormente. Estou fazendo de forma que fique bem fácil dar manutenção. Já previ, inclusive, supressão total dos códigos, para o caso de se montar um preview, que é outra coisa que estou desenvolvendo.

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

MensagemEnviado: 26 Jan 2007 10:27
por sygecom
Mas se serve de consolo, estou fazendo um sub-sistema de impressão com esse esquema de abstração (o cliente já está pagando bem pra isso). Não é nada completo porque é pra um cliente só (meu último programa Clipper - assim espero) e ele usa apenas HP (deskjet/laser) e Epson LX.


Maligno,Não sei se entendi direito....vc esta desenvolvendo um sub-sistema de impressão...apenas pra (deskjet/laser) e Epson LX.....minha duvida é a seguinte esse seu sub-sistema de impressão faz impressão condensada nas impressoras citadas acima ? se sim qual a possibilidade de vc compartilhar essa ferramenta aqui no forum? ou ainda incluir essa ferramenta na WAPI.LIB ?

Obs:Conforme vc mesmo disse o ideal seria fazer uma LIB a parte somente para essa função....mas pensei comigo....como só vai ter para essas duas impressora mesmo não custa nd colocar....usa quem quer.....Toh certo ou toh errado ??

Abraços......

MensagemEnviado: 26 Jan 2007 10:36
por Maligno
Maligno,Não sei se entendi direito....vc esta desenvolvendo um sub-sistema de impressão...apenas pra (deskjet/laser) e Epson LX.....minha duvida é a seguinte esse seu sub-sistema de impressão faz impressão condensada nas impressoras citadas acima ?

Só estou incluindo os códigos para essas duas impressoras. Se for o caso, amanhã ou depois poderão ser incluídos os códigos de quaisquer impressoras.
Aliás, apenas para informar corretamente: estou incluindo os códigos de PCL e ESCP; HPs e EPSONs (matriciais de impacto), respectivamente.

se sim qual a possibilidade de vc compartilhar essa ferramenta aqui no forum? ou ainda incluir essa ferramenta na WAPI.LIB ?

Assim que estiver pronto posso compartilhar. Mas não vou incluir no WAPI. Será uma LIB à parte. O WAPI tem uma destinação totalmente focada em Windows. Não gosto de misturar as coisas. :)

Obs:Conforme vc mesmo disse o ideal seria fazer uma LIB a parte somente para essa função....mas pensei comigo....como só vai ter para essas duas impressora mesmo não custa nd colocar....usa quem quer.....Toh certo ou toh errado ??

Certo. :)

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

MensagemEnviado: 26 Jan 2007 11:33
por sygecom
Assim que estiver pronto posso compartilhar. Mas não vou incluir no WAPI. Será uma LIB à parte. O WAPI tem uma destinação totalmente focada em Windows. Não gosto de misturar as coisas.


Blz.....Ficamos no aguardo dessa nova LIB.....e mais uma vez o forum só tem a agradecer......


Abraços

Re: WAPI.LIB

MensagemEnviado: 30 Jan 2007 10:54
por Maligno
Eu tinha dito escreveu:Não é no WIN95 que estou testando... é no WIN98 como eu disse:
Perdão, mencionei é no WIN98 sendo que eu devia ter dito é no WINXP, desculpe tou ficando louco com a versão do WINDOWS. Mas acredite, a questão toda é no meu WINXP talvez, mas eu estou com antivirus (tou limpo) não sei se isso acontece com outro colega, seria bom alguém mais opinar em outro XP.

Conseguiu resolver essa questão? Ou continua informando Windows 95 ao invés de XP?

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

WAPI.LIB

MensagemEnviado: 31 Jan 2007 06:38
por Pablo César
No WINXP (versão: 5.1.2600) no arquivo gerado, continua dando SEMPRE o mesmo resultado: 9X,Windows 95,,4.0.950 com a função -GETWINDOWSINFO. Os colegas não deram alguma opinião sobre algum caso. Seria desinteresse ou não estaria ocorrendo o mesmo com eles ?. (Vou abrir um novo tópico para debater esta questão).

Não sei se você chegou a alterar algo mas, pelo ultimo WAPI que você disponibilizou aqui no FORUM, ainda continuam essas pendências. E inclusive queria também sugerir, que ora na linha de comando (sem parâmetros) o WAPI.EXE ou ora seja também através de uma função, que pudesse saber a versão do próprio WAPI.

Como eu disse anteriormente, ficam pendentes:

-GETWINDOWSINFO -> Em WINDOWS XP (versão: 5.1.2600)
-PRINT -> Rótulo de impressão em WIN98
-Uma função que detecte se o sistema atual está sendo executado no modo TEXTO ou JANELADO.
-Função para ver a versão do proprio WAPI
-Velocidade de execução do WAPI no WIN98

Também gostaria de retornar a este assunto:
Maligno escreveu:Toda impressora tem fontes internas, armazenadas no BIOS. E isso nada tem a ver com o fato dela imprimir ou não em DOS.
Sei disto, porém gostaria de saber se haveria algum jeito de extrair esta informação (comandos de impressão) ?. Porque todos nós sabemos que como impressoras LEXMARK e essas novas impressoras que tem no mercado, não tem suporte para conseguir este tipo de "documentação".

Um clip-abraço :xau [/quote]

Re: WAPI.LIB

MensagemEnviado: 31 Jan 2007 10:22
por Maligno
-PRINT -> Rótulo de impressão em WIN98

O que tem de errado com a impressão de Windows 98?

-Velocidade de execução do WAPI no WIN98

Continua muito lento?

Maligno escreveu:Toda impressora tem fontes internas, armazenadas no BIOS. E isso nada tem a ver com o fato dela imprimir ou não em DOS.
Sei disto, porém gostaria de saber se haveria algum jeito de extrair esta informação (comandos de impressão) ?

Não dos drivers de impressão. Muito menos da própria impressora. Só por meio da documentação do fabricante.
Não confunda fontes (Arial, Letter Ghotic, etc) com códigos de impressão (configuração, formatação, etc). São coisas totalmente diferentes.

Porque todos nós sabemos que como impressoras LEXMARK e essas novas impressoras que tem no mercado, não tem suporte para conseguir este tipo de "documentação".

É sempre possível conseguir isso pela Internet. O Google taí pra isso. :)
Tive problema com os códigos PCL, conforme comentei em outra thread. Mas resolvi e já está funcionando conforme o planejado. Pra qualquer outra marca o caminho é o mesmo.

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

MensagemEnviado: 31 Jan 2007 12:13
por Maligno
Em tempo: com relação à visualização da versão corrente do WAPI, não vejo realmente muita necessidade. Se você utilizar as funções de abstração, ao invés do WAPI diretamente, não terá problema. Além do que, é só acompanhar a versão pela documentação, ou mesmo pela data dos arquivos.

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

Re: WAPI.LIB

MensagemEnviado: 01 Fev 2007 18:05
por Pablo César
Maligno escreveu:O que tem de errado com a impressão de Windows 98?
Conforme mencionei na minha mensagem anterior:

Só tem um inconveniente no WIN98. Mesmo passando todos os parâmetros, o banner (rôtulo) não é sempre que aparece na fila de impressão quando é acessado no menu (iniciar,impressora,double click).

Fiz uma outra experiência mando imprimir sem os quatros parametros (tipo, fazendo um "reset") e tento mais outra vez, mas desta vez com os quatro parametros, daí imprime beleza e desta vez aparece o banner na fila de impressão. Acho que deve ser, que alguma coisa fica residente ou que ignorasse o banner na fila de impressão. Melhor dito, banner e toda descrição da fila de impressão. Mas imprime toda vez que é passado os quatro parametros, mas nem sempre mostra o banner na fila de impressão da impressora.

Ja no WINXP, não tem problema desse tipo.


Maligno escreveu:Continua muito lento?
Sim.
em WIN98 fica lento a sua execução (de 3 a 4 segundos)


Maligno escreveu:Não confunda fontes (Arial, Letter Ghotic, etc)
Maligno, foi você mesmo que mencionou a palavra "fontes".

Maligno escreveu:com códigos de impressão (configuração, formatação, etc). São coisas totalmente diferentes.
E eu não estou confundido, pois a mudança de tipo de fontes, também é feito por comandos de impressão (pelo menos isso ja venho fazendo alguns anos com as impressoras HP). Até padrão de caracteres ASCII, também é feito pelos comando de impressão.

Maligno escreveu:Em tempo: com relação à visualização da versão corrente do WAPI, não vejo realmente muita necessidade. Se você utilizar as funções de abstração, ao invés do WAPI diretamente, não terá problema. Além do que, é só acompanhar a versão pela documentação, ou mesmo pela data dos arquivos.
OK, foi apenas uma sugestão.

Um clip-abraço :)Pos

Re: WAPI.LIB

MensagemEnviado: 01 Fev 2007 20:07
por Maligno
Fiz uma outra experiência mando imprimir sem os quatros parametros (tipo, fazendo um "reset") e tento mais outra vez, mas desta vez com os quatro parametros, daí imprime beleza e desta vez aparece o banner na fila de impressão. Acho que deve ser, que alguma coisa fica residente ou que ignorasse o banner na fila de impressão. Melhor dito, banner e toda descrição da fila de impressão. Mas imprime toda vez que é passado os quatro parametros, mas nem sempre mostra o banner na fila de impressão da impressora.

Por banner eu entendo que você quer dizer título. Bom, isso já me aconteceu com o Windows XP. Foi uma vez só. Uma "engasgada". Como não voltou a repetir, acho que é uma esquisitice do Windows. Com você isso acontece sempre? Quando manda imprimir, usa o nome da impressora ou a porta?

Maligno escreveu:Não confunda fontes (Arial, Letter Ghotic, etc)
Maligno, foi você mesmo que mencionou a palavra "fontes".

Ok. Me desculpe pela insistência. :)

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

Re: WAPI.LIB

MensagemEnviado: 03 Fev 2007 11:24
por Pablo César
Maligno escreveu:Por banner eu entendo que você quer dizer título.
Isto mesmo. A descrição da fila de impressão que aparece quando entramos na impressora (iniciar,impressora,duplo-click)

Maligno escreveu:Com você isso acontece sempre?
Isto acontece 60% das vezes no WIN98, no WINXP o titulo da fila de impressão faz (digamos sempre).

Maligno escreveu:Quando manda imprimir, usa o nome da impressora ou a porta?
Coloco entre aspas o nome certinho da impressora padrão, isto é o nome tal qual com minusculas e maiusculas. Ex.: "Epson LX-300"

Maligno escreveu:Não confunda fontes ...Ok. Me desculpe pela insistência. :)
Tudo bem Maligno. Eu também sou insistente, pois gostaria de saber como é feito nas linguagens "for Windows", é dizer como é feito a instrução no proprio código fonte, que aquela determinada linha deveria ser impresso em NEGRITO, digamos. Porque imagino que essa instrução serve para qualquer tipo de impressora. Se conseguissemos um jeito para que tais [instruções] sejam re-interpretadas conforme instrução do proprio drive do WINDOWS... daí seria genial !.

Na questão da função -GETWINDOWSINFO (no meu WINXP), nas "Propriedades do Sistema" do ícone "Sistema" do Painel de Controle, me aparece:

Microsoft Windows XP
Professional
Versão 2002
Service Pack 2

Pois é, gostaria tirar essa dúvida. Porque o meu WINDOWS XP, está beleza, sem problemas nenhum a única diferença é a descrição doControle e o resultado do -GETWINDOWSINFO que diz: 9X,Windows 95,,4.0.950 . Mas acredito que se forem feito outros testes na mesma condição iremos descobrir.

Um clip-abraço :(

Re: WAPI.LIB

MensagemEnviado: 03 Fev 2007 14:12
por Maligno
Maligno escreveu:Com você isso acontece sempre?
Isto acontece 60% das vezes no WIN98, no WINXP o titulo da fila de impressão faz (digamos sempre).

Isso é Windows. Quem vai entender? Nem a própria MS explica. :))))

Coloco entre aspas o nome certinho da impressora padrão, isto é o nome tal qual com minusculas e maiusculas. Ex.: "Epson LX-300"

Pode ser bobagem, mas tenta trocar o nome da impressora para "#", pra própria função pegar a impressora default. Provavelmente vai dar no mesmo. Mas de repente,...

gostaria de saber como é feito nas linguagens "for Windows", é dizer como é feito a instrução no proprio código fonte, que aquela determinada linha deveria ser impresso em NEGRITO, digamos. Porque imagino que essa instrução serve para qualquer tipo de impressora.

Negativo. Cada impressora é, pela sua própria natureza, um computador como outro qualquer. Tem processador, BIOS, memória, I/O, etc. A diferença é que a impressora é um computador dedicado a uma única tarefa. Para que ela funcione a contento, cada fabricante especifica um conjunto de comandos de impressão, ou "instruções", que são interpretadas pelo processador, assim que a "stream" de dados começa a chegar. Cada fabricante tem seu próprio conjunto de "instruções". Antigamente até havia impressora (Citizen matricial) que aceitava os códigos da Epson, que era a marca mais popular (e ainda é, para matriciais de impacto). Mas isso, se hoje ainda existir, é muito raro. Portanto, não dá pra generalizar.

Mas, como eu já disse antes, é fácil resolver esse problema, desde que você se disponha a implementar uma LIB com funções de abstração que forneçam os códigos de impressão da impressora previamente selecionada. Um exemplo do que eu já fiz:

set date british
set century on

set margin to 5
set printer to "TST.PRN"
set device to print

SetPrinter(_kPRT_MODEL_PCL5e)

@prow(),0 say _kPRT_CMD_RESET             +;
              _kPRT_ORIENTATION_PORTRAIT  +;
              _kPRT_LINE_SPACING_8LPI     +;
              _kPRT_PAPER_SIZE_A4         +;
              _kPRT_CHARACTER_SET_PC850   +;
              _kPRT_COL_SPACING_FIXED     +;
              _kPRT_PITCH_17CPI           +;
              _kPRT_STYLE_SOLID           +;
              _kPRT_STROKE_BOLD           +;
              _kPRT_TYPEFACE_LETTER_GOTHIC

c := 0
for l := 1 to 84
    c := if(c=132,1,c+1)
    @prow()+1,0 say StrZero(l,3) + " " +;
                    if(l%2=0, _kPRT_STROKE_THIN, _kPRT_STROKE_BOLD) +;
                    Replicate("X",c)
next
@prow(),pcol() say _kPRT_CMD_EJECT

set device to screen
set printer to

if PrintFile("#","TST.PRN")
   ? "Impressao ok!"
else
   ? "Erro na impressão"
end
?


Isso é apenas um teste. Ainda não acabei. Esse código é só pra ter uma idéia. Neste exemplo eu configurei pra usar PCL, mas se usasse Epson matricial de impacto, não teria que mudar nada nesta configuração, já que o próprio sistema faz os ajustes, conforme ele vai recebendo os comandos. Exemplo: a LX300 não tem fonte "Letter Gothic". Neste caso ele usará "Sans Seriff" ao receber o comando para "Letter Gothic". Simples e limpo.

Na questão da função -GETWINDOWSINFO (no meu WINXP), nas "Propriedades do Sistema" do ícone "Sistema" do Painel de Controle, me aparece:

Microsoft Windows XP
Professional
Versão 2002
Service Pack 2

Difícil de entender esse tipo de coisa. Imaginei que o Windows utilizasse a mesma função de busca de versão que eu utilizei no WAPI. Pelo jeito eles utilizaram outro sistema. Nem imagino qual, já que na documentação que eu tenho, que é completa, não há outra forma de fazer isso.

Pois é, gostaria tirar essa dúvida. Porque o meu WINDOWS XP, está beleza, sem problemas nenhum a única diferença é a descrição doControle e o resultado do -GETWINDOWSINFO que diz: 9X,Windows 95,,4.0.950 . Mas acredito que se forem feito outros testes na mesma condição iremos descobrir.

Não tenho tanta certeza disso.
Esta semana não foi possível, mas ferei aquele teste nas máquinas de um cliente na segunda-feira. Depois comentarei o resultado.

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

WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 06 Fev 2007 17:10
por Pablo César
Maligno escreveu:Difícil de entender esse tipo de coisa. Imaginei que o Windows utilizasse a mesma função de busca de versão que eu utilizei no WAPI. Pelo jeito eles utilizaram outro sistema. Nem imagino qual, já que na documentação que eu tenho, que é completa, não há outra forma de fazer isso.
Estive buscando uma das tantas alternativas para identificar a versão do Windows e achei isto da propria Microsoft:

Extrai deste link: http://support.microsoft.com/kb/220143/pt-br

Em um computador execução Windows 9 X,
HKEY_LOCAL_MACHINE / software / Microsoft / Windows / CurrentVersion / ProductID
Ou
Em um computador execução Windows NT,
HKEY_LOCAL_MACHINE / software / Microsoft / WindowsNT / CurrentVersion / ProductID


Mas em vez de pegar o objeto ProductID pegariamos o ProductName. Só não sei se funcionaria em todas as versões do Windows.

Maligno escreveu:Pode ser bobagem, mas tenta trocar o nome da impressora para "#", pra própria função pegar a impressora default. Provavelmente vai dar no mesmo. Mas de repente,...
Lamentavelmente não funcionou assim como colocando o nome da impressora.

Bem eu não sei mais, como posso te ajudar para detectar este problema no WAPI. Mas se for esta a questão, irei incluir na BATCH que chama meu aplicativo o comando do proprio WINDOWS. O comando VER > C:WINVER.TXT. Desta forma terei sempre esse arquivo em cada estação conforme sua versão.

Hoje me aconteceu outra coisa engraçada. Que não sei se foi coincidência ou teria algo a ver: Executei a função -SETAPPTITLE do WAPI em modo "TELA CHEIA" e não funcionou, mas quando passei para modo JANELADO funcionou. Daí se me ocorre uma idéia, que ser for positiva, teremos talvez uma solução para saber se estamos executando em TELA CHEIA ou JANELADO. Haveria como obter se o título ou qualquer item da JANELA-WINDOWS estiver presente ?.

Seria muito bom, se houvesse como. espero que haja diferença entre os dois modos de exibição de tela para com estes itens.

Um clip-abraço :)Pos :|<

Re: WAPI - APLICATIVO para MS-DOS

MensagemEnviado: 06 Fev 2007 17:57
por Maligno
Maligno escreveu:Difícil de entender esse tipo de coisa. Imaginei que o Windows utilizasse a mesma função de busca de versão que eu utilizei no WAPI. Pelo jeito eles utilizaram outro sistema. Nem imagino qual, já que na documentação que eu tenho, que é completa, não há outra forma de fazer isso.
Estive buscando uma das tantas alternativas para identificar a versão do Windows e achei isto da propria Microsoft:

Pois é daí que aquela função deve pegar os dados. A idéia é justamente usar a função para que não seja necessário ir até o Registry, neste ou naquele endereço, conforme a versão do Windows. É a vantagem da abstração.
Aliás, testei hoje em cinco computadores com XP e Windows98. Em todas as informações de versão apareceram corretamente. Testei também as impressões e tudo foi impresso como esperado. Sem erro.

Maligno escreveu:Pode ser bobagem, mas tenta trocar o nome da impressora para "#", pra própria função pegar a impressora default. Provavelmente vai dar no mesmo. Mas de repente,...
Lamentavelmente não funcionou assim como colocando o nome da impressora.

Não sei mais o que dizer. Não tive erro algum que me preocupasse. Só aquela "engasgada" que comentei. Mas foi só uma vez.

Aliás, relembrando algo que você tinha dito....
Fiz uma outra experiência mando imprimir sem os quatros parametros (tipo, fazendo um "reset") e tento mais outra vez, mas desta vez com os quatro parametros, daí imprime beleza e desta vez aparece o banner na fila de impressão. Acho que deve ser, que alguma coisa fica residente ou que ignorasse o banner na fila de impressão.

Quando você manda pro WAPI menos parâmetros do que ele espera, ele simplesmente não faz nada. Só retorna, silenciosamente, sem reportar erro. Isso não "reseta" nada. Nem poderia, já que uma próxima execução do WAPI vai invocar uma nova instância do executável, que nada tem a ver com a instância previamente criada.

Bem eu não sei mais, como posso te ajudar para detectar este problema no WAPI. Mas se for esta a questão, irei incluir na BATCH que chama meu aplicativo o comando do proprio WINDOWS. O comando VER > C:WINVER.TXT. Desta forma terei sempre esse arquivo em cada estação conforme sua versão.

É uma alternativa. Mas há outra: usar o WAPI para recuperar aqueles dados do Registry e interpretá-los você mesmo. Claro que, neste caso, você terá que modificar a função SetAppTitle().

Hoje me aconteceu outra coisa engraçada. Que não sei se foi coincidência ou teria algo a ver: Executei a função -SETAPPTITLE do WAPI em modo "TELA CHEIA" e não funcionou, mas quando passei para modo JANELADO funcionou. Daí se me ocorre uma idéia, que ser for positiva, teremos talvez uma solução para saber se estamos executando em TELA CHEIA ou JANELADO. Haveria como obter se o título ou qualquer item da JANELA-WINDOWS estiver presente ?.

Comigo funciona normalmente no modo tela cheia, tanto no XP (usando o WAPI) como no Windows 98 (usando a OSLib).

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

WAPI

MensagemEnviado: 06 Fev 2007 18:36
por Pablo César
MALIGNO. Could you be answered my question, please ?

Haveria como obter se o título ou qualquer item da JANELA-WINDOWS (o X, propriedades, tamnho, etc) estiver presente na sessão vigente ?.

Seria apenas uma idéia para a questão de JANELA CHEIA ou JANELADO

Apreciaria, que fizesse alguns testes a respeito.

:)Pos

Re: WAPI

MensagemEnviado: 06 Fev 2007 19:21
por Maligno
Haveria como obter se o título ou qualquer item da JANELA-WINDOWS (o X, propriedades, tamnho, etc) estiver presente na sessão vigente ?.

Não entendi muito bem sua pergunta. Obter o título? Se for, GetAppInfo() faz isso. Se não for, reformule a pergunta pra que eu entenda melhor.

Seria apenas uma idéia para a questão de JANELA CHEIA ou JANELADO

Acho que não será por aí.

Apreciaria, que fizesse alguns testes a respeito.

Fiz o teste da alteração do título em tela cheia e janela. Ambas as formas funcionaram corretamente. Logo, não há diferença. E se não há diferença, não há forma de utilizar esse método para descobrir qual o modo vigente: tela cheia ou janela.

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

WAPI - SETTASKBUTTON

MensagemEnviado: 07 Fev 2007 05:53
por Pablo César
Testei o funcionamento do SETTASKBUTTON no WIN98 e WINXP. Funciona muito bem e identicamente em ambas plataformas, mas tenho que informar algumas caracteristicas.

1. Quando testo esta função em modo JANELADO, funciona de acordo o esperado. Isto é, a janela desaparece visualmente. E quando é executada a mesma função com opção SHOW;<Nº HANDLE>, retorna visivel. Até aqui tudo normal.

2. Quando executo esta mesma função em "TELA CHEIA", não desaparece. Até devo entender que porque não tem JANELA-WINDOWS. Certo ?.

3. Após execução do SETTASKBUTTON em TELA CHEIA e não ter desaparecido, pressiono a tecla ALT-ENTER para mudar seu modo de exibição para modo JANELADO. Observo que ainda continua a sessão sem ter se escondido.

4. Faço outro teste, similar ao item 3. Executo a função SETTASKBUTTON em TELA CHEIA e observo ainda que a sessão não desapareceu. Só que desta vez pressiono a tecla do WINDOWS estando na TELA CHEIA. Daí que a sessão desaparece.

Este comportamento, apesar que diferenciado pelo acionamento da tecla WINDOWS, me faz pensar que ainda existe alguma luz no túnel. Que com teu conhecimento sobre este assunto, creio eu, que possamos chegar algum resultado para a criação de uma nova função em que determine se a sessão está sendo executada em modo JANELADO ou TELA CHEIA.

E é agora que poderei esclarecer melhor a seguinte dúvida sobre o meu questionamento anterior:
Maligno escreveu:Se não for, reformule a pergunta pra que eu entenda melhor.
Se a função SETTASKBUTTON funciona diferentemente na TELA CHEIA e no JANELADO, e pudesse dar o retorno de que ora foi executado com sucesso ou não. Então, você teria o mesmo caminho para criar uma outra função que pudesse determinar se está sendo executado em modo JANELADO ou TELA CHEIA.

É com esta função que deu para demostrarte que há diferença de resultado entre modo JANELADO e TELA CHEIA. Mas agora espero que você tenha captado a idéia e espero que você a torne possível com teu conhecimento em BCC.

Aguardo resultados do teus testes e seus comentários e desejo a você muita luz nesta questão.

Um clip abraço :)Pos :xau :-´

Re: WAPI - SETTASKBUTTON

MensagemEnviado: 08 Fev 2007 10:06
por Maligno
É com esta função que deu para demostrarte que há diferença de resultado entre modo JANELADO e TELA CHEIA. Mas agora espero que você tenha captado a idéia e espero que você a torne possível com teu conhecimento em BCC.

Eu já sabia dessa particularidade. Mas realmente, por aí não vai dar para descobrir qual o modo da janela DOS. Ou melhor, até deve ser possível, mas por algum artifício tão ou mais complicado do que usar a API do Windows. Por enquanto ainda não sobrou tempo suficiente pra ir atrás disso. O máximo que posso dizer é que sua idéia, até tem sentido, mas poderia dar mais trabalho. E, na minha opinião, esse não é o método mais indicado para detectar o modo. Eu não acho boa idéia confiar numa peculiaridade do Windows para executar uma tarefa que deveria ser executada pela API(se é que é).

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

WAPI - FULLSCREEN

MensagemEnviado: 10 Fev 2007 18:39
por Pablo César
Maligno escreveu:por aí não vai dar para descobrir qual o modo da janela DOS
Maligno, eu acho que a intenção não é saber se é janela DOS ou não e sim se está em modo JANELA ou TELA INTEIRA.

Sei que mesmo em modo gráfico também dá para abrir uma sessão em modo TELA INTEIRA. Isto é muito usado na apresentação das telas de video-games.

Então a questão é saber se é modo janela ou não. Quem sabe o programadores para video-games, tenham mais intimidade com isto. Pois eu estive vendo isto no seguinte: http://www.codeproject.com/useritems/Wi ... screen.asp

Não sei, como ajudar. Mas confesso que você as vezes me deixa desanimado. Só me resta ter esperanças para que você não abandone a idéia e continue se informando. Desculpe a minha insistência, você ja fez muito por nós.

Um clip-abraço ! :)Pos :D :{

Re: WAPI - FULLSCREEN

MensagemEnviado: 10 Fev 2007 19:57
por Maligno
Maligno escreveu:por aí não vai dar para descobrir qual o modo da janela DOS
Maligno, eu acho que a intenção não é saber se é janela DOS ou não e sim se está em modo JANELA ou TELA INTEIRA.

Você se confundiu. Eu não disse nada sobre ser DOS ou não, até porque, é óbvio que é. Com modo da janela DOS eu quis dizer: se janela ou tela cheia.

Sei que mesmo em modo gráfico também dá para abrir uma sessão em modo TELA INTEIRA. Isto é muito usado na apresentação das telas de video-games.

Isso porque a comutação para o modo gráfico em DOS automaticamente força a janela para tela cheia. Inclusive, uma função que uso faz exatamente isso para comutar para tela cheia. Ela aciona o modo gráfico (isso expande a janela) e depois comuta para o modo texto 80x25.

Então a questão é saber se é modo janela ou não. Quem sabe o programadores para video-games, tenham mais intimidade com isto. Pois eu estive vendo isto no seguinte: http://www.codeproject.com/useritems/Wi ... screen.asp

Não tenha muita esperança. Saber o "estado" da janela DOS é uma necessidade de pouquíssima gente, pelo que percebi nas pesquisas que fiz na Net. E a coisa piora com o passar do tempo, já que quem trabalhava com DOS está migrando para Windows (ou Linux) GUI. (quase) Ninguém mais quer saber de modo texto. Só os reacionários. :)

Não sei, como ajudar. Mas confesso que você as vezes me deixa desanimado. Só me resta ter esperanças para que você não abandone a idéia e continue se informando. Desculpe a minha insistência, você ja fez muito por nós.

Eu continuei procurando. Até achei um esquema, através de uma interrupção do DOS, que informa justamente qual é o modo da janela DOS, do jeito que seria necessário. Mas para funcionar, isso dependeria da construção de um VxD, e apenas nos Windows 9x. Assim não dá. Mas acredite: é raríssimo encontrar alguém que tenha essa mesma necessidade. As mensagens que encontrei a respeito eram de 1993 até 1997, mais ou menos. E normalmente ninguém respondia. Quando respondia dava pista errada.

Sinto muito se eu te dou um "banho de água fria" de vez em quando, mas tenho de ser honesto com você: acho que vai ser difícil resolver esse problema. O próprio Dave Pearson "pulou", conforme você comentou.

Mas pelo menos o WAPI tem muitos outros bons recursos. Aliás, estou acrescentando outro que um colega me pediu. Não faria se não fosse algo simples: inserir informações (textos) no ClipBoard. Acho que vou fazer amanhã, se a preguiça permitir. :)))

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

API do Windows

MensagemEnviado: 13 Fev 2007 10:46
por Pablo César
Sabe MALIGNO, a esperança é a última que morre. Sei que sou reacionário. Mas é porque o meu sistema em DOS que já é bom, poderia ficar ainda melhor com uma ajudinha extra. E a emigração, é uma coisa que exige muito tempo, que passa por várias etapas. Talvez esta, seja a primeira: de reconhecer as limitações em DOS. Mas insistindo mais um pouco, veja o que encontrei na internet: http://www.frontiernet.net/~fys/chkwin.htm

Gostaria de saber se você entendeu o conteúdo disto, que trata de 2 exemplos e que acho que poderia esclarecer melhor dois itens (o da versão Windows e se está em modo janelado). Poderias me confirmar o que eu entendí, por favor ?.

Dentro deste mesmo link, aponta para um outro, no qual aborda e justifica a necessidade de saber a versão do Windows. Talvez este outro tópico, venha acescentar alguma coisa no seu conhecimento. Dê uma olhada: http://www.frontiernet.net/~fys/docs/apj_2004_144.pdf

A outra função sobre o CLIP-BOARD (áera de transferência) que você estaria desenvolvendo, também seria de grande ajuda e todos nós agradecemos.

Um clip-abraço :)Pos

Re: API do Windows

MensagemEnviado: 13 Fev 2007 14:13
por Maligno
Sei que sou reacionário.

Reacionário é aquele que recusa, por opção, a modernidade. Se você almeja a modernidade, mas no momento não pode ir a seu encontro, você não é reacionário. É apenas vítima das circunstâncias. :)

Gostaria de saber se você entendeu o conteúdo disto

Não só entendi como já tinha visto algo parecido, conforme comentei na minha mensagem imediatamente anterior. E testei essas novas abordagens, de novo. Mas não dá certo. O primeiro link trata de um esquema que retorna a versão do Windows e, ao final, se está em Windows ou DOS puro. O primeiro código não ajudou. O segundo sequer funcionou. Acusa DOS puro no Windows (98 ou XP) e em DOS puro também.
No que diz respeito ao nosso problema principal: detectar se modo janela ou tela cheia, esses links não ajudaram em nada, infelizmente. Até porque, se o código testado ajudasse, não traria informações acerca do modo de visualização da janela DOS.

A outra função sobre o CLIP-BOARD (áera de transferência) que você estaria desenvolvendo, também seria de grande ajuda e todos nós agradecemos.

Já está pronto e testado. Só não documentei ainda. Eu aviso quando tiver subido o arquivo pronto.

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

MensagemEnviado: 15 Fev 2007 21:57
por Maligno
Eis a relação atualizada de switches do utilitário WAPI, sendo marcados com asteriscos os novos, para manipulação do Clipboard do Windows.

  -DELETEREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
  -FLASH:<times>[;<handle>]
  -GETAPPSINFO:<resultFile>
* -GETCLIPBOARD:<resultFile>
  -GETDEFPRINTER:<resultFile>
  -GETHDINFO:<resultFile>
  -GETMYHANDLE:<resultFile>
  -GETPRINTERS:<resultFile>
  -GETWINDOWSINFO:<resultFile>
  -HIBERNATE
  -PLAYWAVE:<source>
  -POWEROFF
  -PRINT:<printerName>;<inputFile>;<reportTitle>;<resultFile>
  -READREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
  -REBOOT
  -SETAPPTITLE:<title>
  -SETBUTTONX:<on|off|del>
* -SETCLIPBOARD:<valueType>;<value>;<resultFile>
  -SETSTARTBUTTON:<hide|show|disable|enable>
  -SETTASKBUTTON:<hide|show>[;<handle>]
  -SUSPEND
  -WRITEREGISTRY:<fullKeyPath>;<entryName>;<valueType>;<value>;<resultFile>


E as funções de abstração, incluídas na biblioteca WAPI.

GetWinClip() -> string
SetWinClip(<cData>) -> logic

Ambas as funções foram testadas nos Windows 98 e XP. Mas um detalhe: elas foram feitas para suportar apenas texto simples que, logicamente, estará limitado ao tamanho das variáveis Clipper: 64KB.
Como sempre, é recomendável ler o pequeno manual contido no README.TXT que acompanha o pacote, para conhecer mais detalhes de uso da biblioteca. Inclusive o fonte WAPI.C, para conhecer os detalhes dos switches.

Download: http://buzinello.com/download/wapi.zip

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

MensagemEnviado: 17 Fev 2007 08:51
por Maligno
Nem precisava, mas esqueci de dizer que as críticas serão sempre bem-vindas e também comentários e sugestões de aprimoramentos e/ou adição de novos recursos.
Assim que o tempo permitir, a próxima adição será de um programa demo que contemplará todas as funções já prontas. Um "big" demo. :)

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

Mais implementações p/WAPI

MensagemEnviado: 02 Mar 2007 20:10
por Pablo César
Olá caro Paulo, deixei passr um tempinho para que você pudesse descansar das minhas incomodações... hehe
Mesmo com a sua permissão para que todos nós possamos fazer críticas e sugestões sobre o já tão valorizado WAPI, eu fico ainda acanhado em pedir mais implementações. Uma porque gostaria que você pudesse conseguir fazer algo sobre:

1. Detectar se a sessão é janelada ou tela-inteira (sei que há ainda esperanças)
2. Alguma forma de extrair os comandos para impressão conforme o drive da impressora instalada no WINDOWS. Esta seria uma boa, mesmo que seja em forma gráfica. Eu nunca pude entender como se faz para imprimir em forma gráfica. E como fazem os programadores para imprimir em seus aplicativos GUI. Se você pudesse dar um exemplo ?.

Embora eu tenha interesse também sobre outros recursos que o WAPI poderia fazer. E eu estaria disposto a compensar o seu tempo. Acho que você foi muito caridoso e que não esperava nada em troca de nós. Mas acho que todos merecemos ser recompensados de alguma forma e eu ao menos estou disposto ao menos a ajudar em todo este projeto.

Obrigado mais vez nobre colega !. :{ :)Pos

Re: Mais implementações p/WAPI

MensagemEnviado: 02 Mar 2007 22:17
por Maligno
1. Detectar se a sessão é janelada ou tela-inteira (sei que há ainda esperanças)

A esperança é a última que morre. :)))

2. Alguma forma de extrair os comandos para impressão conforme o drive da impressora instalada no WINDOWS.

É absolutamente impossível recuperar a relação de comandos de uma impressora apenas com seu driver. Só mesmo pela documentação desta.

Eu nunca pude entender como se faz para imprimir em forma gráfica. E como fazem os programadores para imprimir em seus aplicativos GUI. Se você pudesse dar um exemplo ?.

Se você imprime em um programa GUI, em modo RAW, você tem de fornecer os comandos que a impressora alvo aceita. Portanto, você tem de conhecer quais códigos são esses. Se você imprime através de um gerador de relatórios, como os que existem nas melhores IDEs, você apenas monta seu relatório pelo sistema WYSIWYG, a exemplo do que o Word faz. A aplicação, num nível mais elevado, e por meio do gerador, monta uma espécie de pseudo-código que é repassado à etapa de impressão. É esse código que permite, por exemplo, imprimir uma certa página, ao invés de todo o relatório. Nesta etapa o Windows, através do driver, interpreta este código em alto nível, criando um monte de código RAW, em baixo nível. Este será o código enviado para a impressora. Aliás, a impressora só trabalha com código RAW. Não sou especialista no assunto, mas, a grosso modo, é assim que a coisa funciona.

É claro que você também poderia imprimir sem usar gerador nenhum, mas usando primitivas, por exemplo. Você tem código para imprimir quadrados, triângulos, círculos, traços, mudar fontes, etc. Eu até já fiz um programa pra testar impressão, utilizando diversas primitivas, mas isso é muito chato e pouco produtivo. O Windows monta uma página de impressão em memória e você vai executando as funções primitivas informando o posicionamento (e tamanho, cor, etc) de cada uma delas. É entediante demais. É um tipo de "@ lin,col SAY". Só que bem pior.
O meio de transporte desse tipo de código é sempre o driver da impressora, que faz a tradução final, a fim de obter aquele código RAW, que é o nível mais baixo possível. Exatamente por isso que eu disse que o driver da impressora não tem a função de documentar o código RAW. Sua função é obter o código RAW que a impressora deverá receber. Logo, por meio do driver não será possível recuperar esses códigos.

Embora eu tenha interesse também sobre outros recursos que o WAPI poderia fazer.

Quais, por exemplo?

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

Implementações p/Wapi

MensagemEnviado: 07 Mar 2007 10:56
por Pablo César
Antes tudo, obrigado MALIGNO pela sua explicação e paciência comigo e desculpe a demora no meu retorno.

Maligno escreveu:A esperança é a última que morre. :)))
Desculpe insistir nisto, mas quando eu mencionei:
É com esta função que deu para demostrarte que há diferença de resultado entre modo JANELADO e TELA CHEIA. Mas agora espero que você tenha captado a idéia e espero que você a torne possível com teu conhecimento em BCC.
E você respondeu:
Eu já sabia dessa particularidade. Mas realmente, por aí não vai dar para descobrir qual o modo da janela DOS. Ou melhor, até deve ser possível, mas por algum artifício tão ou mais complicado do que usar a API do Windows.


Você não poderia fazer uma função que ao igual da função SETTASKBUTTON que funciona diferentemente na TELA CHEIA e no JANELADO, e pudesse dar o retorno da função quando ora a função tenha conseguido com êxito ou não ??

Maligno escreveu:É absolutamente impossível recuperar a relação de comandos de uma impressora apenas com seu driver. Só mesmo pela documentação desta.
Eu ainda acho que algo deve haver algo mais em torno disto. Porque o DOSPRINTER (aquele do olhinho), ele interpreta os comando EPSON dentro do arquivo TEXTO para o comando de QUALQUER impressora. Se bem que esse comando tem que estar posicionado logo no início de cada linha para poder ser interpretado com sucesso. Nisto mantém o mesmo conceito que você explicou anteriormente de que do caso contrário precisaria do sistema WYSIWYG.

Maligno escreveu:a exemplo do que o Word faz. A aplicação, num nível mais elevado, e por meio do gerador, monta uma espécie de pseudo-código que é repassado à etapa de impressão. É esse código que permite, por exemplo, imprimir uma certa página, ao invés de todo o relatório. Nesta etapa o Windows, através do driver, interpreta este código em alto nível, criando um monte de código RAW, em baixo nível.
O que eu gostaria de obter que ao igua desse DOSPRINTER, possamos interpretar esses "pseudo-códigos" que seriam passados como comandos EPSON que ja todo mundo conhece e traduzir aos comando da impressora instalada.

Fiz testes com o WAPI em WINXP (do próprio cliente), a função de GETWINDOWSINFO e funcionou de acrodo com a versão. Também intentei imprimir numa impressora HP D1300 USB utilizando a função -PRINT do WAPI, mas em nenhuma situação imprimiu. Mencionava "erro" no status da fila de impressão.

Outras sugestões para adição de novos recursos, seriam:

1. Possibilidade de utilizar o WAPI para adicionar programas no menu iniciar (inicializar ou items de programas). Na eminente invasão das novas versões de WINDOWS XP, VISTA... e na extinção do arquivo de inicialização do AUTOEXEC.BAT. Eu faço o meu arquivo de inicialização colocando no INICIALIZAR o arquivo .BAT que desejo executar. Muitas vezes tenho arquivos temporários que ficam criados e não deletados quando o computador é desligado inesperadamente. Ou até mesmo para colocar uma rotina que quero executar somente na inicialização da máquina.

2. Criar atalho, disponibilizando na área de trabalho.

3. Inserir variáveis e items do MSCONFIG como:
KEYBRD2.SYS e PerVMFiles-150 na aba do SYSTEM.INI e seção [386Enh]

4. Tratar LONG NAMES para SHORT NAMES

5. Possibilitar criação de JOBs no MS-TASK, para que possamos utilizar o mesmo Agendador de Tarefas do WINDOWS. Este seria um excelente recurso que possibilitaria unificar agendas e faria a interrupção imediata de cada aplicativo conforme agendamentos.

A minha idéia não é de te encher de coisas a fazer, preciso muito a função de identificar em que modo está sendo exibido a sessão e não quero sobrecarregar de pedidos.

Um clip-abraço :)Pos

Re: Implementações p/Wapi

MensagemEnviado: 07 Mar 2007 11:45
por Maligno
Você não poderia fazer uma função que ao igual da função SETTASKBUTTON que funciona diferentemente na TELA CHEIA e no JANELADO, e pudesse dar o retorno da função quando ora a função tenha conseguido com êxito ou não ??

A função da API não me dá retorno algum. Portanto, não tenho como dizer se ela funcionou ou não.

Eu ainda acho que algo deve haver algo mais em torno disto. Porque o DOSPRINTER (aquele do olhinho), ele interpreta os comando EPSON dentro do arquivo TEXTO para o comando de QUALQUER impressora.

Nunca testei esse programa ou mesmo outro qualquer do tipo, mas imagino que o que ele deve fazer é traduzir os comandos que encontra. Observe a página do DOSPrinter e repara que ele tem uma lista de "Esc/P Esc/P2 supported commands". Ou seja, se você usar algum comando inexistente na lista, ele simplesmente não traduzirá. :)
Logo, sou levado a crer que a minha suposição está certa. E ainda acho que ele não lê código de driver nenhum. Não é essa a função do driver. Imagino que ele apenas monte o mesmo tipo de pseudo-código que um gerador de relatório montaria. Depois é só seguir o caminho natural, através da API do Windows. Aliás, repare: driver de impressão, como qualquer driver, tem como finalidade principal, esconder da aplicação as particularidades do dispositivo. Portanto, seria um grande contra-senso a aplicação se comunicar com o driver. Até porque, talvez a aplicação sequer consiga saber qual é o driver da impressora selecionada.

O que eu gostaria de obter que ao igua desse DOSPRINTER, possamos interpretar esses "pseudo-códigos" que seriam passados como comandos EPSON que ja todo mundo conhece e traduzir aos comando da impressora instalada.

Você mesmo já falou em tradução de comandos. :)
Mas é uma idéia, embora já existam alguns programas que fazem isso. Freeware não conheço, mas deve existir algum. Agora, desenvolver isso, pra mim, vai ser difícil. Não vou ter o tempo disponível necessário, infelizmente. Se bem que, como eu já disse antes, se você se empenhar e montar seu próprio sub-sistema de impressão, em Clipper mesmo, vai conseguir resultado semelhante. Daí, é só imprimir para um arquivo e mandar pro spooler. A não ser, claro, que você queria imprimir gráficos, figuras, etc. Seria possível também, mas daí já compensa usar um desses programas prontos.

Também intentei imprimir numa impressora HP D1300 USB utilizando a função -PRINT do WAPI, mas em nenhuma situação imprimiu. Mencionava "erro" no status da fila de impressão.

Esse erro não é informado pelo WAPI. Onde você o viu?

1. Possibilidade de utilizar o WAPI para adicionar programas no menu iniciar

É possível.

extinção do arquivo de inicialização do AUTOEXEC.BAT.

O AUTOEXEC ainda continua a existir. Nos Windows de kernel NT ele apenas mudou de extensão e sua importância mudou um pouco mas, fora isso, continua do mesmo jeito.

Ou até mesmo para colocar uma rotina que quero executar somente na inicialização da máquina.

Pra isso o WAPI tem o manipulador do Registry. É só acrescentar a chave no local apropriado e ele executará sempre (RUN) ou apenas uma vez (RUNONCE). Só depende do local.

2. Criar atalho, disponibilizando na área de trabalho.

Isso é o mesmo que o ítem 1. :)

3. Inserir variáveis e items do MSCONFIG como: KEYBRD2.SYS e PerVMFiles-150 na aba do SYSTEM.INI e seção [386Enh]

Disponibilizei uma função há alguns dias que é perfeita pra isso. Basta você apontar o arquivo. Talvez seja necessário apenas incluir uma busca de chave, mas isso é simples. Se não viu a mensagem a esse respeito, eis o link do arquivo.

4. Tratar LONG NAMES para SHORT NAMES

Não entendi o que você quer dizer com isso.

5. Possibilitar criação de JOBs no MS-TASK, para que possamos utilizar o mesmo Agendador de Tarefas do WINDOWS.

Nunca usei isso, mas pelo pouco que vi, isso daria um trabalho razoável. :(

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

WAPI

MensagemEnviado: 09 Mar 2007 22:26
por Pablo César
1. Desculpe mais uma vez insistir neste assunto, como você disse: Saber o "estado" da janela DOS é uma necessidade de pouquíssima gente... mas eu sou uma delas e me conformaria se de fato é possível alternar o modo de exibição da tela (sem intervenção do usuário), isto é, de TELA-CHEIA para modo JANELADO e de modo JANELADO para TELA-CHEIA. porque de ser assim, eu não precisaria pedir pro usuário alternar o modo de exibição.

Maligno escreveu:A função da API não me dá retorno algum. Portanto, não tenho como dizer se ela funcionou ou não.
Na minha mensagem na qual indico o link http://www.codeproject.com/useritems/Wi ... screen.asp sobre FULLSCREEN, nessa função feito em C (creio eu), onde indica que após criar as variaveis:
HWND    hWnd;            // The main window handle

HWND    hWndInputPanel = NULL;    // The SIP
HWND    hWndTaskBar    = NULL;    // The TaskBar
HWND    hWndSipButton  = NULL;    // The SIP Button

BOOL mode = false;        // Our current window mode. 
                //  True = Fullscreen
                //  False - Windowed (Startup Default)
E depois procura os "handles" do TaskBar, Standard Input Panel (SIP) e Botões da Barra SIP:
void InitFullScreen (void)
{
    hWndInputPanel    = FindWindow(TEXT("SipWndClass"), NULL);
    hWndSipButton    = FindWindow(TEXT("MS_SIPBUTTON"), NULL);
    hWndTaskBar    = FindWindow(TEXT("HHTaskBar"), NULL);
}
Pergunto: Você conseguiria reproduzir isto ? E ver se se comporta de forma diferente conforme o modo de exibição (Tela cheia ou janelada) ?.

Confesso que ainda não testei essa opção sua e dos outros colegas que aciona o modo gráfico (isso expande a janela) e depois comuta para o modo texto 80x25. Me indique onde encontro essa função e me dê exemplo de como fazer. Enquanto isso, vou re-instalar meu WINDOWS 98 que não me permite fazer este teste, pois meu WINDOWS 98 usar o WINOLDAP está procando falha e colapsa o sistema.

2. Quando eu disse:
intentei imprimir numa impressora HP D1300 USB utilizando a função -PRINT do WAPI, mas em nenhuma situação imprimiu. Mencionava "erro" no status da fila de impressão.
Para ser exato foi um HP Deskjet D1360. E o erro que digo é mostrado na fila de impressão. Neste momento lamentavelmente, não posso precisar o erro, mas logo assim tenha o meu PC a normalidade mandarei por email a tela capturada. Mas é proveniente do Menu Iniciar,Configurações;Impressoras;Double click-na-impressora;e verá o erro.

Maligno escreveu:Esse erro não é informado pelo WAPI. Onde você o viu?
O erro é procedente da FILA-DE-IMPRESSÃO. Não é um erro do WAPI e sim um erro causado pelo WAPI.

3.
Maligno escreveu:Pra isso o WAPI tem o manipulador do Registry. É só acrescentar a chave no local apropriado e ele executará sempre (RUN) ou apenas uma vez (RUNONCE). Só depende do local.
Legal !. Me desculpe a minha falta de conhecimento sobre o REGISTRY, eu vou testar mas é claro que deverá dar certo. Obrigado.

4. Desculpem por não ter sido mais claro, quando me referia: "Tratar LONG NAMES para SHORT NAMES". Estava querendo dizer uma função para tratar os nomes de arquivos quando os seus nomes ultrapassam 12 caracteres (formato DOS 8x3) é dizer nomes-longos e demostrar em forma reduzida. Se bem que existe outra biblioteca que faz o mesmo (LFNSHORT()).

Bem mais, uma vez MALIGNO, agradeço a sua atenção.

Um clip-abraço :)Pos

Re: WAPI

MensagemEnviado: 10 Mar 2007 11:18
por Maligno
Na minha mensagem na qual indico o link [link] sobre FULLSCREEN, nessa função feito em C (creio eu), onde indica que após criar as variaveis:
Pergunto: Você conseguiria reproduzir isto ? E ver se se comporta de forma diferente conforme o modo de exibição (Tela cheia ou janelada) ?.

Sinto muito, mas não dá. A matéria deste link diz respeito ao Windows CE (se bem que as funções utilizadas fazem parte da API do Windows) e nada tem a ver com NTVM. A comutação de modos tratada aqui é para maximizar/minimizar janelas de aplicações comuns. Até poderia funcionar com uma janela NTVM, mas ela só seria maximizada/minimizada. Isso é diferente de trocar de modo TELA CHEIA <-> JANELA.

Confesso que ainda não testei essa opção sua e dos outros colegas que aciona o modo gráfico (isso expande a janela) e depois comuta para o modo texto 80x25. Me indique onde encontro essa função e me dê exemplo de como fazer.

É uma função simples. O link é http://buzinello.com/download/fullscr.zip.
Sintaxe: WinFullScr().

Para ser exato foi um HP Deskjet D1360. E o erro que digo é mostrado na fila de impressão. Neste momento lamentavelmente, não posso precisar o erro, mas logo assim tenha o meu PC a normalidade mandarei por email a tela capturada.

Ah, sim. Um erro qualquer, que você não sabe precisar, na coluna "status" da fila de impressão. Tudo bem. Quando tiver refeito o teste me diga qual erro foi. Se bem que, eu próprio já peguei erro ali. Foi uma "engasgada" do Windows. Não sei dizer porque. Só sei que não foi erro do WAPI. Foi com a minha própria impressora LJ1022. Aconteceu umas duas ou três vezes. Depois parou, sem que eu alterasse qualquer coisa no WAPI. Infelizmente não consegui entender o que aconteceu. Assim, não pude reproduzir o erro. Deixei pra lá. Mas se obtiver o erro novamente, é só dizer. Só não posso dizer que eu vá alterar o WAPI por causa disso. Depois que você comentou sobre isso, revisei o código e não pude encontrar nenhum procedimento incorreto. Logo,... :)

Estava querendo dizer uma função para tratar os nomes de arquivos quando os seus nomes ultrapassam 12 caracteres (formato DOS 8x3) é dizer nomes-longos e demostrar em forma reduzida. Se bem que existe outra biblioteca que faz o mesmo (LFNSHORT()).

Nunca usei essa biblioteca mas, pelo que eu sei, ela dá ao Clipper a capacidade de manipular arquivos com os nomes longos do Windows. Se não me falha a memória, ela acrescenta só essa característica ao Clipper, não traduz nomes longos para curtos. Sei que existe uma função do Windows que informa qual é o nome curto de um arquivo. Só não sei dizer se ela converte para nome curto. Provavelmente não, já que o nome curto depende de uma pesquisa no diretório onde o arquivo se encontra, pois poderá haver algum conflito. Não sei qual é sua real necessidade, mas se for para converter, você mesmo pode fazer uma pequena função Clipper para isso. É só aplicar a regra de renomeação usada pelo Windows e, claro, observar o detalhe da pesquisa no diretório.

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

MensagemEnviado: 10 Mar 2007 12:08
por Clipper
Complementando

O LFN Lib, faz vários tratamentos de nomes longos no Clipper, inclusive o de retornar o nome curto de um arquivo com nome longo. A funçao que faz isso é LF_TOSHORT().

Até logo.

Marcelo

MensagemEnviado: 10 Mar 2007 12:21
por Maligno
Clipper escreveu:O LFN Lib, faz vários tratamentos de nomes longos no Clipper, inclusive o de retornar o nome curto de um arquivo com nome longo. A funçao que faz isso é LF_TOSHORT().

Boa. Não sabia disso. Acho que já deve resolver o problema do nosso colega. Obrigado, Marcelo.
Mas você sabe dizer se ela converte ou realmente lê o nome curto?

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

WAPI

MensagemEnviado: 10 Mar 2007 14:33
por Pablo César
Obrigado Marcelo, eu ja utilizava essas funções. Porém achei conveniente solicitar a inclusão no WAPI a fim de UNIFICAR a LIB no meu sistema. Mas complementando a informação, eu vi no site da propria Microsoft, a metodologia utilizada para interpretação de LONG-FILES-NAMES.

Pena Maligno que a função WinFullScr() não troca de modo TELA CHEIA <-> JANELADO. Pois daí tenho outra sugestão a fazer, mas primeiramente vou explicar uma das razões que preciso alternar o modo de exibição da janela (se bem que ja expliquei aha muito tempo essa minha razão).

Dentro do meu aplicativo, geralmente todos preferem a TELA-CHEIA, e precisam chamar um programa for WINDOWS. Antes de chamar a aplicação for WINDOWS a sessão DOS deve estar em modo janelado, para que o usuário não se perca quando a aplicação DOS for minimizada ao chamar outra sessão (com o aplicativo for WINDOWS). Por isso, que tanto peço a você MALIGNO esta função de deteção. No entanto, vendo que ja estamos até cansados de buscar uma solução para isso e como eu disse tenho outra idéia:

Sabemos que o WAPI possue a função para identificar a sessão abertas e dado pelo número do HANDLE. E se houvesse possibilidade de fazer uma nova função para o WAPI possa abrir (maximizando ou em tela-cheia, se for possível) uma determinada sessão que estivesse minimizada, através do HANDLE. Daí então, não precisaria mudar o modo de exibição porque eu forçaria a retornar ão sistema após rodar aplicação for WINDOWS, digamos. Me diga... que tem forma, sim ???

Espero que Deus ilumine sua mente e abra essa nova função.

Um clip-abraço :)Pos :{ :xau

MensagemEnviado: 10 Mar 2007 17:44
por Clipper
Prezado Maligno

Segundo NG ela converte, veja o que diz no NG :

LF_ToShort() calls the LFN specific DOS function 7160h to convert
the file name. If long file names are not supported, LF_ToShort()
will fail. The DOS error code can then be retrieved by calling
LF_Ferror().

Até logo.

Marcelo

MensagemEnviado: 10 Mar 2007 19:16
por Maligno
Clipper escreveu:LF_ToShort() calls the LFN specific DOS function 7160h to convert the file name. If long file names are not supported, LF_ToShort()
will fail. The DOS error code can then be retrieved by calling
LF_Ferror().

Dei uma olhada na descrição nesse serviço do DOS. Uma descrição de parâmetro ("ASCIIZ long filename or path") me faz pensar que ele não converte levando em conta o conteúdo do diretório alvo. Se ele aceita um simples nome de arquivo, sem path, é porque a conversão é feita sem se certificar de que não haverá conflito com algum outro arquivo.

Bom, eu que não vou usar isso. Então, caso alguém vá, sugiro que preste atenção nesse detalhe, a fim de evitar surpresas desagradáveis.

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

MensagemEnviado: 10 Mar 2007 19:31
por Pablo César
MALIGNO, Acho que vale a pena dar uma olhada no site da Microsoft a respeito. Não faço questão que você quebre a cabeça com isto, mas se for para ajudar a esclarecer sobre o assunto, aqui vai o link:

http://msdn2.microsoft.com/en-us/library/aa371851.aspx

Espero (anciososo) sua resposta sobre minha postagem anterior.

sds

MensagemEnviado: 10 Mar 2007 22:32
por Maligno
Pablo César escreveu:MALIGNO, Acho que vale a pena dar uma olhada no site da Microsoft a respeito.

Eu vi o link. Ele trata de uma propriedade do Windows Installer. Só isso. Inclusive, ele faz referência àquela função que eu citei antes. Mas não esclarece muito.

Espero (anciososo) sua resposta sobre minha postagem anterior.

Vou pensar nisso amanhã. :)

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

MensagemEnviado: 11 Mar 2007 16:37
por Maligno
Sabemos que o WAPI possue a função para identificar a sessão abertas e dado pelo número do HANDLE. E se houvesse possibilidade de fazer uma nova função para o WAPI possa abrir (maximizando ou em tela-cheia, se for possível) uma determinada sessão que estivesse minimizada, através do HANDLE. Daí então, não precisaria mudar o modo de exibição porque eu forçaria a retornar ão sistema após rodar aplicação for WINDOWS, digamos. Me diga... que tem forma, sim ???

Acho que era sobre essa questão que você estava ancioso para obter uma resposta, não é?
Bom, se fosse apenas uma aplicação Windows GUI eu diria que não haveria qualquer problema. Entretanto, como nossa questão gira em torno de sessões DOS, não posso responder nada sem fazer algumas experiências. Talvez até dê para, não maximizar, mas restaurar a janela DOS. Vou fazer alguns testes, antes de dizer qualquer coisa. Depois volto ao assunto. :)

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

Isso mesmo

MensagemEnviado: 11 Mar 2007 22:40
por Pablo César
Maligno escreveu:Acho que era sobre essa questão que você estava ancioso para obter uma resposta, não é?
AHAMMM !!

Maligno escreveu:Vou fazer alguns testes, antes de dizer qualquer coisa. Depois volto ao assunto. :)
BELEZA !!!

GOD BLESS YOU, MALIGNO !!! :)Pos (agora vou dormir mais tranquilo... hihihi)

LONG-FILES-NAMES

MensagemEnviado: 11 Mar 2007 23:03
por Pablo César
Só para complementar informação sobre o LONG-FILES-NAMES (Nomes longos dos arquivos).

Umas das dificuldades com o nome comprido do diretório, é mudar de diretorio (muitos não sabem), mas no DOS para mudar basta colocar o nome longo entre aspas, porém ~eu não conseguí utilizar dessa forma com o DIRCHANGE() da CT.LIB.

Um clip-abraço :)Pos

MensagemEnviado: 15 Mar 2007 00:02
por Maligno
Conforme comentado em outra thread,...

Já até terminei de desenvolver a função URL2FILE no WAPI. Funciona perfeitamente, apesar do meu firewall não gostar muito. Eu até disse que ia liberar de imediato, mas não gostei de uma coisa. Há duas funções: a de download e a de teste de conexão. Esta última, quando desconectado da Internet, demora tempo demais pra retornar. É um exagero. Então resolvi segurar o WAPI mais um pouco pra poder encontrar uma maneira de acompanhar de perto o progresso da conexão. Posso dizer que encontrei uma maneira mas ainda está em teste. Como só posso mexer nisso à noite, vai demorar um pouco mais. Não vai ser fácil monitorar o progresso de um download de forma a poder montar uma barra de progresso. Mas será possível estipular um "timeOut". Isso já vai melhorar a performance da função.

Aliás, uma outra coisa que é bastante chata é o falso positivo no teste de conexão. Como o teste ocorre pelo download de um arquivo pequeno e o U2F usa um moniker do IE, no segundo download o arquivo vem do cachè e não da Internet. Mas isso também está pra ser resolvido. Espero. :)

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

MensagemEnviado: 15 Mar 2007 00:53
por Pablo César
MALIGNO, não seria conveniente separar estas novas funções de comunicação em uma outra biblioteca ou aplicativo, por assim dizer ?.

Nessa nova função ou aplicativo de verificar somente se está conectado a INTERNET. O maior problema e o tempo de retorno (mesmo com TIMEOUT definido) parece ser um problema até do próprio PING que é o mais simples para esta questão que também demora quando está DESCONECTADO.

Talvez eu fale uma besteira, mas me deixe opinar no escuro:

Seria possível, talvez em linguagem de baixo nível (e sei que você manja) verificar se o modem está com a porta aberta ?. Acho que deve funcionar para modems de dial-up mas não entanto não sei como seria em modems DSL.

Sei lá às vezes correm idéia tão malucas... mas que sem querer podem levar a algo.

Boa sorte colega, mas pense em criar outro aplicativo para comunicações.

Um clip-abraço
:)Pos

MensagemEnviado: 15 Mar 2007 02:52
por Maligno
Pablo César escreveu:MALIGNO, não seria conveniente separar estas novas funções de comunicação em uma outra biblioteca ou aplicativo, por assim dizer ?.

Que diferença faria?

Nessa nova função ou aplicativo de verificar somente se está conectado a INTERNET. O maior problema e o tempo de retorno (mesmo com TIMEOUT definido) parece ser um problema até do próprio PING que é o mais simples para esta questão que também demora quando está DESCONECTADO.

Mas se você definir um TIMEOUT acabou o problema da espera prolongada, não é? :)

Seria possível, talvez em linguagem de baixo nível (e sei que você manja) verificar se o modem está com a porta aberta ?. Acho que deve funcionar para modems de dial-up mas não entanto não sei como seria em modems DSL.

Tem uma API do Windows chamada RAS (Remote Access Service) através do qual posso não só saber qual conexão está ativa como até mesmo forçar uma desconexão. Isso vale para qualquer tipo de modem. Eu até poderia usá-la porque já fiz um programa há alguns meses pra testar. Mas ainda prefiro usar o U2F, até porque eu quero usá-lo para download. Afinal de contas, o download pode falhar. Se o servidor estiver down e não houver um timeOut definido pra isso também, o problema da demora continuará. Portanto, são aplicações diferentes que têm o mesmo problema. Portanto, não convém separar as soluções.

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

MensagemEnviado: 25 Mar 2007 04:38
por Maligno
Conforme eu havia comentado há alguns dias, estava desenvolvendo um recurso que fosse uma alternativa menos limitada ao utilitário U2F. Depois de pesquisar e procurar pelas melhores alternativas, conclui o trabalho e incorporei o novo recurso ao WAPI, que já está disponível para download.

Eis uma relação atualizada dos switches que fazer parte do WAPI. O que está em asterísco é o novo recurso. Por meio dele pode-se fazer exatamente o que o U2F fazia: baixar arquivos pela Internet. Mas há duas vantagens: como eu troquei a API do ActiveX por outra melhor, pude desenvolver um código mais controlado, o que me permitiu desligar o cachê, que sempre foi uma coisa problemática no U2F. A segunda vantagem é que agora pode-se definir um TimeOut para forçar um retorno após certo tempo sem tráfego.

  -DELETEREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
  -FLASH:<times>[;<handle>]
  -GETAPPSINFO:<resultFile>
  -GETCLIPBOARD:<resultFile>
  -GETDEFPRINTER:<resultFile>
  -GETHDINFO:<resultFile>
  -GETMYHANDLE:<resultFile>
  -GETPRINTERS:<resultFile>
  -GETWINDOWSINFO:<resultFile>
  -HIBERNATE
  -PLAYWAVE:<source>
  -POWEROFF
  -PRINT:<printerName>;<inputFile>;<reportTitle>;<resultFile>
  -READREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
  -REBOOT
  -SETAPPTITLE:<title>
  -SETBUTTONX:<on|off|del>
  -SETCLIPBOARD:<valueType>;<value>;<resultFile>
  -SETSTARTBUTTON:<hide|show|disable|enable>
  -SETTASKBUTTON:<hide|show>[;<handle>]
  -SUSPEND
* -URL2FILE:<URL>;<fileName>;<timeOut>;<resultFile>
  -WRITEREGISTRY:<fullKeyPath>;<entryName>;<valueType>;<value>;<resultFile>


Também foram adicionadas à biblioteca WAPI duas funções pra abstrair o acesso ao novo recurso: DLoadFile() e IsInternet().

Há alguns dias estava discutindo com alguns colegas algumas idéias a respeito de atualização de programa via Internet. O elo que faltava era justamente uma função que pudesse fazer teste de conexão e download com um pouco mais de controle do que a U2F proporcionava. Agora já é possível.

Claro que, uma vez que há um meio de baixar arquivos, é bem possível também interagir com servidor por meio de alguns scripts. Quem tem site, naturalmente tem acesso a isso. Uma utilidade para o novo recurso é justamente a proteção de um software, seja para validar uma licença ou mesmo renová-la, principalmente para quem aluga software. Eu próprio fiz um teste simples para obter a data do server para comparar com a data do sistema e saber se houve alguma alteração indevida. O script PHP abaixo me retorna um texto com a data e hora no formato DDMMYYYY;hh:mm:ss.

<?php echo(date("Ymd;His")); ?>


O programa XBase abaixo recupera e mostra essa data e hora, caso seja detectada uma conexão.

clear
set date british
set century off
*
if IsInternet()
   cSrv := "buzinello.com"
   cRet := ""
   if DLoadFile("www."+cSrv+"/servertime.php",@cRet)
      ? "No servidor " + cSrv + ":"
      ? "--------------------------"
      ? "Date: " + DtoC(StoD(Left(cRet,8)))
      ? "Time: " + Transf(Right(cRet,6),"@R 99:99:99")
   else
      ? "ERRO desconhecido!"
   end
else
   ? "ERRO: desconectado ou bloqueado pelo firewall!"
end
?


A partir disso é fácil imaginar que novos tipos de controles poderão ser feitos para atender a demanda nessa área. Basta baixar a saída do script (seja de que tipo for: HTML, texto, etc), cujos parâmetros podem ser passados na URL. Podem ser executadas tarefas das mais diversas: conversões, cálculos, pesquisas em MySQL, etc. Tudo parametrizado na própria URL. A imaginação é o limite. :)

O README.TXT, que acompanha o ZIP contém, contém descrições mais detalhadas. Aconselho sua leitura, assim como a leitura dos fontes das funções de abstração.

Link para download: http://buzinello.com/download/wapi.zip

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

MensagemEnviado: 25 Mar 2007 09:19
por Eolo
Pessoal,

Eu uso uma solução muito mais simples (e que tb funciona!) para evitar 2 instâncias do mesmo programa: logo no inicio, faço ele abrir um determinado arquivo TXT com o FOPEN(), em modo exclusivo. Se o FOPEN() retorna .T., deixo o programa continuar. Se o FOPEN() retorna .F., é sinal que ele já tá rodando em outra janela, então QUITo essa 2a. instância e mando uma mensagem pro usuário checar a barra de tarefas...

Na saída do programa, não precisa nem fechar o tal arquivo TXT, o Clipper cuida disso. E, mesmo que por exemplo falte energia durante a execução do programa, não tem problema: quando ela voltar, o arquivo TXT vai estar lá disponível para ser aberto novamente em modo exclusivo.

Eolo

MensagemEnviado: 25 Mar 2007 13:22
por Poka
Prezado Eolo


Voce poderia colocar um exemplo como voce faz para abrir um arquivo exclusivo com FOPEN(), e retornar .T. ou .F.
Eu utilizo funcoes de baixo nivel em algumas rotinas, mas nao consegui colocar o seu exemplo. O que me interessou, é que mesmo faltando energia, esse esquema dá certo.

Obrigado

Poka.

MensagemEnviado: 25 Mar 2007 13:38
por Eolo
Poka,
A seguir, como eu uso (adaptado).
Eolo


arq="c:\aberto.eol" // pode ser .txt, .abc, .qq extensão
* cria arquivo se ele não existir...
if !file(arq)
  arqh=fcreate(arq,0)
  if !arqh>0
    clear
    @10,10 say "Erro ao Iniciar Acesso"
    inkey(5)
    quit
  endi
  txt="Qualquer coisa"
  * grava qq coisa nele...
  txt_t=fwrite(arqh,txt)
  if !txt_t=len(txt)
    @10,10 say "Erro ao Registrar Acesso"
    inkey(5)
    quit
  endi
  fclose(arqh)
endi
* arquivo existe, abre exclusivo...
janela2=fopen(arq,18)
if !janela2>0
  clear
  @10,10 say "Programa aberto EM OUTRA JANELA"
  @12,10 say "Verifique a BARRA DE TAREFAS"
  inkey(5)
  quit
endi
rele arq, arqh, janela2, txt, txt_t
* neste ponto, passou...
* e, se passou, continua a execução normal do prg..
* ...

MensagemEnviado: 25 Mar 2007 13:41
por Eolo
Poka,

Complementando: quando vc usa o FOPEN() e dá certo, ele retorna o número do "file handle". Se der pau, ele retorna -1. Então, se a 2a. instância tentar bloquear um arquivo que já está bloqueado, o FOPEN() retorna -1, o que quer dizer que já foi bloqueado antes.

Cara, esse esquema é tão simples que dá até "raiva"...

Eolo

MULTI SESSÃO

MensagemEnviado: 25 Mar 2007 17:44
por Pablo César
Caro colega Eolo,

Confesso que estou surpreso com a sua NOVA solução através do FOPEN.
Funcionou beleza, testei de todas as formas possíveis e deu certo em TODAS (até agora). Foi uma solução bem prática e o seu resultado é IMEDIATO. Mas me permita, fazer algumas observações.

Este assunto, como já disseram os colegas em outros tópicos, já foi discutido INÚMERAS vezes. Eu lembro que abrí há muito tempo atrás (antes deste novo sistema gerenciador de FORUM) e lembro que a solução apresentada era ctambém muito similar ao seu, mas apresentava falhas. O MALIGNO, inclusivo foi uns dos primeiros a apresentar essa solução com FOPEN também. Pareceria que este assunto não tem vínculo algum com WAPI se não fosse que o WAPI apresenta outra solução muito mais aprimorada com a função -GETAPPSINFO. E inclusive, veja neste tópico aborda este mesmo assunto: http://www.pctoledo.com.br/forum/viewto ... pen+sessao

Esta ultima solução por você apresentada é boa, mas não seria a mais apropriada para os casos de terminais burros (existem casos, como menciona o colega) que não possuem HD.

Também existe outro porém, que no meu caso não resolveria a sua solução apresentada. Como eu ja disse em muitos casos. O meu sistema é MODULAR, isto é, tenho vários executáveis que compõe o sistema. Isto é, tenho um arquivo em lote, que chama um menu.exe que devolve errorlevel e dentro da BATCH chama os executáveis de acordo a opção do menu (isto é, de acordo com o errorlevel passado).

Eu tinha optado, já anteriormente por um aplicativo que verificava assim como o WAPI faz hoje, o nome da sessão aberta. Mas confesso que as vezes, meu aplicativo com WAPI, falha. Não sei ainda o por quê. Talvez haja algum furo no meu aplicativo que verifica o nome da sessão se foi aberta anteriormente já percebí que em várias ocasiões, deixa abrir MULTIPLAS SESSÕES.

Em outras palavras, a solução (vamos dizer) re-apresentada, é boa, é prática mas não é completa para todos os casos.

Aguardo comentários. Eu verificarei se será possível utilizar a sua idéia juntamente com a do MALIGNO, para o meu caso. Caso consiga, postarei aqui o que fiz. Mas parece, que não é tudo 100%. Mas mesmo assim, fico com a função do WAPI -GETAPPSINFO).

Um clip-abraço :)Pos

MensagemEnviado: 25 Mar 2007 18:06
por Eolo
Poka,

a) para o terminal burro, sem HD, é só trocar
arq="c:\aberto.eol" por
arq="\\servidor\prg\aberto.eol"
pra fazer o arquivo de controle ser criado no servidor.

(aliás, é o que eu uso: no contrato com meus clientes, o EXE não pode ser executado 2 vezes simultaneamente dentro da rede)

b) vc usa um BAT mas, na realidade, quer é controlar cada EXE, certo? Ora, é só criar um arquivo "eol" para cada um: o modulo1.exe abre o modulo1.eol em modo exclusivo, o modulo2.exe abre o modulo2.eol, e assim por diante... Não vai acontecer do mesmo módulo ser aberto em 2 janelas.

Aliás, dá pra montar isso de inúmeras formas. Se, por exemplo, vc tem o programa.exe no servidor e quer limitar o uso dele a 3 acessos simultâneos, é só criar o acesso1, acesso2 e acesso3.eol, e fazer com que o programa tente bloquear um dos três... O quarto usuário vai dançar.

Eu tb já tentei uma série de outras soluções, mas esta foi a mais simples que encontrei. E que funciona em 100% dos casos de controle de acesso.

Eolo

MensagemEnviado: 25 Mar 2007 18:57
por Poka
Eolo

Testei aqui em casa e deu certo, eu ja gravo todos os meus arquivos no servidor , inclusive o executavel, entao acredito que não terá problemas.

O comando Fopen aceita como abertura

0 somente leitura
1 gravacao
2 leitura e gravacao

porque fopen(ar,18) ?

testei com 0 -> não dá certo
1 e 2 tambem dá certo
Porque voce colocou 18 ?


Um abraço.

Poka

MensagemEnviado: 25 Mar 2007 19:03
por Pablo César
Não é que você tem razão... sim admito, tens razão ! Muito bom!

Sim... vai dar trabalho e vai criar um monte de arquivinhos.... hehe Mas é aplicável e pelo visto MAIS SIMPLES.

Parabéns, você tem razão. É 100% !.

Mas... pohhh, são tantos os executáveis.... (no meu caso mais de 200)
Também... quem manda fazer o sistema tipo MODULAR... kakakaka Não que nada, graças a isso, consigo que meu sistema seja híbrido com aplicativos GUI sem me importar com o tamanho, nem memória, nem modo protegido, nem nada e me permite que possa fazer manutenção em forma OBJETIVA ou digamos seletiva. Não sei ainda se irei adotar... Mas merece crédito a sua idéia.

Mesmo que eu altere todos os EXE e pegando o seu nome (executável), poderia criar com o mesmo nome porém com extensão .EOL (digamos) e em diretório TEMP (assim, não bagunça tanto de arquivos de semáforos).

Embora o aplicativo que tinha feito pelo WAPI, me mostra piscando a sessão minimizada quando abria duas vezes. Claro que poderia utilizar ambos recursos simultaneamente, também.

Valeu EOLO, matou mesmo !. :|< :)Pos

Também não posso deixar de agradecer aqui mais uma vez ao prezado colega MALIGNO, que elaborou uma função para atender esta demanda, reconhecendo o seu esforço e paciência conosco. No entanto, a função GETAPPSINFO, poderá também ser muito útil para outras finalidades, como por exemplo: capturar os nomes de todas as sessões abertas e solicitar ao usuário fechar tal aplicação. E sabe, que usuário adora abrir e abrir janelas...

MensagemEnviado: 25 Mar 2007 19:10
por Eolo
Pablo e Poka,

Caras, a coisa é simples e funciona mesmo!


Uma curiosidade (Poka): por que vc usa um arquivo batch pra rodar o seu sistema ao invés de deixar tudo dentro de um EXE só? Se é porque tava dando estouro de memória, talvez uma saída seja fazer como eu faço: overlays internos. Eu forço a compilação e linkedição em módulos pequenos, OVERLAYados, o EXE pode ter 2Mb, mas roda até em P1 com 32 de RAM...

Parece que o Blinker (por ex) já cria overlays dinâmicos, mas eu forço os overlays em meus programas (assim consigo inclusive modular melhor a coisa, separar os procedimentos para facilitar a manutenção), deixando no módulo principal só o menu e as funções que são usadas pelos overlays. "Manias" da época do Summer '87 e dos 386 da vida...

O cliente X não quer mais o módulo Y? É só desabilitar ele no menu com um asterisco...


Quanto aos retornos do FOPEN(), os que vc citou são para não-rede. Dá uma olhada no NG. O 18 quer dizer 2 (abrir leitura e gravação) + 16 (modo exclusivo em rede).


Eolo

MensagemEnviado: 25 Mar 2007 19:26
por Pablo César
Eolo escreveu:Uma curiosidade (Poka): por que vc usa um arquivo batch pra rodar o seu sistema ao invés de deixar tudo dentro de um EXE só?
Agora percebo mesmo que você está confundido-me com o colega POKA. MIM SER PABLO, NAUM POKA (eu pouca sombra talvez...), hehehe.

Eolo escreveu:Se é porque tava dando estouro de memória, talvez uma saída seja fazer como eu faço: overlays internos. Eu forço a compilação e linkedição em módulos pequenos, OVERLAYados, o EXE pode ter 2Mb, mas roda até em P1 com 32 de RAM...
Colega... se eu te digo... que não sei fazer isto e que há tempos atrás não tinha conhecido este FORUM, eu não soube fazer overlays.

Eolo escreveu:O cliente X não quer mais o módulo Y? É só desabilitar ele no menu com um asterisco...
Mas também me dá mais flexibilidade na hora de excluir algum módulo, sem ter que compilar. Desabilito e pronto (tanto na BATCH como deletando arquivos, como configurando pelo sistema. E também sempre pensei que se eu colocasse todos esse módulos juntos em um só executável, iria ficar mostruoso. Assim também posso personalizar, facilmente sem ter que RE-COMPILAR. Agora se quiser me explicar como é feito uma compilação com OVERLAYS (sei que agora é ultrapassado)... mas é boms saber. Só que te pediria que você abra um novo tópico para não misturarmos os assuntos e por respeito ao colega MALIGNO, também.

Um clip-abraço

Pablo (falouuuuu... ??) :)Pos

MensagemEnviado: 25 Mar 2007 19:39
por Eolo
Ops, desculpe a troca de nomes...

Sim, vou abrir um tópico Overlays, aí falamos dele lá.

Eolo

MensagemEnviado: 25 Mar 2007 20:29
por Pablo César
Maligno escreveu:Depois de pesquisar e procurar pelas melhores alternativas, conclui o trabalho e incorporei o novo recurso ao WAPI...
FI-COOUUU BOOOMMM !. Gostei, eu tinha voltado a utilizar PING, mas este achei muito melhor porque tem um verdadeiro TIMEOUT.

Maligno escreveu:No caso de não ser informada nenhuma URL de teste, será utilizada uma página inexistente do Google, a fim de obter como retorno uma outra página de erro "404", que sempre é pequena (+/-1KB).
Esta opção, achei muito criativo da tua parte.

Maligno escreveu:E como é mais fácil o inferno esfriar do que o servidor do Google ficar down, é certo que essa página virá se houver conexão.
kakaka, tem razão mesmo !. Eu também tinha escolhida como preferida como site alive.

Maligno escreveu:eu troquei a API do ActiveX por outra melhor, pude desenvolver um código mais controlado
Com esta nova API MALIGNO, ela te dará também melhores recursos para aquela questão de activar janelas minimizadas pelo handle (digamos) ?.

Muito legal esta nova opção, poderemos interagir pela INTERNET com o nosso sistema quase que de forma ONLINE... legal, legal mesmo !.

Um clip abraço MALIGNO, parabéns. :)Pos

MensagemEnviado: 26 Mar 2007 00:51
por Maligno
Pablo César escreveu:Gostei, eu tinha voltado a utilizar PING, mas este achei muito melhor porque tem um verdadeiro TIMEOUT.

Realmente, o PING (ECHO) tem esse problema. E soma-se a isso o problema do U2F, que era o cachê, que acabava retornando um falso positivo para o teste de conexão.

Esta opção, achei muito criativo da tua parte.

Eu procurei por alguma página pequena. Mas tive a idéia de pegar uma mensagem de erro, que é sempre bem pequena. :)

Eu também tinha escolhida como preferida como site alive.

Tem outras: Microsoft, casa branca, Pentágono, etc. Mas o google é mais "popular". :)

Com esta nova API MALIGNO, ela te dará também melhores recursos para aquela questão de activar janelas minimizadas pelo handle (digamos) ?.

Não. A API nova a que me refiro é a WinINet, que presta apenas serviços relacionados à Internet. Ela me pareceu mais flexível que a URLMon, que é usada no U2F. Até fiz um programa melhor usando a URLMon, mas não ficou lá muito bom. A WinINet se encaixou melhor. Ela conta, inclusive, com vários outros recursos, como FTP, por exemplo.

Muito legal esta nova opção, poderemos interagir pela INTERNET com o nosso sistema quase que de forma ONLINE... legal, legal mesmo !.

Só ficou faltando uma coisinha pra ficar realmente muito boa: a interação gráfica com o Clipper, para poder ser feita, por exemplo, uma barra de progresso. Ainda não pude ver muita coisa a respeito, mas a princípio, não será possível montar uma espécie de callback com o Clipper. Se desse, seria ótimo. Não faltaria mais nada. Infelizmente, essa semana foi bem puxada. Não me deram paz. Por esse motivo não pude entregar a atualização do WAPI antes. E, lógico, também não pude pesquisar mais a respeito desse esquema de callback. Mas isso me interessou e quero ver se consigo um tempo pra ver isso mais de perto. Não pude sequer responder às mensagens que você me enviou em private. Eu não tive tempo mesmo. Peço desculpas por isso. Vou respondê-las neste exato momento. :)

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

MensagemEnviado: 26 Mar 2007 05:19
por Maligno
Tive de fazer uma pequena correção no WAPI. Fui fazer um teste no Windows 98 e percebi que havia um erro de "timing" no WAPI ao tentar apagar alguns arquivos temporários. Nada grave. Nenhum serviço estava sendo feito errado. O problema é que "lixo" se acumulava à toa e também um arquivo de retorno de resultado podia não ser aberto, por ainda estar ocupado pelo WAPI, o que gerava um erro. A função de leitura desse arquivo só precisava de mais um "tempinho" pro arquivo ser liberado. Mas no XP isso não acontecia.

O ZIP atualizado já está disponível.
Link para download: http://buzinello.com/download/wapi.zip

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

MensagemEnviado: 26 Mar 2007 09:04
por Pablo César
MALIGNO,

Eu fiz o download de ultimo WAPI.ZIP. Eu guardo todas as versões em pastas diferenciadas pela sua versão (de acordo a tua disponibilização aqui no FORUM), e me pareceu que não foram mudados de tamanho, data e hora os arquivos: WAPI.EXE, WAPI.C, WAPI.LIB. Será que você não errou de versão ao disponibilizá-lo ao público, nesta última ?.

MensagemEnviado: 26 Mar 2007 10:08
por Maligno
Mantive data e hora como a penúltima versão (25/03/2007;01:00), mas repare que o tamanho da LIB mudou. Agora é 56.320 bytes. O WAPI.EXE mesmo não mudou, já que o problema estava numa função da LIB.

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

MensagemEnviado: 26 Mar 2007 10:11
por Pablo César
Retornando um pouco aquela questão de verificar se a sessão foi aberta anteriormente no mesmo PC. Venho insistindo ao MALIGNO à criação de uma nova função que permita abrir (melhor dizer: deixar ativa) uma janela através do HANDLE que servirá como parâmetro obtido da função -GETMYHANDLE do WAPI. Se isto se tornar realidade, penso que a utilização do WAPI para essa questão de MULTI SESSÃO, será de grande vital para RE-ABRIR chamando apenas a sessão que estava aberta e minimizada. Assim como é feito nos aplicativos GUI. Que mesmo que o usuário tente abrir uma 2ª sessão do mesmo aplicativo, o API nem precisa dar mensagem alguma, apenas reabre a sessão deixando-a ativa em exibição e execução. Por isso que eu aposto na solução apresentada pelo MALIGNO com os recursos das APIs do WINDOWS através do WAPI. Esta seria un dos melhores recursos que o WAPI teria, pois irá forçar a chamada da janela que estava minimizada e o usuário não tinha percebido ao clicar novamente no atalho que chamaria por 2ª vez o aplicativo. Daí então também não será necessário ter que pedir pro usuário que mude a tela de exibição. Porque seria só chamar a janela para que fique ativa através dessa nova função do WAPI.

Ja não ocorreu que o usuário diz que a janela DOS do aplicativo sai quando por exemplo o antivirus avisa que precisa ser atualizado ou qua faz qualque interrupção de tela e é afetado a exibição do nossos aplicativos DOS. Fazer o quê...? temos nos adaptar a cada situação. Mas uma coisa digo e que aqui poucos tem a humildade de dizer:

Aplicativos ou bibliotecas geralmente feitas em outra linguagem, só fortalecem a qualidade dos nossos aplicativos em DOS. E o MALIGNO, tem feito uma grandissima contribuição para facilitar nossa vida com CLIPPER. Ao contrário dele, outros dizem para quê ? Seria mais conveniente mudar de linguagem e pronto !. E não estão preocupados em melhorar e/ou ajudar o desenvolvimento em MS-DOS que muitas vezes é justificado a opção em DOS.

MALIGNO, manda ver com essa nova função que estou te pedindo... irá servir para muitos colegas que ainda persistem.

Obrigado, :)Pos

MensagemEnviado: 26 Mar 2007 10:16
por Pablo César
Maligno escreveu:mas repare que o tamanho da LIB mudou. Agora é 56.320 bytes.
Desculpe insistir, mas o tamanho da versão anterior também é de 56.320 bytes. Mas se você está dizendo que manteve a data e hora igual, então não tá aqui quem falou...

Um clip-abraço :)Pos

MensagemEnviado: 26 Mar 2007 11:04
por Maligno
Pablo César escreveu:
Maligno escreveu:mas repare que o tamanho da LIB mudou. Agora é 56.320 bytes.
Desculpe insistir, mas o tamanho da versão anterior também é de 56.320 bytes. Mas se você está dizendo que manteve a data e hora igual, então não tá aqui quem falou...

No dia 25 soltei a LIB com a inclusão do URF2FILE. A LIB deste pacote deve ser ligeiramente menor que 56.320. Se você guarda todos os ZIPs, por favor, confira. O ZIP que soltei nesta madrugada tem uma LIB com exatos 56.320 bytes. É a que contém a correção da função. Não é isso?
Veja: estou falando do WAPI.LIB e não do WAPI.EXE.

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

MensagemEnviado: 26 Mar 2007 11:25
por Pablo César
Maligno escreveu:O ZIP que soltei nesta madrugada tem uma LIB com exatos 56.320 bytes. É a que contém a correção da função.
Isso mesmo, tem esse tamanho (56.320 bytes)

Maligno escreveu:No dia 25 soltei a LIB com a inclusão do URF2FILE. A LIB deste pacote deve ser ligeiramente menor que 56.320.
Negativo. Nessa versão (de acordo o arquivo WAPI.LIB) estava também com (56.320 bytes).

Talvez, se você me dizer em que linha você alterou, porque o WAPI.C teria que estar diferente, não é mesmo ?. Pois estão IGUAIS em tamanho (as duas ultimas versões), ambos WAPI.C tem exatamente 78.000 bytes.

Só não comparei ainda, mas se você me dizer em qual linha você começou +/- a mudar ?. Mas me parece igual no WAPI.C

:|

MensagemEnviado: 26 Mar 2007 11:38
por Maligno
Pablo César escreveu:Só não comparei ainda, mas se você me dizer em qual linha você começou +/- a mudar ?. Mas me parece igual no WAPI.C

Não. O WAPI.C não tem nada a ver. Foram alterados os arquivos READRETF.PRG (linha 33 - entra num while, que antes não existia) e EXECWAPI.PRG (linha 58 - entra num while, que antes não existia).

Mas cho que o ZIP está correto. Baixei de novo e conferi os fontes. Gerei a LIB de novo e comparei com o CRC32 da versão antiga. Bateu. Fique tranqüilo.

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

MensagemEnviado: 26 Mar 2007 11:50
por Pablo César
Ahhh OK, já percebí...

if EraseWAPI()
   nSecs := Seconds()
   while FErase(cWAPI) < 0
... assim por diante

Obrigado pelo esclarecimento. :)Pos

MensagemEnviado: 27 Mar 2007 21:49
por Maligno
Pablo César escreveu:criação de uma nova função que permita abrir (melhor dizer: deixar ativa) uma janela através do HANDLE

Pois está pronto. Só pra efeito de organização, repito mais uma vez a lista de switches, com um asterisco prefixando o novo switch.

  -DELETEREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
  -FLASH:<times>[;<handle>]
  -GETAPPSINFO:<resultFile>
  -GETCLIPBOARD:<resultFile>
  -GETDEFPRINTER:<resultFile>
  -GETHDINFO:<resultFile>
  -GETMYHANDLE:<resultFile>
  -GETPRINTERS:<resultFile>
  -GETWINDOWSINFO:<resultFile>
  -HIBERNATE
  -PLAYWAVE:<source>
  -POWEROFF
  -PRINT:<printerName>;<inputFile>;<reportTitle>;<resultFile>
  -READREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
  -REBOOT
  -SETAPPTITLE:<title>
  -SETBUTTONX:<on|off|del>
  -SETCLIPBOARD:<valueType>;<value>;<resultFile>
  -SETSTARTBUTTON:<hide|show|disable|enable>
  -SETTASKBUTTON:<hide|show>[;<handle>]
  -SUSPEND
  -URL2FILE:<URL>;<fileName>;<timeOut>;<resultFile>
* -WINDOW2TOP:<handle>
  -WRITEREGISTRY:<fullKeyPath>;<entryName>;<valueType>;<value>;<resultFile>


O novo recurso funciona normalmente em kernel NT e Win9x. Só há um inconveniente. Em Windows NT/XP, a janela DOS, mesmo que esteja em tela cheia, será restaurada normalmente. Todas as demais janelas desaparecerão e o DOS voltará a vida, como se tivesse sido executado. Entretanto, mesmo depois de muito pesquisar, não foi possível conseguir o mesmo em Windows 98, se o DOS estiver em tela cheia. Só neste caso. Em modo janela ou mesmo um aplicativo GUI, a operação se completa como esperado.

A função de abstração, já incluída também, se chama Window2Top(<handle>). Detalhes no arquivo README.TXT da pasta WAPI\LIB.

Link para download: http://buzinello.com/download/wapi.zip

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

MensagemEnviado: 28 Mar 2007 08:56
por Pablo César
Aleluiahh ! Muito, muito obrigado MALIGNO !. O problema parece sempre estar com o WIN98... Mas mesmo assim, é uma grande vitória já. Testei no meu sistema e ficou muito bom. Engraçado que no WIN98 o tempo de espera na execução da rotina através do RUNWAPICMD é muito mais rápido do que no WINXP. Como você disse no WINXP funciona tudo OK (transparentemente). Mas no WIN98, se estiver em TELA-CHEIA, não abre de forma ATIVA. Será que nessa tentativa de abrir a janela, a função poderia dar algum retorno (se VERDADEIRO ou FALSO) de acordo com o resultado ?. Ou não tem como retornar o resultado da operação ?. Porque se voltasse FALSO, ao menos eu dava uma mensagem para o usuário dizendo que deve clicar na sessão minimizada (e faria com que piscasse) para chamar atenção ao usuário com efeito visual.

Mas você é um GÊNIO !. Serio mesmo. Sabia que você ia conseguir...

Gracias, muchas gracias ! :)Pos :* -:] :{ :)) :D :)Pos

MensagemEnviado: 28 Mar 2007 09:11
por Maligno
Engraçado que no WIN98 o tempo de espera na execução da rotina através do RUNWAPICMD é muito mais rápido do que no WINXP.

Eu notei que no Windows 98 o retorno do WAPI é mais lento, e não mais rápido.

Será que nessa tentativa de abrir a janela, a função poderia dar algum retorno (se VERDADEIRO ou FALSO) de acordo com o resultado ?.

Sabia que você ia me perguntar isso. Mas não tem jeito. O retorno é um valor lógico invariavelmente positivo. Não tem como saber se deu certo ou não, a não ser visualmente. Inclusive você talvez tenha percebido que a janela atual até perde o foco, mas a janela alvo não é restaurada e focalizada.
Pelo menos resta o console da gente saber que quanto mais o tempo passa, mais enterram o Windows 98. :))

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

MensagemEnviado: 28 Mar 2007 09:31
por Maligno
Acabei de descobrir que compilei errado o WAPI.EXE. Corrigi e subi o arquivo novamente. Para efeito de comparação: a versão do ZIP novo tem exatos 113.501 bytes, contra 113.505 do antigo.

Link: http://buzinello.com/download/wapi.zip

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

MensagemEnviado: 28 Mar 2007 10:17
por Pablo César
(msg repetida)

MensagemEnviado: 28 Mar 2007 10:20
por Pablo César
Puxa vida ! Com a pressa de ver a ultima versão acabei perdendo o ZIP anterior. Possuo todos os arquivos, mas o ZIP, não guardo. Só guardo o último. E confere o tamanho do ultimo ZIP (113.501 bytes). Fiz testes novamente está beleza, salvo quando a tela está em modo TELA-CHEIA.

:(

Com respeito a perder o foco da janela, aqui pra mim deu tudo certo, a janela atual e mando fechar no meu proprio arquivo .BAT, pois seria a segunda sessão (repetida que iria abrir do mesmo aplicativo).

Lamentavelmente, não tenho como forçar a que meus usuários usem em modo JANELADOem WIN98, pois todos eles gostam da TELA-CHEIA. E é engraçado, que alguns por falta de maiores conhecimentos em informática, ficam apavorados quando vêm a sessão em modo JANELADO.

Fazer o quê... quem programa em DOS, sofre... :|

ahhh, lembrei...
Maligno escreveu:Sabia que você ia me perguntar isso.
heee... eu também sabia que você ia dizer isso... kakaka :)Pos :D

MensagemEnviado: 30 Mar 2007 10:15
por Maligno
Me esqueci completamente de avisar: na penúltima alteração que fiz, mudei um código de erro de lugar. Portanto, se alguém usa esta LIB e seus códigos de erro, aconselho recompilar o projeto todo. Mas é só isso.

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

MensagemEnviado: 03 Abr 2007 13:06
por Pablo César
Caro MALIGNO,

Estou intrigado com as re-aberturas de janelas atraves da função WINDOW2TOP. No seu código fonte, menciona uma variável SW_RESTORE. Não sei se o que eu vou perguntar teria sentido, mas gostaria saber se essa variavel SW_RESTORE seria onde guarda as propriedades da JANELA. Estive pensando, que as janelas em modo TELA-CHEIA (das quais ainda não são possíveis re-exibir) talvez não possuem as propriedades da janela e de que as propriedades seriam vitais para a sua reabertura. Pensei que nesses casos, você poderia FORÇAR com atributos (default) caso essas propriedades não existam (por serem provenientes de TELA-CHEIA), ao forçar e re-abrir a sessão DOS, poderiamos então FORÇAR seu modo de exibição, com aquela outra técnica de utilização do SETMODE e com isto fazer com que fique em FULLSCREEN. Aguardo seus comentários.

Um clip-abraço :)Pos

MensagemEnviado: 03 Abr 2007 14:23
por Maligno
Pablo César escreveu:gostaria saber se essa variavel SW_RESTORE seria onde guarda as propriedades da JANELA.

SW_RESTORE é apenas e tão somente uma constante que passa à função ShowWindow() o valor que ela necessita para saber como exibir a janela (ou esconde-la, no caso de uma aplicação Windows/GUI). Inseri essa chamada apenas para a eventualidade da janela alvo estar minimizada. Esta função serve apenas para restaurar a janela (usando ESSA constante). Por meio dela não é possível mudar o modo de visualização da janela DOS, embora seja possível maximizar uma janela Windows/GUI. Usando outra constante, claro.
Quem faz a troca de foco é a função SetForegroundWindow(). Portanto, não será possível levar adiante sua idéia. Até porque, a idéia de maximizar, em se tratanto de uma sessão DOS, tem um sentido diferente da troca de modo de visualização (fullScreen/windowed). Note que há um botão de maximização na janela DOS. Mas o efeito que ele proporciona é bem diferente.

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

MensagemEnviado: 03 Abr 2007 17:37
por Pablo César
Maligno escreveu:Inseri essa chamada apenas para a eventualidade da janela alvo estar minimizada.
No meu caso, na maioria dos casos, a janela está MINIMIZADA.

Maligno escreveu:embora seja possível maximizar uma janela Windows/GUI. Usando outra constante, claro.
E o quê faltaria para também maximizar a SESSÃO-DOS (que não possue JANELA alguma, isto é, não é WINDOWED é TELA-CHEIA) ?. Tem como explicar essa situação ?. É dizer, você consegue ver a diferença de propriedades de uma janela e outra ?.

Mesmo que não fosse possível restaurar em modo TELA-CHEIA, eu me conformaria que a SESSÃO-DOS (que estava em modo TELA-CHEIA) e que pudesse estar minimizada pudesse ser RESTAURADA ou MAXIMIZADA mesmo em modo WINDOWED.

Dificil, né ? :-o

MensagemEnviado: 04 Abr 2007 08:29
por Maligno
E o quê faltaria para também maximizar a SESSÃO-DOS (que não possue JANELA alguma, isto é, não é WINDOWED é TELA-CHEIA) ?. Tem como explicar essa situação ?. É dizer, você consegue ver a diferença de propriedades de uma janela e outra ?.

Imagino que você está fazendo confusão nos termos. Maximizar uma sessão DOS não a faz entrar em modo tela cheia (full screen). Se é isso o que quer saber, eu não encontrei qualquer informação acerca da troca de modos.

Mesmo que não fosse possível restaurar em modo TELA-CHEIA, eu me conformaria que a SESSÃO-DOS (que estava em modo TELA-CHEIA) e que pudesse estar minimizada pudesse ser RESTAURADA ou MAXIMIZADA mesmo em modo WINDOWED.

Isso só não acontece com o Windows 98, pelos testes que fiz.

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

MensagemEnviado: 04 Abr 2007 09:40
por Pablo César
Maligno escreveu:Imagino que você está fazendo confusão nos termos.
Vamos dizer que você tem duas opções de "REATIVAR" e/ou "DEIXAR VIGENTE" a sessão NHandle da função WINDOW2TOP, seria MAXIMIZAR ou RESTAURAR a JANELA da sessão. É por isso que eu utilizo o termo MAXIMIZAR. Eu sei que MAXIMIZAR não é o mesmo que fazer retornar a aplicação em TELA-CHEIA. Mas no fim, eu creio que você entendeu o que eu quis dizer. Em síntese (desculpa insistir) o que eu queria dizer, a questão toda deve estar nas propriedades da janela. Quando digo, propriedades são: tamanho, título, botões habilitados, etc...
Isto porque acredito que deva existir alguma diferença entre o modo TELA-CHEIA e o JANELADO em algumas das propriedades. Por isso que te pergunto, se você consegue LER as propriedades da janela. Você consegue ?.

Veja no link: Código_Exemplo onde menciona:
The first step is to find the handles of the three main windows that handle the TaskBar, Standard Input Panel (SIP) and SIP Button Bar.
Eu sei que você vai pensar... mas isto é para WINDOWS CE, mas o que eu quero FRISAR, é que talvez seriam essas propriedades (ou apropriadamente seriam HANLDES) que façam a diferença entre um modo e outro (modo TELA_CHEIA e JANELADO). Avete capito, collega ?.

Porque abaixo nesse mesmo link, no item: "Toggling Between The Two Modes" mostra a diferença dos dois modos, tal é assim que no fonte do Barney L. Parker diz:

void ToggleFullScreen ()
{
    RECT rtDesktop;

    if (mode)
if (mode) não estaria já definido o modo de TELA-CHEIA (FULLSCREEN) da JANELADA (WINDOWED) ?

Maligno escreveu:Isso só não acontece com o Windows 98, pelos testes que fiz.
Você está certíssimo !. Eu tinha feito testes, mas não percebí que no WINXP faz a recuperação da sessão TELA-CHEIA para JANELADO. Ao menos, isso é uma BOA !. Pena que no WIN98, ja no acontece isso. Parece que o WIN98 é sempre o nosso CARMA !.

Desculpa colega, pela minha insistência, sei que você está se esforçando muito para encontrar um solução para isto. Eu por outro lado, não consigo ajudar melhor, pois não conheço da linguagem C. Mas eu acredito firmemente que diferenças nos "TaskBar, Standard Input Panel (SIP) e SIP Button Bar". Agora suponhamos também que mesmo que você consiga ver a diferença deles na sua função e não consiga manipulá-los, eu acharia que você poderia dar um retorno na função com um novo número de erro (digamos). Daí saberei que é pra dar uma mensagem pro usuário. Tipo: "Clique na sessão minimizada piscando..." (po exemplo).

Você está tão perto... (de me mandar para aquele lugar.... quem sabe ? hehe) e eu agradeço a sua atenção. Pois desta forma ou outra você consegue cativar cada vez mais a liguagem C que eu tanto gostaria de aprender.

Um clip-abraço, colega. E desculpa a minha chatisse. :{ :)Pos

MensagemEnviado: 04 Abr 2007 10:28
por Maligno
Vamos dizer que você tem duas opções de "REATIVAR" e/ou "DEIXAR VIGENTE" a sessão NHandle da função WINDOW2TOP, seria MAXIMIZAR ou RESTAURAR a JANELA da sessão. É por isso que eu utilizo o termo MAXIMIZAR.

Não use mais, pois isso só causa confusão. O termo maximizar, que existe em sessão DOS, nada tem a ver com mudança de modo (janela/tela cheia). Maximizar em DOS significa magnificar a janela DOS até o limite do tamanho da janela, da mesma forma que se faz em um programa GUI. A diferença é que programas GUI podem, na maior parte das vezes, ocupar todo o desktop.
Façamos um trato: vamos usar apenas os termos JANELA e TELA CHEIA, que é o certo, aliás. Senão, você diz uma coisa e eu entendo outra. Esqueça o termo maximizar, que não se aplica ao nosso problema. Use o termo troca de modo.

Isto porque acredito que deva existir alguma diferença entre o modo TELA-CHEIA e o JANELADO em algumas das propriedades. Por isso que te pergunto, se você consegue LER as propriedades da janela. Você consegue?.

Não. Se tivesse conseguido isso o problema já estaria resolvido. E nem há um local único onde se consegue obter todas essas informações de um só vez.

Eu sei que você vai pensar... mas isto é para WINDOWS CE, mas o que eu quero FRISAR, é que talvez seriam essas propriedades (ou apropriadamente seriam HANLDES) que façam a diferença entre um modo e outro (modo TELA_CHEIA e JANELADO). Avete capito, collega?.

Capisco. Mas, sendo Windows CE ou não, este link não diz nada que eu já não saiba.
Note: os handles nada mais são que números de controle de instanciamento. Eles não me dão acesso a nada. Apenas me servem para informar o Windows sobre qual instância estou me referindo quando executo determinada função.

Porque abaixo nesse mesmo link, no item: "Toggling Between The Two Modes" mostra a diferença dos dois modos, tal é assim que no fonte do Barney L. Parker diz:

void ToggleFullScreen ()
{
    RECT rtDesktop;

    if (mode)
if (mode) não estaria já definido o modo de TELA-CHEIA (FULLSCREEN) da JANELADA (WINDOWED) ?

Repare que a variável pública mode representa um simples valor binário, já que ela é tratada como uma expressão lógica.

Mas eu acredito firmemente que diferenças nos "TaskBar, Standard Input Panel (SIP) e SIP Button Bar".

Pois então desacredite. Partindo do princípio: seu desktop é criado por um programa comum (explorer.exe) como um simples componente visual do tipo ListView. Os botões da taskbar e a própria taskBar são simples componentes visuais, como os utilizados em muitos programas. Portanto, eles não contém (e não se pode obter através deles) quaisquer informações úteis que possam ajudar a resolver o problema da troca de modo de uma sessão DOS.

Agora suponhamos também que mesmo que você consiga ver a diferença deles na sua função e não consiga manipulá-los, eu acharia que você poderia dar um retorno na função com um novo número de erro (digamos). Daí saberei que é pra dar uma mensagem pro usuário. Tipo: "Clique na sessão minimizada piscando..." (po exemplo).

Seria uma boa solução. Paleativa, mas melhor que nada. Mas eu já havia comentado com você que isso também não será possível. Primeiro que não tenho o que executar para tentar trocar de modo. Segundo que o Windows, quando executa funções do tipo, ele apenas executa, não verificando se o que foi pedido foi de fato efetuado corretamente. Veja o caso da função SetForegroundWindow() do switch -WINDOW2TOP. A função executa perfeitamente no Windows 98. Eu tenho um retorno TRUE. Mas a sessão DOS não é realmente colocada à frente, como acontece no XP. Logicamente, o retorno TRUE não se refere à "conferência" da execução do serviço, mas apenas à execução da função.

De qualquer forma, valeu o seu esforço pelas novas tentativas. E continuamos tentanto. Conforme o tempo permitir. :)

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

MensagemEnviado: 04 Abr 2007 11:49
por Pablo César
Maligno escreveu:Façamos um trato: vamos usar apenas os termos JANELA e TELA CHEIA... e também: Use o termo troca de modo.
OK

Maligno escreveu:Note: os handles nada mais são que números de controle de instanciamento. Eles não me dão acesso a nada. Apenas me servem para informar o Windows sobre qual instância estou me referindo quando executo determinada função.
Então acredito que o que faltaria é um RECURSO que possibilite a interpretação da CONDIÇÃO de tais INSTANCIAMENTOS ?.

Maligno escreveu:Repare que a variável pública mode representa um simples valor binário, já que ela é tratada como uma expressão lógica.
Sim, claro. Ela começou como false onde o código define:
false // Our current window mode.  
        //  True = Fullscreen
        //  False - Windowed (Startup Default)

Mas pode ver que ela é re-atribuída caso obedeça a condição:
if (hWndTaskBar != NULL);if (hWndInputPanel != NULL) ;if (hWndSipButton != NULL)
Teria ela mudado caso ela não fosse MODO TELA-CHEIA ?

Maligno, você teria como compilar este código, ou até mesmo adaptando ao GCC ?. Assim conseguiria entender bem o que este código faz ?.

Maligno escreveu:Veja o caso da função SetForegroundWindow() do switch -WINDOW2TOP. A função executa perfeitamente no Windows 98. Eu tenho um retorno TRUE. Mas a sessão DOS não é realmente colocada à frente, como acontece no XP.
Se não acontence na sessão DOS, então não é executado "perfeitamente". Alí você quer dizer que é executado sem erro. É isso ?.

Maligno escreveu:Logicamente, o retorno TRUE não se refere à "conferência" da execução do serviço, mas apenas à execução da função.
Isto entendí bem, assim como outros recursos que utiliza API no WAPI.

Grazie, molto per la tua attenzione. Um clip-abraço :)Pos

MensagemEnviado: 04 Abr 2007 14:19
por Maligno
Então acredito que o que faltaria é um RECURSO que possibilite a interpretação da CONDIÇÃO de tais INSTANCIAMENTOS ?.

Sim. Algo que me dê o status da sessão.

Maligno, você teria como compilar este código, ou até mesmo adaptando ao GCC ?. Assim conseguiria entender bem o que este código faz ?.

Nem vou perder tempo com isso. Olhando o código já sei que ele não vai ajudar.

Se não acontence na sessão DOS, então não é executado "perfeitamente". Alí você quer dizer que é executado sem erro. É isso ?.

Exatamente. Embora algumas funções da API sejam executadas normalmente em outras plataformas, o efeito final não é atestado pelo retorno da função.

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

MensagemEnviado: 04 Abr 2007 17:54
por Pablo César
Caro colega BOM MALIGNO (hehe, que contradição nas palavras... não é quanto a sua pessoa, viu ? Your are a very GOOD GUY)

:{ :)Pos

Achei na INTERNET estes 3 aplicativos FULLSCRN:

http://homepage3.nifty.com/norza/soft/petty/fullscrn.com

http://www.columbia.edu/~em36/wpdos/fullscrn.exe

ftp://barnyard.syr.edu/pub/vefatica/fstoggle.exe

Funcionam, mas infortunamente não sempre dá o resultado esperado. As vezes, trava, as vezes aparece aquela famosa TELA AZUL do RUINDOWS. Mas na sua maioria funciona, mas não SEMPRE. Será que esses aplicativos são aplicativos feito a moda KAMIKAZE ?.

E você viu também no tópico que acabei de adicionar: http://www.pctoledo.com.br/forum/viewto ... 1&start=17 que trata sobre o WHOAMI. Parece que isto funciona bem, a salvo da mensagem que aparece quando não é logado e quero REDIRECIONAR em arquivo (o arquivo cria) com tamanho ZERO mas dá mesmo assim a mensagem de não LOGADO. Quem sabe, você conseguisse acrescer mais este recurso ao WAPI.

Um clip-abraço :)Pos

MensagemEnviado: 04 Abr 2007 18:17
por Maligno
Funcionam, mas infortunamente não sempre dá o resultado esperado. As vezes, trava, as vezes aparece aquela famosa TELA AZUL do RUINDOWS. Mas na sua maioria funciona, mas não SEMPRE. Será que esses aplicativos são aplicativos feito a moda KAMIKAZE ?.

Acontece que esses três programas são do tempo do Windows v3.1. O primeiro, fullscrn.com, usa a multiplex do DOS para mudar o foco da janela virtual. O segundo, fullscrn.exe, faz o mesmo, mas depois também comuta para o modo texto 80x25. O terceiro, fstoggle.exe, mais elaborado, faz o mesmo. A diferença de tamanho é porque ele foi feito em C, ao que me parece.
Para comutar do modo janela para tela cheia, ainda prefiro minha função WinFullScr(), que tem a vantagem de residir no próprio programa.

E você viu também no tópico que acabei de adicionar: que trata sobre o WHOAMI...
Quem sabe, você conseguisse acrescer mais este recurso ao WAPI.

Vi a thread. Sobrando um tempinho dou uma olhada com mais atenção. Mas, a princípio, tudo é possível. :)

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

MensagemEnviado: 05 Abr 2007 10:11
por Maligno
Sobrando um tempinho nesta madrugada, resolvi pesquisar a respeito e acabei incluindo mais um switch, para obter várias informações acerca do sistema.

  -DELETEREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
  -FLASH:<times>[;<handle>]
  -GETAPPSINFO:<resultFile>
  -GETCLIPBOARD:<resultFile>
  -GETDEFPRINTER:<resultFile>
  -GETHDINFO:<resultFile>
  -GETMYHANDLE:<resultFile>
  -GETPRINTERS:<resultFile>
* -GETSYSTEMINFO:<resultFile>
  -GETWINDOWSINFO:<resultFile>
  -HIBERNATE
  -PLAYWAVE:<source>
  -POWEROFF
  -PRINT:<printerName>;<inputFile>;<reportTitle>;<resultFile>
  -READREGISTRY:<fullKeyPath>;<entryName>;<resultFile>
  -REBOOT
  -SETAPPTITLE:<title>
  -SETBUTTONX:<on|off|del>
  -SETCLIPBOARD:<valueType>;<value>;<resultFile>
  -SETSTARTBUTTON:<hide|show|disable|enable>
  -SETTASKBUTTON:<hide|show>[;<handle>]
  -SUSPEND
  -URL2FILE:<URL>;<fileName>;<timeOut>;<resultFile>
  -WINDOW2TOP:<handle>
  -WRITEREGISTRY:<fullKeyPath>;<entryName>;<valueType>;<value>;<resultFile>


O switch retorna uma lista de strings (separadas por vírgulas), onde constam:

1) Nome do computador
2) Nome do usuário logado no sistema
3) Diretório de instalação do Windows (nome longo)
4) Idem, nome curto
5) Diretório do sistema (nome longo)
6) Idem, nome curto
7) Diretório de instalação de programas (nome longo)
8) Idem, nome curto
9) Diretório do desktop do usuário (nome longo)
10) Idem, nome curto
11) Diretório do desktop para todos os usuários (nome longo)
12) Idem, nome curto
13) Diretório da pasta "Meus Documentos" (nome longo)
14) Idem, nome curto

A função de biblioteca, GetSysInfo(), naturalmente, retorna uma matriz.

Download: http://buzinello.com/download/wapi.zip

E a recomendação de sempre: leia o README.TXT no diretório WAPI\LIB para conhecer os detalhes das funções e/ou o fonte WAPI.C para conhecer os switches.

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

MensagemEnviado: 05 Abr 2007 11:10
por Pablo César
LEGAL !. Esta função é bem completa. Pensar que eu fazia rodar todo uma listagem através do RUN DIR > DIR.TXT e ainda sujeito a não funcionar adequadamente ora pelo WINXP ou pelo VISTA por causa do sinal de re-direcionamento ">". Além do mais que demorava e sujeito a erro estava a minha rotina.

Sem falar do NOME-COMPUTADOR e NOME-DO-LOGADO, que me estava sendo falta.

Eu acho que quando o programador decide fazer um SISTEMA, deve pensar de forma que SIMPLEFIQUE a vida do usuário, tem que ser VERSÁTIL (independente da versão do WINDOWS), com RECURSOS que possibilite a CONFIGURAÇÃO do SISTEMA pelo próprio usuário. Tudo isto isto aliado com AGILIDADE e PRATICIDADE. Parece redundante, não é ?. Mas veja bem, que os nossos esforços valem a pena para que o CLIENTE fique SATISFEITO e consiga PRODUZIR cada vez mais. Porque se o cliente está BEM, NÓS também iremos estar. A idéia de fazer um SISTEMA que se ADECUE ao CLIENTE e não o CLIENTE que deva se ADECUAR ao SISTEMA. Isto é qualidade do PRODUTO.

Obrigado, MALIGNO ! Esta BIBLIOTECA está cada vez MELHOR !.

Percebí que no seu código-fonte, é utilizado uma função interna chamada GETSHORTPATHNAME(). Esta função faria com a "tradução" do modo de NOMES-CURTOS ?. E será, que não seria possível disponibilizá-la pra nós também dentro do WAPI ?. Daí então acho que você poderia sintetizar o número de resultados (VETORES após leitura do arquivo-de-resultado) da função -GETSYSTEMINFO. Desta forma não precisaria gravar em arquivo os NOMES-CURTOS e sim os NOMES-LONGOS para posteriormente passar pela função de "tradução", isto conforme usuário solicitar. Que você acha de adicionar o recurso do GETSHORTPATHNAME() e sintetizar o resultado da função -GETSYSTEMINFO ?.

Mais uma vez obrigadão ! :)Pos :D :)) -:]

MensagemEnviado: 05 Abr 2007 11:50
por Maligno
Que você acha de adicionar o recurso do GETSHORTPATHNAME() e sintetizar o resultado da função -GETSYSTEMINFO ?.

Não vejo razão pra isso. Se você utiliza nomes longos, obrigatoriamente você terá de usar aquela biblioteca para Clipper (LBFN?), que internamente já possui uma função de conversão. Portanto, não há necessidade. E para quem não usa nomes longos, o WAPI já fornece as duas formas.

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

MensagemEnviado: 05 Abr 2007 12:12
por Pablo César
Só achei que com essa outra função de tratamento de NOMES-LONGOS, o WAPI ficaria mais ainda versátil. Eu deixaria de usar essa outra biblioteca LBFN. Ou a função interna GETSHORTPATHNAME(), não é confiável ?. Além do mais, sempre é bom ter a opção de NOMES-CURTOS e os resultados do-GETSYSTEMINFO deixariam de ser redundantes com a nova opção.

Mas enfim, não há drama algum !. A biblioteca é sua, e você sabe avaliar o que é bom pra ela. Assim, como mostrar a versão da biblioteca, pois sempre haverá alguém que tenha uma versão anterior querendo fazer algo que na versão mais atual tenha. Think about !

Um clip-abraço :)Pos

MensagemEnviado: 05 Abr 2007 13:23
por Maligno
Só achei que com essa outra função de tratamento de NOMES-LONGOS, o WAPI ficaria mais ainda versátil. Eu deixaria de usar essa outra biblioteca LBFN.

Se você usa a LBFN é porque usa nomes longos. Você precisa dela. E se precisa dela, não precisa de outra função para obter os nomes curtos. Aí sim seria redundância. Além do que, no WAPI quero oferecer apenas serviços que não existam em Clipper. Não é o caso dessa função.

Ou a função interna GETSHORTPATHNAME(), não é confiável ?.

É uma função da API do Windows. Imagino que possa confiar nela. :)

Além do mais, sempre é bom ter a opção de NOMES-CURTOS e os resultados do-GETSYSTEMINFO deixariam de ser redundantes com a nova opção.

Não vejo redundância, uma vez que são outras versões dos nomes. Além do que, incluí essa opção apenas porque havia "espaço" para o switch crescer. Resolvi incluir os nomes curtos para os casos daqueles que não usam nomes longos, como eu. Era uma necessidade.

mostrar a versão da biblioteca, pois sempre haverá alguém que tenha uma versão anterior querendo fazer algo que na versão mais atual tenha.

Ah, sim. Já estou pensando nisso. Mas provavelmente não será um switch.

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

MensagemEnviado: 05 Abr 2007 15:39
por Pablo César
MALIGNO, me permita fazer algumas aclarações e sugestões.

Maligno escreveu:Se você usa a DBLFN é porque usa nomes longos.
Bem, na maioria dos casos eu preciso dos nomes de arquivos e/ou drietórios de forma CURTA, não longa. Hoje em dia é mais comum encontrar os nome em modo LONGO, mas por questão do DOS é preciso em modo CURTO. E o DBLFN.LIB possue as duas funções: LFNSHORT e LFNLONGTOSHORT, cujos nomes ja diz o que elas fazem. Veja outros recursos desta LIB também: http://www.ousob.com/ng/lfnlib/ng249.php

Maligno escreveu:Não vejo redundância ... //... Resolvi incluir os nomes curtos para os casos daqueles que não usam nomes longos
Ok, perfeito, acho útil pois daí não precisaria usar o DBLFN. Eu me expressei mal quando. Eu quiz dizer que se você fizesse uma nova função para conseguir os NOMES-CURTOS, alguns itens do resultado do GETSYSTEMINFO passariam a ser redundantes porque daí então não haveria necessidade de gerar os caminhos em modo CURTO.

Maligno escreveu:Ah, sim. Já estou pensando nisso. Mas provavelmente não será um switch.
Seria bom que o WAPI.EXE, ao ser executado sem parâmetro algum, mostrasse a versão e/ou o mesmo na WAPI.LIB, quando chamada sem parâmetro algum.

Aceite mais uma sugestão, MALIGNO. Vejo que a sua documentação é bem extensa e completa. Ja pensou fazer em arquivo .NG ? Da qual todos estamos acostumados a utilizar.

Um clip-abraço :)Pos

MensagemEnviado: 05 Abr 2007 19:51
por Maligno
Pablo César escreveu:na maioria dos casos eu preciso dos nomes de arquivos e/ou drietórios de forma CURTA, não longa.

Estou na mesma situação. :)

Eu quiz dizer que se você fizesse uma nova função para conseguir os NOMES-CURTOS, alguns itens do resultado do GETSYSTEMINFO passariam a ser redundantes porque daí então não haveria necessidade de gerar os caminhos em modo CURTO.

É verdade. Mas realmente não há necessidade disso. Quem for usar nomes longos, obrigatoriamente precisará usar a lib LFN. E se usar, não precisará deste recurso no WAPI.

Seria bom que o WAPI.EXE, ao ser executado sem parâmetro algum, mostrasse a versão

Pois é exatamente isso que vou fazer.

Ja pensou fazer em arquivo .NG?

Já pensei. Mas só pensei. :)))) Vai demorar um pouco mais.

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

MensagemEnviado: 05 Abr 2007 20:00
por Pablo César
Eu sugerí a criação do NG, mas eu não sei como fazer. Sei que existe um aplicativo ou uma LIB que é possível construir tais NGs. Se eu conseguisse aqui no FORUM explicação e utilitário de como fazer, eu me habilito para ajudar a fazer baseado na sua documentação. Se você quiser.

Um clip-abraço :)Pos

MensagemEnviado: 05 Abr 2007 21:16
por Maligno
* * * * * * * * * * * * * * * * * * * * *

A linha espalhafatosa serve apenas para marcar o fim de uma fase e o início de outra na história do WAPI, pois daqui por diante teremos um acompanhamento pelo número da versão.
Como o WAPI cresceu bastante (já temos 25 switches), a partir deste ponto estou considerando o WAPI concluído. Sua versão agora é a 1.00.
Daqui pra frente, todas as inclusões e/ou modificações acrescentarão um número ao release, e será acrescido algum comentário no arquivo de histórico de versão. Tal arquivo ainda não existe. Será criado a partir da próxima modificação que vier.
Para saber qual é a versão que está usando, basta executar o WAPI.EXE sem qualquer argumento. Lá aparecerá o número da versão, mes/ano e link para o download oficial. Não haverá um switch para ler o número da versão em arquivo.

Download já disponível: http://buzinello.com/download/wapi.zip

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

MensagemEnviado: 05 Abr 2007 21:59
por Pablo César
Ok, pra mim esta ultima versão é a décima quarta versão. :)Pos

MensagemEnviado: 10 Abr 2007 09:50
por Maligno
Para a próxima atualização, já tenho pronto o bloqueio total ou parcial do teclado. E outras coisas mais. Já está pronto, funcionando em Windows 98 e NT/XP. Mas antes de liberar, tenho de fazer o WAPI se tornar residente.

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

MensagemEnviado: 10 Abr 2007 11:16
por sygecom
Buenas...
Tche, Maligno me tira uma duvida, em que e pq se bloquearia o teclado total ou parcial ?

Obs: sei que pra ECF é obrigatorio fazer isso.

Abraços

MensagemEnviado: 10 Abr 2007 11:23
por Maligno
Obs: sei que pra ECF é obrigatorio fazer isso.

Você próprio já deu um motivo. Mas há outros: às vezes o sujeito tem o péssimo hábito de apertar a WinKey pra acionar outra aplicação e acaba se perdendo pra voltar ao seu programa DOS. A solução é bloquear a WinKey. Às vezes (programas de caixa, por exemplo) ao usuário não se deveria permitir dar uma escapada do programa. Solução: bloquear todas as teclas especiais ou mesmo forçar o programa a rodar num desktop à parte (só XP), bloquear o desktop inteiro, etc. E por aí vai...

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

MensagemEnviado: 10 Abr 2007 11:46
por sygecom
Maligno, valeu pela explicação.......me diga uma ultima coisa...nesse bloqueio parcial vai ter como bloquear por ex: CTRL+ALT+DEL ou ALT+C .....????

Abraços e Boa Semana !!!

MensagemEnviado: 10 Abr 2007 12:00
por Maligno
nesse bloqueio parcial vai ter como bloquear por ex: CTRL+ALT+DEL ou ALT+C .....????

Claro.

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

MensagemEnviado: 10 Abr 2007 15:57
por Pablo César
Surgiu-me uma idéia em razão dessa nova função. Talvez eu esteja sonhando e não teria como fazer. Mas se você consegue bloquear a teclas tais e tais... Claro que também irão retornar ao normal as mesmas bloqueadas, isto é, você consegue identificar TODAS as teclas, certo. Mas haveria possibilidade de ACIONAR-LAS ? Assim como nós fazemos com o KEYBOARD ou o KBDEMULATE() do CT.LIB ??

Sei lá... é apenas uma indução de idéias... É possível ? :-o

MensagemEnviado: 10 Abr 2007 16:08
por Maligno
Pablo César escreveu:É possível?

Sim, é possível injetar códigos de teclas para uma aplicação específica. Porque? Que idéia você teve?

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

MensagemEnviado: 10 Abr 2007 19:10
por Pablo César
Eu já vi tópicos aqui perguntando se há possibilidade de acionar a tecla ALT ENTER. Porque daí seria muito conveniente usar esse recurso por exemplo: para alternar de janela ao utilizar uma aplicação GUI.

Também daria (quando for em WIN98) alternar o modo de exibição para quando tiver a necessidade de recuperar a sessão pelo WINDOW2TOP seja possível em modo janelado.

sendo possível acionar as teclas ALT ENTER, em ambas situações, apenas alternará ora em modo JANELADO ou ora em modo TELA-CHEIA (sem saber em que modo está), portanto ainda restaria saber (antes de excutar o ALT-ENTER) em que modo estaria a janela, não é ?. Mas mesmo assim teria utilidade, pois este recurso de acionar ALT ENTER por exemplo no comando do DOS não existe aplicativo algum que faça isso. Ou pelo menos desconheço.

No meu caso, o 99% dos meus clientes gostam de usar em modo TELA-CHEIA e 80% ainda gostam do WIN98 (daí usarei mesmo assim). Engraçado, né ? (sobre a preferência). Mas sei que ainda isto mudará um dia. Mas como sabemos, o WINDOW2TOP do WAPI funciona bem com WINXP.

Um clip-abraço :)Pos

MensagemEnviado: 10 Abr 2007 20:42
por Maligno
Até imaginei que você fosse tocar no assunto do Alt+Enter. Mas observe que adicionar essa característica no WAPI não ajudará em nada, já que esse atalho serve apenas para alternar entre modos. Ainda se houvesse um atalho para, especificamente, mudar para fullScreen, o problema já seria amenizado. Mas não é esse o caso.

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

MensagemEnviado: 10 Abr 2007 21:40
por Pablo César
Pois é... Você já até antecede o que vou a dizer...

Sei que não é uma solução, mas já ajudaria. Será que você poderia fazer com que pudesse passar como parâmetro as teclas a que forem ser invocadas de acordo com o arquivo.ch ?. Seria viável ?.

Um clip-abraço :)Pos

MensagemEnviado: 10 Abr 2007 22:47
por Maligno
Pablo César escreveu:Sei que não é uma solução, mas já ajudaria.

Discordo totalmente. Não ajudaria em nada ficar comutando de janela para fullScreen, de fullScreen para janela. Esta é a função de Alt+Enter. Ajudaria em quê, se você não sabe em que modo está?
E fora o atalho Alt+Enter, não há nenhuma outra tecla ou atalho relevante que precise ser injetado pelo Windows.

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

MensagemEnviado: 11 Abr 2007 12:29
por Pablo César
Sim, eu sei disso. Esse é um problema sério ainda. Vou enviar uma mensagem a Microsoft para ver se existiria algum caminho para esse dilema.

:(

MensagemEnviado: 11 Abr 2007 16:27
por Maligno
Pablo César escreveu:Sim, eu sei disso. Esse é um problema sério ainda. Vou enviar uma mensagem a Microsoft para ver se existiria algum caminho para esse dilema.

No grupo de notícias da Microsoft, você quer dizer. Já tentei no grupo da Borland, sem sucesso. Ninguém soube me responder. Mas se você tiver a paciência de tentar, vá em frente. Qualquer novidade é só dizer.

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

MensagemEnviado: 11 Abr 2007 20:16
por Pablo César
Acabei de postar meu pedido de ajuda numa espécie de FORUM (na Microsoft), pior que eu fechei a janela e agora não temnho o endereço. Mas se me responderem, eu aceitarei a sua ajuda, pois postei numa seção de linguagem C. Também me inscreví em dois FORUNS para linguagem C, um no ABRIL e outro que ainda espero receber a minha senha por email (mas até agora nada). Espero obter resposta e te deixarei a par das mensagens.

Um clip-abraço :)Pos

MensagemEnviado: 11 Abr 2007 20:31
por Maligno
Pablo César escreveu:Também me inscreví em dois FORUNS para linguagem C, um no ABRIL e outro que ainda espero receber a minha senha por email (mas até agora nada).

Fórum da Abril? E qual é o outro?

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

MensagemEnviado: 11 Abr 2007 22:52
por Pablo César
São estes:

http://www.aeiou.pt/registos/f/Forum_so ... gem_C.html (Mas este ainda não conseguí postar porque ainda não me passar a minha senha para acesso).
http://forum.abril.com.br/info/topicos.php?area=142

O terceiro foi feito na Microsoft, mas como eu disse, perdí o link onde entrei através do meu passaporte do MSN.

Um clip-abraço :)Pos

MensagemEnviado: 13 Abr 2007 09:36
por Pablo César
Maligno,

Quando é deletado qualquer arquivo através do DOS, esses arquivos não aparecem na LIXEIRA do WINDOWS, portanto não há possibilidade de recuperá-los. Existe possibilidade de ser deletado pelo WAPI com possibilidade de restraurar da LIXEIRA ?. Que você acha ?

Digo isto, porque ontem a noite tive de ir a um cliente para deletar um arquivo da ficha de um cliente. Este arquivo estava corrompido. Não é usual, mas esta é a segunda vez que me acontece e eu levo uma cara para descobrir. Claro que agora em mais, terei em conta a experiência passada. Foi dificil entender o erro que estava causando esse bendito arquivinho. Dava como "corruption detected", nós logo pensamos: algum problema no arquivo de índices. Mas não é, quando você tenta abrir pelo DBU é que você percebe que aquele arquivinho está baleado. Como eu disse, em anos este é o segundo caso, mas também quer o quê... o cliente não tem NO-BREAK e lá a toda hora há PICOS de energia. Vou fazer um tratamento que identifique esse erro. Mas contar com uma possibilidade de recuperá-lo (claro que antes iria RENOMEAR dentro do meu sistema) seria muito importante.

Um clip-abraço.

MensagemEnviado: 13 Abr 2007 09:58
por Maligno
Existe possibilidade de ser deletado pelo WAPI com possibilidade de restraurar da LIXEIRA ?. Que você acha ?

Possibilidade existe. Mas eu não acho nada. Nunca pensei nisso. Aliás, dificilmente apago alguma coisa nos meus programas. A não ser DBFs temporários. Aliás, nem sou eu quem apaga. Quando o DBF é temporário o meu sistema de controle já o abre no modo exclusivo e o apaga quando ele é fechado. É tudo automático.

Digo isto, porque ontem a noite tive de ir a um cliente para deletar um arquivo da ficha de um cliente. ...

Não entendi o que esse "causo" tem a ver com a lixeira?

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

MensagemEnviado: 13 Abr 2007 10:33
por Pablo César
Maligno escreveu:Aliás, dificilmente apago alguma coisa nos meus programas. A não ser DBFs temporários. Aliás, nem sou eu quem apaga. Quando o DBF é temporário o meu sistema de controle já o abre no modo exclusivo e o apaga quando ele é fechado. É tudo automático.
Não tudo bem... essa questão sua é válido também. Mas é que eu não posso deletar aquele arquivinho, enquanto tiver algum registro dentro. Digamos que é uma arquivo QUASE que temporário. Só apagaria em extrema necessidade. claro que poderia RENONEAR, também. Mas se eu apagasse (pelo sistema digo) e o cliente precise dele recuperado (claro que teriamos que utilizar um aplicativo para REPARO), mas como no meu caso não é dramático DELETÁ-LO, então a minha opção mais válida, seria deleta-lo. Mas em caso que quisesse e existisse alguma forma de deletar colocando-o na LIXEIRA, seria como trabalhar no padrão WINDOWS.

Maligno escreveu:Não entendi o que esse "causo" tem a ver com a lixeira?
CAUSO ? Essa palavra me lembra... Clique aqui

Hehehe... é uma graça apenas, não me leve a mal... :D

MensagemEnviado: 13 Abr 2007 11:08
por Maligno
Mas em caso que quisesse e existisse alguma forma de deletar colocando-o na LIXEIRA, seria como trabalhar no padrão WINDOWS.

Mas você quer usar a lixeira como repositório? Isso realmente não é uma boa idéia. Alguém pode apagar a lixeira sem saber. Daí, danou-se. É melhor você optar por um diretório de repositório na cadeia de diretórios do seu programa.

CAUSO ? Essa palavra me lembra...

Ah, eu vi. :))))

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

MensagemEnviado: 13 Abr 2007 11:47
por Pablo César
a lixeira como repositório... Não longe disso !. É que neste meu caso, o mais indicado não é guardar o arquivo. O mais indicado é DELETAR, mesmo. Ora porque para o usuário REFAZER o seu conteúdo seria mais fácil do que aplicar o FILEFIX (por exemplo) para recuperar o arquivo DANIFICADO.

E tem mais um exemplo. No meu sistema tenho uma opção de criar (não é CAMPO MEMO... hehehe) arquivos "quase que temporários", são arquivos para dar um recado, é feito através do MEMOEDIT e é guardado em pasta exclusiva para isso. Uma vez lido a mensagem, pergunta se deseja apaga-la.

Outro exemplo que eu tive no meu sistema. Tenho uma opção onde o usuário pode imprimir o movimento mensal. Para isto o sistema dispõe em ACHOICE os meses que ele tem acumulado e que são arquivos conforme cada mês. Nesta função que rege o ACHOICE também disponibilizo a opção de deletar esses arquivos que são compostos pela nomenclatura (MES/ANO). Ja teve cliente, que me perguntou se poderia ser recuperado, porque ele deletou. Já viu... foi triste para mim dizer... que não dava mais, a não ser que recorresse ao BACKUP.

Veja Maligno, que eu não te estou pedido para satisfazer a minha necessidade apenas. Acho que apagar um arquivo da forma que o WINDOWS o faz, isto é colocando-o na lixeira. Isto é um conceito, diferente para nós que trabalhamos em DOS.

Por outro lado, fazer uma pasta como repositório, tem também seus inconvenientes. Para os usuários deleixados, a pasta em certo tempo iria ficar com arquivos e mais arquivos e demandar uma rotina para eliminá-los por data. Sei que não soa mal, mas depende para que caso e quais os motivos.

E depois de tudo, sua biblioteca está ficando muito completa e não viria mal essa nova opção.
Um clip-abraço :)Pos

MensagemEnviado: 13 Abr 2007 12:10
por Maligno
Ja teve cliente, que me perguntou se poderia ser recuperado, porque ele deletou. Já viu... foi triste para mim dizer... que não dava mais, a não ser que recorresse ao BACKUP.

Não é vergonha sua. Quem apagou foi ele. :)

Acho que apagar um arquivo da forma que o WINDOWS o faz, isto é colocando-o na lixeira. Isto é um conceito

Ah, sim. Não discordo disso. Seria um recurso a mais.

Para os usuários deleixados

O desleixo do usuário é responsabilidade dele. Sua responsabilidade seria apenas indicar um filtro de backup para excluir estes arquivos.

iria ficar com arquivos e mais arquivos e demandar uma rotina para eliminá-los por data.

Algumas poucas linhas de código, que seria executado ao iniciar o programa.

E depois de tudo, sua biblioteca está ficando muito completa e não viria mal essa nova opção.

Não descartei. Está anotado na agenda do WAPI. Só que vai demorar um pouco. Estou fazendo o WAPI residente e isso envolve multi-trheading. Isso toma mais tempo que o normal. Depois disso, na seqüência, ainda tem o bloqueio de desktop e teclas.

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

MensagemEnviado: 18 Abr 2007 13:26
por Pablo César
Sei que você anda ocupado MALIGNO. Mas teria como responder pro colega esta questão do http://www.pctoledo.com.br/forum/viewtopic.php?t=5714

Um clip-abraço :)Pos

MensagemEnviado: 18 Abr 2007 19:46
por Pablo César
Caro MALIGNO,

Recebeu a minha mensagem privada sobre a resposta que recebí sobre a questão do modo da sessão (linguagem C) ?. Verificando o conteúdo indicado, encontrei este exemplo:
http://msdn2.microsoft.com/en-us/library/ms685035.aspx
Mas não sei se irá clarear alguma coisa. Mas eu tentando entender, ocorreu-me uma idéia:

Será que verificando/obtendo os eventos do mouse, para cada sessão houvera alguma diferença entre sessão (modo TELA-CHEIA e JANELADO) ?

É apenas uma idéia e talvez pudesse ser trabalhada. Pois uma das diferenças entre os modos (TELA-CHEIA e JANELADO) no modo TELA-CHEIA, não possue MOUSE do WINDOWS. isto poderia ser uma indicação para saber em que modo estaria. O que você acha colega ?.

Um clip-abraço :)Pos

MensagemEnviado: 18 Abr 2007 21:04
por Maligno
Pablo César escreveu:Será que verificando/obtendo os eventos do mouse, para cada sessão houvera alguma diferença entre sessão (modo TELA-CHEIA e JANELADO)?

Nem digo que seja impossível. Muitas vezes um efeito colateral qualquer até pode resolver um problema. O difícil é encontrar tempo pra estudar e pesquisar uma forma de conseguir isso. :)

Não quero dar esperanças a você, mas naquele link que você me passou, há uma entre as 5 alternativas que encontrei pra detectar o modo da janela. Uma delas é até interessante. Porém, ela tem dois defeitos: funciona, mas só no XP. E segundo: nem sempre funciona no XP, pelos testes que fiz. Não sei se é bug da Microsoft, do meu Windows ou meu. :))) Mas não deu tão certo como deveria.

Aliás, também não quero desanimá-lo, mas você já parou para pensar sobre o assunto e percebeu que detectar o modo da janela é apenas parte do problema? O ideal seria detectar o modo da janela e sempre forçá-lo para um ou outro modo, de acordo com sua preferência. Detectar o modo não garante a comutação automática. O problema, aliás, nem está na comutação. Isso é bem fácil. O problema está na detecção E comutação automática. A NTVDM não possui uma mensagem específica para a troca de modos, pelo que já pude apurar. Se tivesse, o próprio WAPI talvez pudesse ter uma thread que ficasse monitorando a pilha de mensagens do Windows. Portanto, SE houver um meio eficiente de detectar o modo, você precisaria criar uma "task" em background no próprio Clipper. Isso certamente elevaria seu consumo de CPU às alturas.

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

MensagemEnviado: 18 Abr 2007 21:56
por Pablo César
Maligno escreveu:Nem digo que seja impossível.
Logo que postei e ví a demora em você responder... pensei... acho que o Maligno, algo encontrou !!!

Maligno escreveu:Muitas vezes um efeito colateral qualquer até pode resolver um problema. O difícil é encontrar tempo pra estudar e pesquisar uma forma de conseguir isso. :)
Bom isto já é um começo. E quanto o menos esperamos, vemos numa coisa simples a solução.

Maligno escreveu:... naquele link que você me passou, há uma entre as 5 alternativas que encontrei pra detectar o modo da janela. Uma delas é até interessante.
Sei que você ainda está estudando a forma mais conveniente e testando as opções. Mas se precisar que seja respondido e aproveitar para um pedido de opinião, sinta-se livre de fazé-lo diretamente para a pessoa ou até mesmo para que eu traduça e/ou envie por email.

Maligno escreveu:Porém, ela tem dois defeitos: funciona, mas só no XP. E segundo: nem sempre funciona no XP, pelos testes que fiz.
Este sempre foi um KARMA para mim, por algumas funções do API, não funcionarem em WIN98.

Maligno escreveu:...não quero desanimá-lo, mas você já parou para pensar sobre o assunto e percebeu que detectar o modo da janela é apenas parte do problema? O ideal seria detectar o modo da janela e sempre forçá-lo para um ou outro modo, de acordo com sua preferência.
Sim, seria muito importante se você pudesse reproduzir as teclas ALT-ENTER. Mas se não houver possibilidade e conseguir detectar o modo, como eu disse em mensagens anteriores, eu me conformaria com apenas dar uma mensagem pro usuário para que acionasse a telca ALT-ENTER para mudar de modo, no caso que a detecção não seja a pretendida.

Maligno escreveu:Não sei se é bug da Microsoft, do meu Windows ou meu
Se precisar que seja testado todas as vezes que você achar uma nova versão, pode contar comigo. Me mande por email e eu teste nos dois WINDOWS (98 e XP).

Maligno escreveu:Portanto, SE houver um meio eficiente de detectar o modo, você precisaria criar uma "task" em background no próprio Clipper.
Não entendí essa parte. Essa task é para que fique residente e faça alguma verificação ?.

Também outra questão que não entendí, quando você menciona em mensagem anterior:
Estou fazendo o WAPI residente e isso envolve multi-trheading.
Qual seria essa finalidade ?. Seria para tratar a questão de bloqueio do teclado para a questão do ECF ?. Será que o aplicativo para atender essa questão de "residente", não deverias separa-la do WAPI ?. Acho estranho ver o WAPI como residente, não carregaria coisas a mais na memória ?. Digo isto, porque para o caso de aplicativos residentes, sempre é apenas UM aplicativo ESPECÍFICO e não multivalentes como é o WAPI.

Tenho certeza que você irá descobrir a forma mais adequada de detectar o modo e possivelmente a reprodução de acionamento das teclas ALT ENTER.

Boa sorte colega, pena que não poderei estar muito tempo sem dormir. Pois estou com uma gripe que tira toda as minhas forças... vou descansar, mas amanhã estarei desde cedo (se DEUS permitir, é claro).

Um clip-abraço :)Pos

MensagemEnviado: 19 Abr 2007 04:18
por Maligno
Logo que postei e ví a demora em você responder... pensei... acho que o Maligno, algo encontrou !!!

Eu estava trabalhando. Aliás, só consegui acabar agora, às 4 da manhã. :(

E quanto o menos esperamos, vemos numa coisa simples a solução.

O diabo é que essas coisas simples não são fáceis de encontrar. :(

Este sempre foi um KARMA para mim, por algumas funções do API, não funcionarem em WIN98.

É como eu já disse há um bom tempo: não alimente muitas esperanças de ver esse problema resolvido da forma ideal.

seria muito importante se você pudesse reproduzir as teclas ALT-ENTER. Mas se não houver possibilidade e conseguir detectar o modo, como eu disse em mensagens anteriores, eu me conformaria com apenas dar uma mensagem pro usuário para que acionasse a telca ALT-ENTER para mudar de modo, no caso que a detecção não seja a pretendida.

Também como já disse antes: a injeção de um código de Alt+Enter no Windows não refresca nada, já que este atalho tem função comutativa. Não há utilidade nisso. Aliás, se existisse um atalho qualquer que comutasse especificamente para modo fullScreen, também não seria uma boa solução, já que isso, pra funcionar, imporia um overhead considerável no programa Clipper.

Se precisar que seja testado todas as vezes que você achar uma nova versão, pode contar comigo. Me mande por email e eu teste nos dois WINDOWS (98 e XP).

Obrigado. Mas Isso não chega a ser problema, já que eu próprio disponho de todas as versões do Windows, a exceção do Me. É só montar uma máquina virtual no VMware.

Maligno escreveu:Portanto, SE houver um meio eficiente de detectar o modo, você precisaria criar uma "task" em background no próprio Clipper.
Não entendí essa parte. Essa task é para que fique residente e faça alguma verificação ?.

Por "task" no Clipper, entenda: uma função que execute em background. Pra evitar que o usuário mude para o modo windowed você precisaria de uma função rodando em background no Clipper. Essa função, ao detectar a troca de modo, comutaria de volta para o modo fullScreen. Isso, logicamente, imporia um overhead no sistema e o consumo de CPU subiria bastante.

Também outra questão que não entendí, quando você menciona em mensagem anterior:
Estou fazendo o WAPI residente e isso envolve multi-trheading.
Qual seria essa finalidade ?. Seria para tratar a questão de bloqueio do teclado para a questão do ECF ?.

Exatamente. É o seguinte: para bloquear o teclado eu preciso instalar um hook no manipulador de eventos de teclado do Windows. Mas isso só é possível dentro da mesma tarefa. Portanto eu tenho que manter o WAPI na memória. Se ele morre depois de instalado o hook, o hook morre junto e a monitoração deixa de existir. Quando disse que isso envolve multi-threading, eu quis dizer que com o WAPI residente algumas tarefas poderão ser executadas ao mesmo tempo, com a criação threads. Com o WAPI transiente nada disso será possível. E hoje ele ainda é transiente. Mas mudá-lo para residente é algo que eu já previa desde o começo. Só não fiz antes porque a coisa tem que ser melhor planejada. Também com relação às funções de abstração e à possibilidade de dupla instância do programa Clipper.

Será que o aplicativo para atender essa questão de "residente", não deverias separa-la do WAPI ?. Acho estranho ver o WAPI como residente, não carregaria coisas a mais na memória ?.

O WAPI é um sistema atômico. Não dá pra dividir. Mas a memória consumida é uma mixaria. Nem se preocupe com isso. :)))

Digo isto, porque para o caso de aplicativos residentes, sempre é apenas UM aplicativo ESPECÍFICO e não multivalentes como é o WAPI.

Não pensei ainda na possibilidade de multiplas instâncias do WAPI. É até uma possibilidade, mas tenho quase total certeza de que o melhor é bloquear isso. Acho que a instância única seria melhor, até porque, uma vez multi-threading, cada tarefa processaria em seu próprio espaço, separadamente. O bom disso é que bloquear re-instanciamento de aplicacão Windows é bem mais fácil. :)

Pois estou com uma gripe que tira toda as minhas forças...

Estimo melhoras. :)

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

MensagemEnviado: 19 Abr 2007 09:23
por Pablo César
Fiquei acordado até pouco depois da meia noite, fico ancioso pensando em como eu poderia ajudar você. Esse link que eu tinha te passado na minha mensagem anterior, foi encontrada de dentro de aquelas 3 Títulos que eu havia te mandado por MP. Assim que é bastante extenso a documentação da MS.

Maligno escreveu:se existisse um atalho qualquer que comutasse especificamente para modo fullScreen, também não seria uma boa solução, já que isso, pra funcionar, imporia um overhead considerável no programa Clipper.
E se eu usasse o WAPI.EXE diretamente na linha de comando. No meu caso específico, com meu sistema modular, tranquilamente poderia sair do aplicativo-Clipper (mas não sair da sessão) executar o aplicativo GUI e depois executar o WAPI.EXE de dentro do arquivo .BAT que gerencia todas as chamadas do meu sistema. Será que assim não sobre-carregaria pois estaria sendo executado na linha de comando.

Maligno escreveu:Por "task" no Clipper, entenda: uma função que execute em background. Pra evitar que o usuário mude para o modo windowed você precisaria de uma função rodando em background no Clipper. Essa função, ao detectar a troca de modo, comutaria de volta para o modo fullScreen. Isso, logicamente, imporia um overhead no sistema e o consumo de CPU subiria bastante.
Puxa ! Seria genial isso !!!. Mas mesmo que você conseguisse reduzir esse consumo, eu tenho minhas dúvidas se isso iria funcionar em WIN95, WIN98. Com certeza deve-se ao novo conceito e estruturação do proprio SO.

Também outra questão que não entendí, quando você menciona em mensagem anterior:
Estou fazendo o WAPI residente e isso envolve multi-trheading.
Qual seria essa finalidade ?. Seria para tratar a questão de bloqueio do teclado para a questão do ECF ?.

Exatamente. É o seguinte: para bloquear o teclado eu preciso instalar um hook no manipulador de eventos de teclado do Windows. Mas isso só é possível dentro da mesma tarefa. Portanto eu tenho que manter o WAPI na memória. Se ele morre depois de instalado o hook, o hook morre junto e a monitoração deixa de existir.

Maligno escreveu:Quando disse que isso envolve multi-threading, eu quis dizer que com o WAPI residente algumas tarefas poderão ser executadas ao mesmo tempo, com a criação threads. Com o WAPI transiente nada disso será possível. E hoje ele ainda é transiente. Mas mudá-lo para residente é algo que eu já previa desde o começo. Só não fiz antes porque a coisa tem que ser melhor planejada. Também com relação às funções de abstração e à possibilidade de dupla instância do programa Clipper.
Isto significaria agilidade na execução de algumas funções, isto é iriam ser executadas independentes ?. Desculpe, mas ainda não entendo o quê isso iria representar ?. Ganho de velocidade, talvez ?.

Você poderia me especificar quais foram as opções que mais se adecuaram e quais seriam as dificuldades sobre aquelas informações que nos foram passadas pelo "Ancient Dragon". Porque eu gostaria de respodner pra ele e de passo arriscar um segundo retorno.

Um clip-abraço :)Pos

MensagemEnviado: 21 Abr 2007 00:30
por Maligno
E se eu usasse o WAPI.EXE diretamente na linha de comando.

Não mudaria nada.

eu tenho minhas dúvidas se isso iria funcionar em WIN95, WIN98. Com certeza deve-se ao novo conceito e estruturação do proprio SO.

Um detalhe: esse tipo de "background task" é coisa antiga no Clipper, caso não saiba. Se já conhece, me desculpe. É que tive a impressão de que não conhece.
O conceito de multi-threading, da forma como estou planejando, talvez não funcione tão bem com o Windows 98. Mas se não for possível nesta versão, o WAPI residente ainda estará disponível.

Isto significaria agilidade na execução de algumas funções, isto é iriam ser executadas independentes ?. Desculpe, mas ainda não entendo o quê isso iria representar ?. Ganho de velocidade, talvez ?.

Com multi-threading você poderia, por exemplo, imprimir, tocar música e baixar arquivos ao mesmo tempo. Ou seja, conforto e mais velocidade em algumas tarefas.

Você poderia me especificar quais foram as opções que mais se adecuaram e quais seriam as dificuldades sobre aquelas informações que nos foram passadas pelo "Ancient Dragon". Porque eu gostaria de respodner pra ele e de passo arriscar um segundo retorno.

Mas você não participa da thread do tal "Ancient Dragon". Mas em todo caso, ele dá como alternativa uma chamada ShowWindow(hWnd,SW_SHOWMAXIMIZED);, que não faz nada além de maximizar a janela DOS. Não é mudar para fullScreen, note. É maximizar.

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

MensagemEnviado: 21 Abr 2007 01:42
por Pablo César
Maligno escreveu:Mas você não participa da thread do tal "Ancient Dragon".
Será que estamos falando do mesmo caso ?. Pois já são várias a mensagens que recebí. Todas te mandei por email. Seria bom que você me confirmasse se é a mais indicada seria aquela você destacou:
Maligno escreveu:naquele link que você me passou, há uma entre as 5 alternativas que encontrei pra detectar o modo da janela. Uma delas é até interessante.
É daqui que você se referia ? ==> http://www.daniweb.com/techtalkforums/thread75750.html

Maligno escreveu:dá como alternativa uma chamada ShowWindow(hWnd,SW_SHOWMAXIMIZED);, que não faz nada além de maximizar a janela DOS. Não é mudar para fullScreen, note. É maximizar.
Disto, gostaria de fazer duas questões:

1. Isto foi extraído do link do FORUM acima indicado ?. Se não for, me diga de onde (por favor, coloque o link de onde tirou isso).

2. Esta função ShowWindow(hWnd,SW_SHOWMAXIMIZED), sabe se trabalharia em WIN98 ?. Pois se funcionar (mesmo que MAXIMIZE) a sessão que antes era como FULLSCREEN, acho que poderiamos nos conformar para aqueles casos que não funcionam na função -WINDOW2TOP do WAPI. Pelo menos quando for em WIN98, a sessão que antes estava MINIMIZADA iria "RE-ABRIR" em modo JANELADO. Ja isto seria melhor do que não dar resultado. Estamos falando da função WINDOW2TOP do WAPI em WIN98 (modo FULLSCREEN), ok ?. Sabemos que em WINXP, funciona perfeitamente. Bem até alí, não mexer, isto é, você poderia verificar se for SO WINXP pra cima restaura conforme estava, mas se for SO pra baixo, RE-ABRA a sessão SEMPRE em modo JANELADO com a implementação de ShowWindow(hWnd,SW_SHOWMAXIMIZED). Eu sou dessa opinião. Sei que soa errado, mas pelo menos a sessão WIN98 irá sempre funcionar com WIN2TOP (teoricamente).

Um clip-abraço :)Pos

MensagemEnviado: 21 Abr 2007 02:37
por Maligno
Pablo César escreveu:É daqui que você se referia ? ==> http://www.daniweb.com/techtalkforums/thread75750.html

Ah, sim. Me desculpe. É que tem outra mensagem dele e eu fiz confusão.

1. Isto foi extraído do link do FORUM acima indicado ?. Se não for, me diga de onde (por favor, coloque o link de onde tirou isso).

O link é http://www.daniweb.com/techtalkforums/thread33838.html.

Sei que soa errado, mas pelo menos a sessão WIN98 irá sempre funcionar com WIN2TOP (teoricamente).

Teoricamente. Mas muito provavelmente não. Se não me falha a memória, uma aplicação minimizada não se tornaria maximizada por esta função, uma vez que há uma limitação da própria API. Mas isso tudo depende de teste para confirmar. Infelizmente o tempo está meio escasso. :(

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

MensagemEnviado: 21 Abr 2007 09:22
por Pablo César
Maligno escreveu:Teoricamente. Mas muito provavelmente não. Se não me falha a memória, uma aplicação minimizada não se tornaria maximizada por esta função, uma vez que há uma limitação da própria API. Mas isso tudo depende de teste para confirmar. Infelizmente o tempo está meio escasso.
Entendo. Esperarei que você faça seus testes e gostaria que você me ajudasse a compor uma pergunta pra ele, ja que até agora foi ele que teve as melhores indicações. Inclusive ele indicou o mesmo que um segundo colega Howard L tinha me indicado esta leitura: Consoles foi daqui que me surgiu aquela idéia de eu te mandei por email sobre verificação da linha 00 coluna 00 (vamos assim dizer em DOS console), claro que tavez a sua leitura seja em pixels nessa posição, mas que servirá para verificar o primeiro canto se é determinado conjunto de pixels ou é parte do Desktop ou borda de janela. Inclusive nesta ultima idéia você comentou que já tinha pensado em algo similar e que irias testar-la.

Bem fico no aguardo seus testes. Agora estou entendendo melhor as razões do multi-threading (tipo de "background task") que inclusive poderão ser útil naquela função PLAYWAVE... hehe você é uma pessoa bem persistente, né ? (acredita que esta questão do PLAYWAVE eu ví no meu sonho ?) e ví outra razão mais que agora não lembro mais. Mas pouco a pouco chegamos lá...

Um clip-abraço (vê se dorme eihnn ?) :)Pos

MensagemEnviado: 21 Abr 2007 10:31
por Maligno
Pablo César escreveu:você comentou que já tinha pensado em algo similar e que irias testar-la.

Isso. A leitura do modo de vídeo vigente. Se gráfico, windowed. Se texto, fullScreen. É uma teoria a ser testada.

você é uma pessoa bem persistente, né ?

Só assim a coisa vai pra frente. :)))

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

MensagemEnviado: 08 Mai 2007 21:07
por Pablo César
Olá prezado colega Maligno, como está o projeto WAPI ?. Espero que esteja avançando cada vez mais, fortalecendo a sua biblioteca/aplicativo a fim de quebrar os paradigmas que temos com o Clipper.

Parabéns pelo seu trabalho e pelo visto seu tópico foi valorizado aqui no FORUM pelo moderadores, colocando como FIXO.

Tenho mais uma sugestão/pedido/idéia... ou pent...ação como queira chamar.... hehe. Bem ja falei em mensagens anteriores aqui neste tópico sobre esta nova idéia Maligno, que claro deixo mais uma vez evidente uma das nossas necessidades e que deva ser avaliado por você a possiblidade de incrementar a seguinte idéia:

Veja os seguinte tópicos: http://www.pctoledo.com.br/forum/viewto ... bour#24721

O acima proveniente deste outro tópico: http://www.pctoledo.com.br/forum/viewtopic.php?t=5764

Essa função que é do xHarbour, muda o tipo de fonte que será impresso (seja em estilo, como tamanho). Será que teria uma função similar em BCC ? Que possa converter uma TAG dentro de um arquivo-de-impressão e re-escrevé-la em forma de comando de impressão ?. Claro que qualquer implementação neste sentido não deva fazer parte do WAPI, pois não sei se isto se aplica a API do WINDOWS. Mas que você acha Maligno ?.

Um clip-abraço e esperamos a próxima versão do WAPI. :)Pos

MensagemEnviado: 09 Mai 2007 09:06
por Maligno
Pablo César escreveu:como está o projeto WAPI?

Infelizmente está parado. A parte das threads exige um pouco mais de tempo do que disponho atualmente. :(

Parabéns pelo seu trabalho e pelo visto seu tópico foi valorizado aqui no FORUM pelo moderadores, colocando como FIXO.

Pois é. Agradeço o Dudu por isso.

muda o tipo de fonte que será impresso (seja em estilo, como tamanho). Será que teria uma função similar em BCC?

Não. Nem poderia.

Que possa converter uma TAG dentro de um arquivo-de-impressão e re-escrevé-la em forma de comando de impressão ?. Claro que qualquer implementação neste sentido não deva fazer parte do WAPI, pois não sei se isto se aplica a API do WINDOWS. Mas que você acha Maligno ?.

Veja a coisa por um prisma diferente: qual o problema da impressão em USB? Acessar esse tipo de porta. Pelo Clipper não dá. Então fazemos uma ponte através de um programa Windows que acessa as funções da API do Windows. Até aí, fácil. Existem várias soluções pra esse problema.
Fica só um último problema: aquilo que acontece no meio do caminho, entre a geração do relatório e seu envio para o spooler. Me refiro à interpretação de certos códigos de impressão especiais (negrito, condensado, etc).
Esse problema final tanto pode ser resolvido na aplicação que encaminha o relatório para o spooler quanto na própria aplicação Clipper. Eu uso essa segunda opção. Qual a dificuldade nisso? Nenhuma. Como eu já disse antes a você, é tudo uma questão de arregaçar as mangas (tendo tempo pra isso, claro) e montar sua biblioteca de abstração desses comandos.
Eu fiz da seguinte maneira. Imprimo normalmente, inserindo algo semelhante a tags com os comandos especiais que preciso, nos trechos certos dos relatórios. Não uso @ SAY para impressão. Tenho uma função pra isso. Essa função recebe a linha a imprimir. Mas antes de iniciar a impressão seleciono qual o destino da impressão (vídeo ou impressora) e, sendo impressora, qual é. A função de impressão é então instruída a suprimir (vídeo) ou traduzir (impressora) os códigos especiais. A linha a ser impressa, salvo raras ocasiões, é enviada para um arquivo temporário. Depois de totalmente povoado, esse arquivo é direcionado ou para o vídeo ou para o spooler e, neste caso, através do WAPI.

É simples assim e funciona.

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

MensagemEnviado: 11 Mai 2007 10:15
por Pablo César
Maligno escreveu:Infelizmente está parado.
Imagem

Maligno escreveu:Não. Nem poderia.
ahamm, eu entendí, não que você ja não tenha dito... Apenas pensei que tudo em informática pode ser escrito em arquivo e pensei que esta seria uma solução. Mas o que entendí resume-se a resposta neste tópico: http://www.pctoledo.com.br/forum/viewtopic.php?t=5825

Maligno escreveu:Não uso @ SAY para impressão.
Você gera arquivo de impressão então ?.

Maligno escreveu:Tenho uma função pra isso. Essa função recebe a linha a imprimir.
Essa função, lê o seu arquivo de impressão, linha a linha ?

Maligno escreveu:Imprimo normalmente, inserindo algo semelhante a tags com os comandos especiais que preciso, nos trechos certos dos relatórios.
Essas TAGS são gravadas no arquivo de impressão, então ?.

Acho que já perguntei isto antes: você conhece o PRINTER.EXE ( Printer (DOS/WIN) ), viu que ele imprime em modo gráfico e trabalha através de um arquivo intermediário que é gerado com TAGS e o PRINTER.EXE traduz as TAGS em modo de impressão. A sua forma de imprimir é gráfica ?.

Bem aguardamos qualquer novidade do WAPI e espero que tenhas éxitos na sua emprendados desafios.

Imagem

MensagemEnviado: 12 Mai 2007 06:29
por Maligno
Pablo César escreveu:Apenas pensei que tudo em informática pode ser escrito em arquivo

Tudo o que pode ser representado em termos de bits e bytes pode ser escrito em arquivo. Mas eu entendi que você perguntou se o BCC tinha algo "nativo". Não tem. Mas pode ser feito.

Você gera arquivo de impressão então ?.

Sim, pois torna viável o trabalho de particionamento da impressão e é, aliás, a única forma confiável de exibir um preview de relatório.

Essa função, lê o seu arquivo de impressão, linha a linha ?

Não. A função a que me referi envia dados para impressão. Isso não significa que esses dados serão impressos. Pode ser configurado um destino para esses dados. Posso imprimir diretamente, como nos sistemas tradicionais ou armazenar esses dados em arquivo. O próprio arquivo poderá ser enviado para o spooler ou, depois da tradução (ou supressão das "tags"), ser enviado para o vídeo. Tenho um sub-sistema de manipulação de texto pra isso.

Essas TAGS são gravadas no arquivo de impressão, então ?.

Não. A função de impressão, que substitui os @...SAY, recebe essas "tags" de impressão normalmente. Esses dados são direcionados para um arquivo e nele serão gravados com ou sem os comandos de impressão, de acordo com o destino. Se o destino for o vídeo, todos os comandos serão eliminados. Aliás, faço o inverso com a acentuação das palavras. Se o destino for a impressora, são eliminados. Caso contrário, sendo vídeo, eles permanecem.
Agora, se o destino da impressão dos dados for a impressora, as "tags" são substituídas pelos comandos relativos à impressora escolhida. O WAPI envia o arquivo devidamente preparado (RAW) para o spooler.

A sua forma de imprimir é gráfica ?.

Não. Gráfico só em Windows (por um gerador de relatórios). Em DOS só uso texto. Até já me pediram impressão gráfica, mas eu recusei.

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

MensagemEnviado: 17 Mai 2007 10:23
por Pablo César
Caro Maligno,

Adicionando ainda mais a sua lista de pendências... hehe lá vem o Pablo...

Surgiu a idéia, a minha resposta Veja aqui de uma MP enviada pra mim e na qual menciono a abertura de uma sessão nova sessão e que poderia causar alguns inconvenientes ao fechar o aplicativo que estaria em outra sessão. Bem a idéia seria... (ora que meio radical) de utilizar uma nova função do WAPI que pudesse "fechar" a sessão com handle X (daquela sessão minimizada). Você hoje, consegue RE-EXIBIR uma sessão (com a função WINDOW2TOP), será que poderia fazer FECHAR ?. Sei que soa radical porque é necessário avaliar as consequências que traria fechar uma sessão com aplicativo sendo executado e não fechado devidamente. Pense, talvez seja útil e fica a critério de cada um. O quê você acha ?

Um clip-abraço :)Pos

MensagemEnviado: 17 Mai 2007 10:30
por Maligno
Pablo César escreveu:será que poderia fazer FECHAR ?

Sim, a princípio não haveria qualquer problema pra isso. Muito embora em alguns casos o fechamento pode depender de uma interação com o programa que estiver para ser fechado.

Sei que soa radical porque é necessário avaliar as consequências que traria fechar uma sessão com aplicativo sendo executado e não fechado devidamente.

Bom, aí já é problema de quem vai fechar o programa. Não tenho nada com isso. :)))

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

MensagemEnviado: 17 Mai 2007 10:41
por Pablo César
Então... podemos considerar que você iria disponibilizar mais essa nova opção no WAPI ?

Imagem

MensagemEnviado: 17 Mai 2007 10:51
por Maligno
Pablo César escreveu:Então... podemos considerar que você iria disponibilizar mais essa nova opção no WAPI ?

Claro. Farei assim que tiver um tempinho. :)

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

MensagemEnviado: 23 Mai 2007 14:06
por Daniel
Maligno

Valeu por esta lib muito boa mesmo gostei, me tirou de uma enrascada com impressao em usb

Valeu

MensagemEnviado: 23 Mai 2007 14:21
por Maligno
Daniel escreveu:me tirou de uma enrascada com impressao em usb

Que bom que ajudou. Fico contente por você. E vai ficar um pouco melhor, acredito, quando tiver conseguido terminar o modo residente do WAPI, que poderá ficar simplesmente monitorando um certo diretório em busca de comandos, que poderão ser executados simultâneamente.

Só uma curiosidade: você está usando as funções da biblioteca ou executando o WAPI.EXE diretamente?

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

MensagemEnviado: 23 Mai 2007 15:47
por Daniel
Ola
eu estou usando a biblioteca e compilando junto com os meus prg.
Em uma impressora lx-300 usando cabo adaptador de usb para ieee-1284 em windows xp o codigo ficou assim:

cIm:= "I" + (StrZero(Val(StrTran(Str(Seconds()), ".", "")), 7)) + ".txt"
Set Console Off
Set Device To Printer
Set Printer On
Set Printer To &cIm

...........
..........

Eject
Set Printer Off
Set Device To Screen
Set Console On
SetaImp(cIm,"Relatório de Vendas")

********************************
Function SetaImp(cImp, cTitulo)
Local aPrinter, op, x2:= 10, TelaAnt

   TelaAnt:= SaveScreen()
   aPrinter:= GetPrinters()
   If Empty(aPrinter)
      @ 24, 10 Clear
      @ 24, 13 Say "Nao ha Impressora instalada!"
      FErase(cImp)
      Return .f.
   EndIf
   @ 9, 23 Clear To (10 + LEN(aPrinter)), 51
   @ 9, 23 To (10 + LEN(aPrinter)), 51
   For x:= 1 TO LEN(aPrinter)
      xp:= 20 - Len(AllTrim(aPrinter[x,2]))
      @ x2, 25 Prompt Str(x, 2) + "-> " + aPrinter[x, 2] + Space(xp)
      x2++
   Next
   Menu To op
   RestScreen(,,,,TelaAnt)
   If LastKey() == 27
      FErase(cImp)
      Return .f.
   Else
      PrintFile(aPrinter[op, 2], cImp, cTitulo)
      FErase(cImp)
      Return .t.
   EndIf


MensagemEnviado: 23 Mai 2007 15:56
por Maligno
Uma aplicação típica das funções da biblioteca. Bem melhor que interagir diretamente com o WAPI.EXE. Mais fácil. A LIB gerencia tudo pra você. :)

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

MensagemEnviado: 15 Jun 2007 10:21
por Maligno
O que esse tópico tem a ver com o grupo "Códigos Fonte" para ser transferido do grupo de Clipper?

Reclassificação do Wapi

MensagemEnviado: 15 Jun 2007 21:47
por Pablo César
Pois é, Maligno eu gostava de ver este tópico lá na seção do Clipper mesmo, pois acredito que você estaria criando uma biblioteca para Clipper, motivado pelas limitações que o Clipper apresenta (e não outra linguagem) e o pessoal que precisa mesmo de outros recursos para o Clipper iriam passar desapercebidos aqui. Muitos dos colegas que se iniciam na inscrição do FORUM confundem muito a seção "código-fontes" com questões que deveriam ser feitas lá na seção Clipper.

Mesmo que o colega Maligno não tenha apresentado outras contribuições ao WAPI não quer dizer que o projeto esteja parado ou não estivesse atendendo as diversas demandas que ora foram solicitadas pelas carências da linguagem Clipper e ora também porque o projeto não considera-se como "finalizado" e precisa muito da participação e debate dos colegas que enfrentam lá na seção Clipper.

Na minha opinião deveria ser re-avaliado esta situação. Queremos muito que o projeto WAPI enriqueça-se com novos recursos que o nobre colega Maligno nos está oferecendo e que seja motivado pelos colegas que solicitam e expõem suas limitações com o Clipper.

Sabemos que o WAPI.EXE também poderia ser funcional para outras linguagens em DOS mas basicamente a criação da LIB é exclusiva para o Clipper. Não estou querendo menos prezar nem descriminar nenhuma outra linguagem, mas sinto-me muito a vontade de saber que o Clipper traz muita motivação, até mesmo a criação deste conceituado FORUM.

MensagemEnviado: 20 Jun 2007 01:15
por Maligno
Ao passo que existem no grupo de Clipper tópicos que servem apenas e tão somente para distribuir códigos fontes. E outros tópicos que só tratam de XHarbour. Mas permanecem no grupo de Clipper. Se é pra reclassificar mensagens, até entendo. Mas que seja feito do jeito CERTO.

MensagemEnviado: 24 Jun 2007 13:53
por Dudu_XBase
A Postagem foi movida para minimizar a quantidade de tópicos FIXOS na seção clipper.
A postagem em si foi colocado como fixa anteriormente para ser mais evidenciada e dar reconhecimento a colaboração do Maligno.
As classificações das mensagens serão reavaliadas.
Desculpe se causei algum transtorno estarei vendo junto com os demais moderadores outras decisões que serão tomadas, avaliando sugestões dos demais amigos do Fórum.

MensagemEnviado: 24 Jun 2007 17:39
por Maligno
Dudu_XBase escreveu:A Postagem foi movida para minimizar a quantidade de tópicos FIXOS na seção clipper.

Isso constitui algum problema para o grupo? Não acho que haja uma quantidade exagerada. De qualquer forma, nunca pedi que esse tópico se tornasse fixo. Nem vejo necessidade nisso.

A postagem em si foi colocado como fixa anteriormente para ser mais evidenciada e dar reconhecimento a colaboração do Maligno.

Agradeço sua preocupação nesse sentido, mas realmente não vejo necessidade. É um tópico como outro qualquer, sem merecimento a mais sobre qualquer outro tópico.

As classificações das mensagens serão reavaliadas.
Desculpe se causei algum transtorno estarei vendo junto com os demais moderadores outras decisões que serão tomadas, avaliando sugestões dos demais amigos do Fórum.

Transtorno nenhum, mas causou sim estranheza (a mim, pelo menos) pelo critério na reclassificação. Ficaremos no aguardo. Só quero frisar que esse assunto de reclassificação não é da minha alçada, não me diz respeito e não me faz diferença. Portanto, o que vocês decidirem, por mim será aceito passivamente. Garanto que não tocarei mais nesse assunto. Já dei minha opinião a respeito. Obrigado.

MensagemEnviado: 29 Jun 2007 15:48
por Dudu_XBase
Maligno Boa Tarde.
Os tópicos que forem movidos agora serão deixados um post fantasma na seção anterior ou onde ele se originou.

MensagemEnviado: 29 Jun 2007 18:23
por Pablo César
Desculpem Dudu e Maligno, por me intrometer... mas isso de criar duplicidade de mensagem, você não acha Sr. Moderador que isto iria causar alguns transtornos ?. Pois pelo que me parece, se alterar, incluir o deletar algo de um dos tópicos o outro fica sem modificações...

Sei que não é da minha conta, mas esse procedimento de "copiar" o tópico" pra lá e pra cá... não estaria inchando cada vez mais a base de dados do FORUM ?

Sinceramente, não gostei. Essa é a minha opinião. Em vez de enxugar estamos duplicando. Pois disseram que iriam re-classificar mensagens e ver o que os amigos do Forum tem pra dizer... mas isto !

MensagemEnviado: 30 Jun 2007 01:01
por Maligno
Dudu_XBase escreveu:Os tópicos que forem movidos agora serão deixados um post fantasma na seção anterior ou onde ele se originou.

Sinceramente, não entendi. Não percebi qualquer mudança, a não ser uma mensagem de solicitação de emprego no grupo de Clipper. Aquilo acho que "incha" o grupo desnecessariamente. Se isso for o tal de post "fantasma", acho ficou pior do que estava. Bastaria mover o tópico.

Veja, eu disse que não reclamaria mais sobre isso. E não vou reclamar. Vou apenas fazer uma simples pergunta: porque simplesmente não movem as mensagens aos seus devidos lugares? Não seria mais fácil? O tópico sobre o WAPI, para citar um exemplo, não é "código fonte". É LIB para Clipper, cujos fontes, apesar de liberados, não foram publicados aqui. Logo, no meu entendimento, deveria estar no grupo de Clipper, não de códigos fontes de Clipper. É simples.

Inclusive, quando tiver que dar continuidade a este tópico, com mensagens de cunho técnico, se ele ainda estiver no "código fonte", vou abrir novo tópico no grupo de Clipper, pois é lá que eu acho que ele deve ficar.

MensagemEnviado: 06 Jul 2007 18:49
por Maligno
Dudu_XBase escreveu:Os tópicos que forem movidos agora serão deixados um post fantasma na seção anterior ou onde ele se originou.

Isso de nada adianta, Dudu. Acabei de postar na seção de Clipper, mas o tópico não subiu. Ficou no mesmo lugar. O tópico fantasma não fez diferença alguma.
Sinceramente, não seria mais simples apenas voltar o tópico à seção de Clipper? Poderia me fazer esse favor? Não é necessário "fixá-lo".

MensagemEnviado: 06 Jul 2007 18:51
por Maligno
Estou quase podendo voltar a desenvolver a biblioteca. Por isso, apenas para lembrar os ítens que ainda estão pendentes, (+/-) na ordem de prioridade:
  1. Inclusão do modo residente, a fim de executar simultâneamente diversas tarefas;
  2. Cancelamento de jobs de impressão do spooler;
  3. Fechamento de uma aplicação pelo seu handle;
  4. Funções de FTP: list, delete, upload, download, etc.

Alguma coisa a mais?

MensagemEnviado: 06 Jul 2007 23:31
por Pablo César
Maligno escreveu:Acabei de postar na seção de Clipper, mas o tópico não subiu. Ficou no mesmo lugar. O tópico fantasma não fez diferença alguma.
Pois foi justamente por causa disso, que eu alertei na minha mensagem:
Pois pelo que me parece, se alterar, incluir o deletar algo de um dos tópicos o outro fica sem modificações...
Fora também quando é procurado algo sobre o WAPI não é encontrado nada (pelo "Busca" do menú do forum)na seção "CA-Clipper". Tudo isto, está trazendo mais confusão ainda. Srs. moderadores/Sr. administrador, teria como reverter esta situação o mais breve possível ?. De voltar ao que estava, na seção Clipper ?.

Maligno escreveu:... apenas para lembrar os ítens que ainda estão pendentes, (+/-) na ordem de prioridade:

1. Inclusão do modo residente, a fim de executar simultâneamente diversas tarefas;
2. Cancelamento de jobs de impressão do spooler;
3. Fechamento de uma aplicação pelo seu handle;
4. Funções de FTP: list, delete, upload, download, etc.


Estive recompilando as pendências (ora confirmadas pelo Maligno) e ficaram a seguintes a serem mencionadas:

5. Procedimento para ler status da sessão. (modo Janelado/Tela-cheia)
6. Possibilidade de deletar arquivos e enviar para lixeira do Windows.
7. Mostra a versão do WAPI, executando sem parâmetro algum.
8. Bloqueio total ou parcial do teclado.
9. Deixar de utilizar o PLAYWAVE em modo sincrono, para que os sons pudessem ser interrompidos.
10. Testar teoria: Leitura da tela na linha 00 coluna 00 (ou em pixels) para obter o modo em que a sessão pudesse estar. Se texto, é TELA-CHEIA se é gráfico, é JANELADO. Você falou que iria fazer testes quando tiver algum tempinho...

Não ví outra pendência que precise ser mencionada. Isto sem falar que o WIN2TOP em WIN98 não funciona adequadamente.

MensagemEnviado: 07 Jul 2007 04:15
por Maligno
Pablo César escreveu:5. Procedimento para ler status da sessão. (modo Janelado/Tela-cheia)

Isso, sinceramente, já nem penso mais. Embora não tenha oficialmente desistido, vai ficar por último, pois ainda vai consumir muito tempo. Fica como adendo, pro fim.

7. Mostra a versão do WAPI, executando sem parâmetro algum.

Essa opção já existe desde a última liberação. :)

8. Bloqueio total ou parcial do teclado.

Essa realmente eu esqueci. Vai ser uma das minhas favoritas. :)

9. Deixar de utilizar o PLAYWAVE em modo sincrono, para que os sons pudessem ser interrompidos.

Não lembro disse ter sido comentado antes. Mas o bloqueio de sons é algo bem útil. Mas foi bom tocar nesse assunto, pois eu esqueci de comentar a idéia que tive: implementar a execução de lotes de sons. Só vou levar isso adiante porque é algo muito simples. Tive essa idéia após ver o programa "São Tomé" do colega Toya. Se aquilo tivesse de ser feito em Clipper, não seria possível. Com o WAPI atual até poderia ser, mas ainda não ficaria bom. Seria necessária uma execução em seqüência contínua. Baixe o programa demo e veja como a "fala" ficou bem feita. Mas isso, apesar de muito simples de fazer, ficará com prioridade baixa.

Remontando a lista então:
  1. Inclusão do modo residente, a fim de executar simultâneamente diversas tarefas;
  2. Bloqueio do teclado em nível global
  3. Cancelamento de jobs de impressão do spooler;
  4. Fechamento de uma aplicação pelo seu handle;
  5. Cancelamento de execução de WAVEs;
  6. Execução de sons em lote, no modo síncrono;
  7. Funções de FTP: list, delete, upload, download, etc. Deixei este ítem por último por ser mais trabalhoso.


E o adendo: tentar fazer a porcaria do Windows98 confessar qual é o estado atual da janela DOS. Mesmo que seja sob tortura. :)))

MensagemEnviado: 07 Jul 2007 08:44
por Pablo César
Caro Maligno,

Eu não estou seguro se você concordou com a incrementação de mais este recurso quando:
Maligno escreveu:
Veja Maligno, que eu não te estou pedido para satisfazer a minha necessidade apenas. Acho que apagar um arquivo da forma que o WINDOWS o faz, isto é colocando-o na lixeira. Isto é um conceito, diferente para nós que trabalhamos em DOS.
Ah, sim. Não discordo disso. Seria um recurso a mais.
Mas tinha me parecido que você faria algo pra isso.

Maligno escreveu:
7. Mostra a versão do WAPI, executando sem parâmetro algum.
Essa opção já existe desde a última liberação.
Lembro você ter mencionado isso, mas o engraçado foi que eu baixei do seu post e comparando as datas do executáveis é a mesma, mas agora baixei novamente pela 15º e realmente vejo que tem diferença. Agora tem a versão sim.

Maligno escreveu:
9. Deixar de utilizar o PLAYWAVE em modo sincrono, para que os sons pudessem ser interrompidos.

Não lembro disse ter sido comentado antes. Mas o bloqueio de sons é algo bem útil.
Lembro que você mencionou que não estava conseguindo funcionar em background porque utiliza-se do modo SINCRONO o que não permitiria interromper os sons. E se você conseguir, ótimo !.

Maligno escreveu:Tive essa idéia após ver o programa "São Tomé" do colega Toya.
Eu ví seu post mencionando o "Terminal de consulta com voz" que alias está muito bem feito e inclusive é possível interromper o som. E fico animado saber que irias incorporar mais esse recurso ao WAPI.

Maligno escreveu:foi bom tocar nesse assunto, pois eu esqueci de comentar a idéia que tive: implementar a execução de lotes de sons.
Então podemos considerar esta opção juntamente com a opção 5 que você menciona na sua ultima mensagem ?

Maligno escreveu:E o adendo: tentar fazer a porcaria do Windows98 confessar qual é o estado atual da janela DOS. Mesmo que seja sob tortura. :)))
kakaka Imagem Sei este WIN98 é o nosso KARMA. Pois eu tenho muitos clientes ainda com WIN98 e até mesmo lembro que ja teve colegas perguntando se você poderia fazer algo para acionar a tecla WINKEY e/ou ALT_ENTER. Mas claro esta ultima opção, seria para alternar o modo, mas sem saber o STATUS fica inviável. Sorry my friend !

MensagemEnviado: 07 Jul 2007 11:56
por Maligno
Antes de tudo, quero agradecer o Dudu por mover o tópico para seu lugar de origem.

Pablo César escreveu:apagar um arquivo da forma que o WINDOWS o faz, isto é colocando-o na lixeira.

Não discordo. Coloco na lista. :)

Lembro que você mencionou que não estava conseguindo funcionar em background porque utiliza-se do modo SINCRONO o que não permitiria interromper os sons. E se você conseguir, ótimo !

Na verdade, o problema todo está no modo transiente do WAPI. Enquanto ele não morrer, ele não volta. Para tarefas que exigem mais tempo, acaba causando um desconforto no programa Clipper. Daí nasceu a idéia do WAPI residente.

Então podemos considerar esta opção juntamente com a opção 5 que você menciona na sua ultima mensagem ?

Já está lá. É o ítem 6.

lembro que ja teve colegas perguntando se você poderia fazer algo para acionar a tecla WINKEY e/ou ALT_ENTER. Mas claro esta ultima opção, seria para alternar o modo, mas sem saber o STATUS fica inviável. Sorry my friend !

Pois é. No caso das demais teclas, não vejo muita necessidade.

A lista que tenho agora:
  1. Execução do WAPI no modo residente;
  2. Bloqueio do teclado em nível global;
  3. Cancelamento de jobs de impressão do spooler;
  4. Fechamento de uma aplicação pelo seu handle;
  5. Cancelamento de execução de WAVs;
  6. Execução de sons em lote;
  7. Remoção de arquivo pra lixeira do Windows;
  8. Funções de FTP: list, delete, upload, download, etc;
  9. Acompanhamento do progresso de downloads e uploads.

O último ítem ainda depende de alguns testes pra confirmar se a idéia é exeqüível ou não. Se for, será implementada.

MensagemEnviado: 07 Jul 2007 19:12
por Maligno
Detectei um erro no WAPI.EXE que bloqueava a execução das tarefas. Já subi uma correção.
Aproveito pra relembrar o link: http://buzinello.com/download/wapi.zip

MensagemEnviado: 07 Jul 2007 19:49
por Pablo César
Eu também agradeço muito por terem reconsiderado. Gosto muito deste pessoal que valorizam a nossa opinião e põem ordem na casa. Valeu DUDU !.

Maligno escreveu:
apagar um arquivo da forma que o WINDOWS o faz, isto é colocando-o na lixeira.
Não discordo. Coloco na lista. :)
Jóia !

Maligno escreveu:
lembro que ja teve colegas perguntando se você poderia fazer algo para acionar a tecla WINKEY e/ou ALT_ENTER.
Pois é. No caso das demais teclas, não vejo muita necessidade.
Eu particularmente iria utilizar (caso tivesse esse recurso no WAPI) para ativar as teclas combinadas ALT_ENTER. Eu iria utilizar mesmo assim, não sabendo o status da sessão mas para tão somente nos casos de WIN98. Que tenho certeza que 99% dos meus clientes ((em WIN98) utilizam meu sistema em sessão em modo TELA-CHEIA. Mas este seria um risco meu, mesmo. Aposto a utilidade na grande massa. Então se puder incluir esta opção (sem encargos de consciência, hehe), eu agradeço.

Maligno escreveu:O último ítem ainda depende de alguns testes pra confirmar se a idéia é exeqüível ou não. Se for, será implementada.
Maligno, baixei esta ultima correção ao WAPI, mas percebí que a versão continua a mesma. Só para diferenciar, não daria para mudar ao menos o número do release ou digamos que fique a versão 1.16 (porque na minha contagem esta é a 16ª versão). Sei que você só corrigiu, mas é bom diferenciar o número, pois então iremos tomar conhecimento se a versão está com BUG ou não. Alias, eu ainda não percebí qual era mesmo o BUG.

MensagemEnviado: 07 Jul 2007 20:05
por Maligno
Pablo César escreveu:Aposto a utilidade na grande massa. Então se puder incluir esta opção (sem encargos de consciência, hehe), eu agradeço.

Ok. Coloco, mas no fim da lista. :)

digamos que fique a versão 1.16 (porque na minha contagem esta é a 16ª versão). Sei que você só corrigiu, mas é bom diferenciar o número

Pois eu me esqueci disso. Tudo bem. Mas se ninguém reclamou ainda ou é porque usam uma versão mais antiga que aquela ou nem usam. Portanto, não fará muita diferença. De qualquer forma, vou passar a incrementar o release a partir da próxima atualização. Por enquanto fica como está.

MensagemEnviado: 12 Jul 2007 19:31
por Maligno
Vou modificar um pouco a ordem da lista que eu editei. Não quero "trabalhar" neste sábado. Então vou "trabalhar" em alguma coisa (leve) da WAPI.

MensagemEnviado: 13 Jul 2007 08:58
por Pablo César
Maligno escreveu:Vou modificar um pouco a ordem da lista ... "trabalhar" em alguma coisa (leve) da WAPI.
Ótima decisão !. Aliás, eu estive várias vezes pensando em mencionar isso pra você, mas como você uma vez disse: "o timoneiro é o autor do programa". Então colega, pra mim não precisa pôr número nos itens pendentes. O importante que sejam realizados, pois a ordem dos tratores não alteram o viaduto...

MensagemEnviado: 14 Jul 2007 05:27
por Maligno
pra mim não precisa pôr número nos itens pendentes. O importante que sejam realizados, pois a ordem dos tratores não alteram o viaduto...

Pra falar a verdade, aquela era a única forma que eu conhecia de usar o comando LIST do BBCode. Encontrei um help dele e agora já aprendi os demais comandos. :)))

MensagemEnviado: 19 Jul 2007 07:42
por Pablo César
Maligno escreveu:Não entendo por quê você utiliza RunWAPICmd() diretamente, se existem as funções da biblioteca que fazem todo o trabalho por você de forma mais fácil e segura. Ou existe algum problema com essas funções ?
Maligno, você me fez este questionamento no outro tópico na qual eu o considerei apropriado, porém tenho uma pergunta a fazer:

Com a opção de execução RunWAPICmd() eu posso aninhar comandos utilizando-se apenas uma vez o recurso do RUN (ou SWPRUNCMD que é utilizado pelo WAPI). Embora por questão prática e "segura" teria como executar as funções em modo aninhado ?. Pois sendo executada uma a uma, iria também se executado (internamente) o RUN tantas vezes a função for chamada por separado.

Como ficaria nesses casos ?

MensagemEnviado: 19 Jul 2007 09:37
por Pablo César
Maligno, vendo aquele post sobre imagens e bibliotecas... me occorreu uma idéia. O uso da API como plug-in de SVG (Scalable Vectorial Graphics ou gráficos vectoriais escaláveis) poderia ser reproduzido algo (seja WAPI ou outra LIB) mesmo que possa ser exibido uma imagem em outra sessão (abrindo outra janela e desta em modo gráfico), haveria possibilidade de ser feita para atender a demanda em Clipper ?.

Puxa... seria tão bão chamar uma função (que seja digamos da WAPI) de dentro de uma aplicação Clipper, para ser exibido uma foto... por exemplo...

MensagemEnviado: 19 Jul 2007 11:22
por Maligno
Pablo César escreveu:Com a opção de execução RunWAPICmd() eu posso aninhar comandos utilizando-se apenas uma vez o recurso do RUN (ou SWPRUNCMD que é utilizado pelo WAPI).

Isso é verdade. Ao "juntar" comandos, você pode invocar o interpretador de comandos do DOS uma vez só. Mas em quantas situações você precisa fazer isso? Normalmente só se invoca um comando por vez, quando necessário. Pensei em fazer comandos em lote (não é aninhamento). Assim, você apensas precisaria "descarregar" o WAPI no final. Mas daí surgiu a idéia do WAPI residente, que não precisará mais do interpretador de comandos, já que ele vai se comunicar com o programa através de arquivos.

Embora por questão prática e "segura" teria como executar as funções em modo aninhado ?.

Sim, claro. Como eu disse, pensei nisso. Mas daí veio a idéia do WAPI residente. Se bem que, com comandos em lote, ficaria muito mais difícil tratar os retornos. Seria realmente um problema.

Pois sendo executada uma a uma, iria também se executado (internamente) o RUN tantas vezes a função for chamada por separado.

Como eu disse: não vejo tanta necessidade de executar vários comandos em lote.

MensagemEnviado: 19 Jul 2007 11:26
por Maligno
Pablo César escreveu:Maligno, vendo aquele post sobre imagens e bibliotecas... me occorreu uma idéia. O uso da API como plug-in de SVG (Scalable Vectorial Graphics ou gráficos vectoriais escaláveis) poderia ser reproduzido algo (seja WAPI ou outra LIB) mesmo que possa ser exibido uma imagem em outra sessão (abrindo outra janela e desta em modo gráfico), haveria possibilidade de ser feita para atender a demanda em Clipper ?.

Que SVG? Pela execução de uma função em outro programa? Ou que o próprio WAPI fizesse isso?

Puxa... seria tão bão chamar uma função (que seja digamos da WAPI) de dentro de uma aplicação Clipper, para ser exibido uma foto... por exemplo...

Desculpe, mas vejo pouca utilidade prática pra isso. Não consigo ver vantagem nisso. Desagregar o programa,... O próprio programa é que deveria fazer isso. E já existem bibliotecas que permitem isso. No que pese o fato de algumas serem meio "problemáticas" com a comutação para modo gráfico.
Sinceramente, acho que DOS não foi feito pra isso. Em todos casos que vi de programas DOS gráficos, há sempre algum "probleminha" ou "problemão", em decorrência do modo gráfico. Particularmente, gráfico é coisa com a qual trabalho apenas no Windows. DOS pra mim é texto.

MensagemEnviado: 19 Jul 2007 11:59
por Stanis Luksys
Maligno escreveu:Em todos casos que vi de programas DOS gráficos, há sempre algum "probleminha" ou "problemão", em decorrência do modo gráfico. Particularmente, gráfico é coisa com a qual trabalho apenas no Windows. DOS pra mim é texto.


hahaha :))

E isso não há quem discorde!

MensagemEnviado: 19 Jul 2007 12:04
por Pablo César
Maligno escreveu:Que SVG?
Lembro uma aplicativo feito em C que utilizou esse recurso não lembro o nome e não estou achando, a aparência de exibição era boa e era por vetorição.

Maligno escreveu:existem bibliotecas que permitem isso. No que pese o fato de algumas serem meio "problemáticas" com a comutação para modo gráfico.
É isso é, por isso hoje prefiro chamar um aplicativo que na linha de comando aceite o parâmetro (no caso nome da foto) e exiba. Mas isto requer uma instalação de um browser para exibir em modo gráfico.

Maligno escreveu:Sinceramente, acho que DOS não foi feito pra isso.
Com certeza que não. Mas eu não me referia fazer um aplicativo para DOS e sim ser chamar o browser como função, isto é convertido pelo seu aplicativo BIN2HEXA.

MensagemEnviado: 19 Jul 2007 12:07
por Maligno
Pablo César escreveu:
Maligno escreveu:Sinceramente, acho que DOS não foi feito pra isso.
Com certeza que não. Mas eu não me referia fazer um aplicativo para DOS e sim ser chamar o browser como função, isto é convertido pelo seu aplicativo BIN2HEXA.

Bom, até pode ser. E neste caso, nada tem a ver com o WAPI em si. Este prorgrama Bin2Hexa é base para fazer o embutimento de recursos no Clipper. Mas, limitado a 64KB. Se você conseguir encontrar esse programa feito em C, ele ficará limitado a esse espaço. Se não tiver sido feito pelo BCC, é capaz que dê. :)))

Conselho de amigo: se você precisa de gráficos, migre pra Windows. Uma ferramenta Windows não só resolve esse problema, como também muitos outros, que são vistos apenas no DOS. Você não vai conseguir protelar por muito tempo. Encare a realidade: o Clipper já está quase que totalmente obsoleto.

MensagemEnviado: 19 Jul 2007 12:13
por Pablo César
Maligno escreveu:neste caso, nada tem a ver com o WAPI em si.
Teria a ver caso você considerasse fazer no WAPI. Por isso mencionei:
(seja WAPI ou outra LIB)


Maligno escreveu:Se você conseguir encontrar esse programa feito em C, ele ficará limitado a esse espaço. Se não tiver sido feito pelo BCC, é capaz que dê.
Procurei no meu PC, mas não achei. Procurarei nos meus CDs... mas já viu quanto custa procura CD por CD... Mas quando achar enviarei pra você pra dar uma olhadinha.

MensagemEnviado: 19 Jul 2007 12:14
por Maligno
Esse tipo de trabalho está bem fora do escopo do que o programa se presta a fazer. Lembre-se: WAPI significa Windows API. Uma ponte para as funções da API do Windows.

Não lembra o nome do programa em C?

MensagemEnviado: 19 Jul 2007 12:17
por Pablo César
Não. Não lembro. Mas... etahhh teclado rápido o teu... parece escrivão de delegacia... kakaka não consigo piscar o olho... você ja responde... kakakaka (me ensina a tua técnica, e isso que nunca vejo você logado) hihihihi

MensagemEnviado: 19 Jul 2007 12:18
por Maligno
Oito anos como auxiliar de escritório datilografando como escrivão de polícia. É prática. :)))

MensagemEnviado: 21 Jul 2007 13:46
por Maligno
<APAGADO>
Lista de parâmetros do utilitário WAPI.EXE.

MensagemEnviado: 21 Jul 2007 20:12
por Pablo César
Maligno, como você mesmo disse ainda é a mesma versão do que a ultima disponibilizada em 07 Jul 2007 19:12h ?

Eu agora estou visualizando sua ultima mensagem em WIN98 (resolução 1024x768 pixels) e estou tendo dificuldades com ler a sua letrinha azul... será que poderias aumentá-la ? (já viu a idade não vem sozinha... hihihi)

MensagemEnviado: 21 Jul 2007 20:52
por Maligno
Pablo César escreveu:Maligno, como você mesmo disse ainda é a mesma versão do que a ultima disponibilizada em 07 Jul 2007 19:12h ?

Sim, esta é a ultima. Versão 1.00. Porque?

Eu agora estou visualizando sua ultima mensagem em WIN98 (resolução 1024x768 pixels) e estou tendo dificuldades com ler a sua letrinha azul... será que poderias aumentá-la ? (já viu a idade não vem sozinha... hihihi)

Poxa! Usei size=8 e achei grande. :))) Ajustei pra 10. Melhorou?

MensagemEnviado: 21 Jul 2007 20:53
por sygecom
Melhoro as letra das Lista......apesar que isso jah vem junto com a Wapi...é soh baixar e ver.

Abraços
Leonardo Machado

MensagemEnviado: 21 Jul 2007 20:57
por Maligno
sygecom escreveu:Melhoro as letra das Lista......apesar que isso jah vem junto com a Wapi...é soh baixar e ver.

Não entendi. O que o download da WAPI tem a ver com as letras da lista?

MensagemEnviado: 21 Jul 2007 21:02
por sygecom
Maligno escreveu:
sygecom escreveu:Melhoro as letra das Lista......apesar que isso jah vem junto com a Wapi...é soh baixar e ver.

Não entendi. O que o download da WAPI tem a ver com as letras da lista?

Eu me refiro a Lista e não ao tamanho da fonte das letras. Mas deixa pra lah.

Abraços
Leonardo Machado

MensagemEnviado: 21 Jul 2007 21:10
por Maligno
Ah, sim. Agora eu entendi. Mas eu repliquei a lista com um resumo justamente pra facilitar, conforme eu havia comentado. Além de ressaltar a minha TODO list.

MensagemEnviado: 22 Jul 2007 13:26
por Maligno
Pronta a função de apagamento de arquivos para a lixeira. Mas não penso em fazer uma função de restauração. Se for necessário restaurar, acho mais seguro que isso seja feito pelo Windows Explorer.

MensagemEnviado: 23 Jul 2007 07:10
por Pablo César
Maligno escreveu:
Pablo César escreveu:Maligno, como você mesmo disse ainda é a mesma versão do que a ultima disponibilizada em 07 Jul 2007 19:12h ?
Sim, esta é a ultima. Versão 1.00. Porque ?.
Eu estava em dúvida, porque nas ultimas atualizações o número do release não tinha sido modificado.

Poxa! Usei size=8 e achei grande. :))) Ajustei pra 10. Melhorou?
Ficou boa, agora sim dá pra ler normalmente.

Pronta a função de apagamento de arquivos para a lixeira.
Que bom ! Olhei no seu site para saber se ja estava disponível para download. Foi difícil de fazer esta nova função ?.

Se for necessário restaurar, acho mais seguro que isso seja feito pelo Windows Explorer.
Pelo Windows Explorer ou pela lixeira do próprio Windows. Acho que essa outra função não é primordial.

OK, Ficamos no aguardo do seu novo release...

MensagemEnviado: 23 Jul 2007 08:24
por Maligno
Pablo César escreveu:Eu estava em dúvida, porque nas ultimas atualizações o número do release não tinha sido modificado.

Não foi modificado porque nenhuma nova função foi adicionada.

Foi difícil de fazer esta nova função ?.

Não. Mas a documentação da Microsoft me indiziu a erro. Até achar... :[

OK, Ficamos no aguardo do seu novo release...

À tarde eu subo. Ainda tenho que atualizar o README. :)

MensagemEnviado: 23 Jul 2007 10:39
por Pablo César
Maligno,

Estive pensando... há vezes que é preciso mandar uma mensagem a X ou Todas as estações de uma rede. Isto poderia ser feito algo como para que seja lido de um arquivo (gravado em determinado diretorio) e exibido nas estações através do WAPI utilizando-se do modo residente ? Esta questão de exibição, pode ser feito um aplicativo GUI que mostre o conteúdo. Eu já ví um desses aplicativo baixando-o da internet. Mas também para quem trabalha em GUI não deve ser difícil fazer uma aplicativo JANELA for Windows.

MensagemEnviado: 23 Jul 2007 10:48
por Maligno
Sim, é bem possível. Um sistema de broadcasting de mensagens. Basta um programa GUI, residente no tray, "escutando" certo diretório em busca de certo arquivo texto, que conteria as informações de exibição. Há de se amadurecer essa idéia. Aliás, boa idéia. Gostei. Parabéns.

MensagemEnviado: 23 Jul 2007 10:56
por Pablo César
Maligno escreveu:Sim, é bem possível... boa idéia. Gostei. Parabéns.
Obrigado. Eu também fico feliz saber que você pode realizar esta façanha. Alias, para amadurecer ainda mais a idéia, eu sempre estive interessado fazer uma agenda para meu sistema (assim como o colega Stanis Luksys e outros também). Claro que o agendador de tarefas do Windows era o indicado, ora seja pelas variantes ou até pela intervenção que faz nos aplicativos em execução. Então, como você disse poderiamos através do "residente no tray (escutando)" para verificar determinado tipo de arquivo (.BAT ou qualquer outra extensão), ler o conteúdo desse arquivo para executar o comando escrito nesse arquivo. Só não sei se o Wapi poderia executar abrindo em nova sessão...

MensagemEnviado: 23 Jul 2007 11:10
por Maligno
Pablo César escreveu:Então, como você disse poderiamos através do "residente no tray (escutando)" para verificar determinado tipo de arquivo (.BAT ou qualquer outra extensão), ler o conteúdo desse arquivo para executar o comando escrito nesse arquivo. Só não sei se o Wapi poderia executar abrindo em nova sessão...

Eu estava pensando, na verdade, em um arquivo texto com comandos proprietários, inteligíveis para este programa residente. Mas coisa simples. Nada muito sofisticado. Seria, digamos, um batch diferente.

MensagemEnviado: 23 Jul 2007 11:14
por Maligno
Acabo de subir o WAPI v1.01 para o meu site. Ele agora contém mais alguns arquivos: na pasta WAPI\LIB aparecem agora os arquivos TODO.TXT e um HISTO.TXT. O primeiro para marcar o planejamento de novas implementações e o segundo, um histórico do que foi feito desde a versão 1.00.

Além disso, claro, a função de biblioteca Del2RecBin(), para apagamento de arquivos com remoção para a lixeira do Windows. Isso me lembra de que esqueci de dizer no README.TXT, na descrição da função, que a remoção para a lixeira depende da configuração da própria. Se não configurada para aceitar um drive, logicamente o arquivo não irá para lá. :)

Link direto: http://pub.buzinello.com/clipper/libs/wapi_v1.01.zip

MensagemEnviado: 23 Jul 2007 11:17
por Pablo César
Pois é, serviria tanto para o sistema de mensagens broadcasting como também para ativar mensagens provenientes de uma agenda (mesmo feito em Clipper). O problema para as mensagens agendadas seria estabelecer um parâmetro de data inicial, hora, frequência de msg (assim como o agendador de tarefas possue). Isso seria o ideal.

MensagemEnviado: 23 Jul 2007 11:20
por Maligno
Pablo César escreveu:O problema para as mensagens agendadas seria estabelecer um parâmetro de data inicial, hora, frequência de msg (assim como o agendador de tarefas possue). Isso seria o ideal.

Não vejo porque isso seria um problema. Uma vez que o programa está residente no tray, ele poderia acompanhar o tempo e disparar qualquer evento previamente configurado.

MensagemEnviado: 23 Jul 2007 11:23
por Pablo César
Ôbaaaa ! Então podemos considerar esta opção para ser adicionada na sua PL (pendings list) ?

MensagemEnviado: 23 Jul 2007 11:54
por Maligno
TODO list é o termo mais comumente usado. Sim. Vou acrescentar na lista.

MensagemEnviado: 23 Jul 2007 12:34
por Pablo César
Maligno escreveu:TODO list é o termo mais comumente usado
Ahhh é ? Não sabia, por isso não tinha entendido anteriormente e quase indiquei uma correção no idioma.

Ja baixei e testei seu WAPI, Maligno e funciona beleza !. Testado em WIN98 e realizado com WAPI.EXE na linha de comando, mas prometo que irei compilar a WAPI.LIB e fazer testes também. Mais um na conta, valeu !

MensagemEnviado: 23 Jul 2007 12:38
por Maligno
Isso me lembra que esqueci de comentar que, ao apagar algo que já foi apagado, o Windows retorna sem erro. Bug? Não sei. Mas parece. Deveria retornar um erro de "arquivo não encontrado". Mas não é isso o que acontece.

E também esqueci de dizer aqui que a lista com vários arquivos deve ser separada por vírgulas, se executado o WAPI em linha de comando. Mas se for usar a LIB, o que eu recomendo, não será necessário se preocupar com isso. Por isso não comentei no README.

Ah, sim. Também esqueci de dizer que funciona perfeitamente no mal-amado do Windows 98. :)))

MensagemEnviado: 23 Jul 2007 14:19
por Pablo César
Maligno escreveu:Deveria retornar um erro de "arquivo não encontrado".
Não necessáriamente. Já no meu caso eu iria utilizar este novo recurso do WAPI para deletar arquivo (caso exista), isso pode ser verificado no próprio aplicativo em Clipper.

Ah, sim. Também esqueci de dizer que funciona perfeitamente no mal-amado do Windows 98. :)))
É... esse o importante, pois sempre foi o seu KHARMA e para meu ver é a versão do Windows mais estable e fácil de trabalhar...

MensagemEnviado: 23 Jul 2007 14:23
por Maligno
Pablo César escreveu:
Maligno escreveu:Deveria retornar um erro de "arquivo não encontrado".
Não necessáriamente. Já no meu caso eu iria utilizar este novo recurso do WAPI para deletar arquivo (caso exista), isso pode ser verificado no próprio aplicativo em Clipper.

Pra mim isso é erro. Se eu mando apagar algo que não existe, o Windows deveria reportar um erro. De fato isso acontece. Mas se eu tentar apagar o que já foi apagado, não há erro algum.

para meu ver é a versão do Windows mais estable e fácil de trabalhar...

Pois pra mim a melhor versão e a mais estável é o XP. Aliás, minha análise coincide com a da crítica especializada. :)

MensagemEnviado: 24 Jul 2007 09:52
por ilovewindev
Maligno,
la libreria WAPI es EXCELENTE, tengo prolbema para linkearla con Clipper 5.2, Funcky, Comix y Clipper Tools usando Blinker. Pueden publicar algun archivo .LNK que usan para linkear la libreria.

Gracias

The WAPI library is EXCELENT, I'having trouble to link it using Clipper 5.2, Funcky, Comix y Clipper Tools using Blinker. Can you post a .LNK to see how you link it.

Thanks

ILW :))

MensagemEnviado: 24 Jul 2007 09:59
por Pablo César
Hola ilovewindev (no sé tu nombre), bien venido al forum. Podrias describirnos qual es el mensaje de error que está ocurriendo ?.

Sabias que hay dos formas de ejecucion del WAPI ?. Es decir se puede utilizar el WAPI.EXE como aplicativo externo. Pero, no veo por qué daria problemas linkando con otras LIBs.

Creo tambien que no haberia necesidad de traduccion para el ingles. Cualquier cosa le doy una manito a Maligno con el idioma (no te preocupes).

Esperamos tu respuesta.

Parabéns Maligno ! Seu aplicativo agora virou internacional ! hehe

MensagemEnviado: 24 Jul 2007 10:03
por sygecom
Se alguem mais poder testar esse BUG ou sei lah como podes chamar...acontece que em modo RAW algumas impressora a WAPI não funciona...se alguem tiver impressoras Lexmark...e poder testar a WAPI seria interesante.
Abaixo um exemplo de um colega que passou pelo mesmo problema que eu:
http://www.pctoledo.com.br/forum/viewto ... 7&start=60


Agradaeço Antecipadamente a Todos
Leonardo Machado

MensagemEnviado: 24 Jul 2007 18:33
por Maligno
ilovewindev escreveu:Maligno,
The WAPI library is EXCELENT, I'having trouble to link it using Clipper 5.2, Funcky, Comix y Clipper Tools using Blinker. Can you post a .LNK to see how you link it.


Thank you, ILW. Be welcome to our group. As you may know at this moment, we have a great group of friends here. You're invited to join us. :)

I think you know the library WAPI is only a set of high level Clipper functions that simply invoke a tool called WAPI.EXE, embedded into the library. It's a Windows executable file like any other. Once you call a Clipper function, a copy of WAPI.EXE is extracted to a certain directory (configurable). Finally, the WAPI.EXE is executed with the convenient command line arguments to perform the desired action throught Windows. That's it. Just it.

So the library per se is very simple. Not only to use but to link it to your system too. There is only one requirement: CATools. Nothing more. Reading your message, I noticed you already use it.

The following example is the easiest way to compile a source file called TEST and link the library WAPI.

clipper test
blinker fi test li wapi,ct52

Nothing more than this is necessary. You related some trouble. What trouble exactly? Any error message? Can you show us your linkage script?

By the way, I have a question: how did you know about that library?

Regards,

MensagemEnviado: 24 Jul 2007 19:03
por Maligno
Pablo César escreveu:Parabéns Maligno ! Seu aplicativo agora virou internacional ! hehe

Pois é. Pra você ver. Sabe que agora que me dei conta de um detalhe? Nunca vi nada semelhante à essa biblioteca antes. Será que tem mais alguma por aí?

Aliás, falando em internacional, gostaria de saber se você, um legítimo "hermano" com domínio do espanhol, se disporia a traduzir alguns textos da WAPI. Nada pra agora, pois quero organizar melhor esses textos todos.

MensagemEnviado: 24 Jul 2007 19:25
por Eolo
Mr. Evil,
This is really cool! Congrats.

MensagemEnviado: 24 Jul 2007 19:27
por Maligno
Thanks, grandpa Eolo. :)))

MensagemEnviado: 24 Jul 2007 23:39
por Pablo César
Minha nossa ! Como estamos !. Todo mundo falando ingreis... Legal !

Maligno, tentarei traduzir a documentação que você me indicar para o español para nuestros hermanos. Nós sabemos que a tua documentação é bem extensa, mas podemos começar com o README, que você acha ?. pode contar.

MensagemEnviado: 25 Jul 2007 00:16
por Maligno
Sim, pode ser. Mas não se apofe. É melhor que eu faça essa reorganização primeiro senão o trabalho vai ser dobrado. Além do mais, tem as demais funções que estou desenvolvendo agora. Mas já fico contente que teremos uma tradução pro espanhol. Depois eu também vou tentar "arranhar" no inglês. :)
Obrigado.

MensagemEnviado: 25 Jul 2007 00:19
por Pablo César
Tudo bem, aguardarei (pois era isso que devia ter dito pra você): Só se você acabar a WAPI.... hihihi

Maligno escreveu:Depois eu também vou tentar "arranhar" no inglês.
Ok, também poderei dar uma ajudinha.

MensagemEnviado: 25 Jul 2007 00:51
por Maligno
Tudo bem, aguardarei (pois era isso que devia ter dito pra você): Só se você acabar a WAPI.... hihihi

Acho que depois que eu esvaziar a TODO pouco vai sobrar. Se bem que a sua imaginação, ao que parece, é bem fértil. :)))

MensagemEnviado: 25 Jul 2007 09:24
por ilovewindev
Yo me ofrezco a traducir al espaniol o al ingles con mucho gusto

Una pregunta al paso: alguien ha provado comunicar alguna aplicacion clipper via sockets/ipx/spx con una aplicacion windows ??? Es solo una idea que estoy investigando

ILW

MensagemEnviado: 25 Jul 2007 09:43
por Pablo César
ilovewindev escreveu:Yo me ofrezco a traducir al espaniol o al ingles con mucho gusto
Que bien, esperamos contar con vos.

ilovewindev escreveu:Una pregunta al paso: alguien ha provado comunicar alguna aplicacion clipper via sockets/ipx/spx con una aplicacion windows ??? Es solo una idea que estoy investigando
ILW, no me tomes a mal, pero seria conviente que abrieras un nuevo tópico para tratar de este asunto si no tiene a ver con WAPI. Porque sinó se hace una confusion terrible.

ILW, podrias respondernos los cuestionamientos ? :
Mios, click aqui
De Maligno, click aqui

Así podemos proseguir en tu dificultad. O será que resolviste el problema ? Entonces, contanos como hiciste. Así nos sirve de experiencia, ok compatriota ?

MensagemEnviado: 25 Jul 2007 22:58
por Maligno
ilovewindev escreveu:Yo me ofrezco a traducir al espaniol o al ingles con mucho gusto

Thank you, ILW. Your offer will be considerated at the right moment. :)

MensagemEnviado: 27 Jul 2007 20:15
por Maligno
Para este final de semana estou planejando implementar os ítens abaixo:
  • Cancelamento de jobs de impressão do spooler
  • Fechamento de uma aplicação pelo seu handle
  • Apagamento seguro de arquivos (wipe file)
O terceiro é ainda uma dúvida, mas é algo que em algumas ocasiões eu precisei usar. Ou melhor, o cliente pediu que fosse feito.
Daria até pra fazer pelo Clipper mesmo, mas a manipulação de arquivos pelo Windows é bem mais eficiente. E dependendo do tamanho do arquivo, isso pode levar muito tempo. Sem falar na técnica envolvida. Há duas ou três formas específicas, todas em conformidade com as exigências do Departamento de Defesa americano, que podem exigir de dois a três passos sobre o arquivo.

MensagemEnviado: 28 Jul 2007 12:21
por Pablo César
Beleza, Maligno espero que você consiga. Só não lembro mais para qual situação foi estimulada fazer a função de "Fechamento de uma aplicação pelo seu handle" ?

E geralmente quais são os arquivos WIPE dos quais você se refere, poder dar exemplos ?.

MensagemEnviado: 28 Jul 2007 12:32
por Maligno
Pablo César escreveu:Só não lembro mais para qual situação foi estimulada fazer a função de "Fechamento de uma aplicação pelo seu handle" ?

Mas você mesmo levantou essa necessidade. :)))
Tudo bem. Eu próprio tenho aplicação pra isso. Mas você pode usar essa característica pra fechar algum aplicativo que você mesmo tenha invocado para desempenhar alguma tarefa específica, por exemplo.

E geralmente quais são os arquivos WIPE dos quais você se refere, poder dar exemplos ?.

Não. WIPE é um método de apagamento especial de arquivos, que os torna absolutamente irrecuperáveis. Por vezes documentos sigilosos precisam ser apagados. A técnica consiste em sobreescrever todo o documento com seqüências de bytes, a fim de tornar impossível sua recomposição. Depois disso o arquivo é apagado.
Sabe como é: existem ferramentas que podem recupar um arquivo fisicamente. Em certas situações é interessante que não se permita sua recomposição. Daí a necessidade desse tipo de artifício. Isso, inclusive, é muito utilizado por repartições públicas, autoridades, etc. Há duas ou três normas específicas para sobreescrita de arquivos, criadas pelo Departamento de Defesa americano. São essas as normas utilizadas em programas que têm essa finalidade.

MensagemEnviado: 28 Jul 2007 12:46
por Eolo
El Evil,
Uma pergunta, sobre o "wiping": se eu por ex sobrescrever toda a área livre de um HD com Zeros, só uma vez, como pode isso não ser suficiente pra evitar a futura leitura de algo que estava lá antes?

(lembro que o Norton Utilities deixa vc escolher quantas vezes o wiping vai ser feito...)

MensagemEnviado: 28 Jul 2007 12:57
por Maligno
Isso, Eolo, pra nós, simples mortais, é praticamente impossível. Mas pra quem tem maquinário apropriado, pode ser feita uma leitura "diferenciada" da mídia magnética. Quando se sobrescreve um bit 0 no lugar de 1, ainda fica uma ínfima marca do que estava ali, antes do 0 chegar. É uma memória magnética. A física explica. O material magnético é formado por cristais de óxido de ferro. Quando recebe uma informação, aquela posição tem seus cristais arranjados de forma a representá-la. Quando recebe outra informação, inversa, há um rearranjo. Mas isso não é perfeito. Aí que entra em ação o tal maquinário especial.
Por isso, pelo esquema do DoD, são utilizados até 3 passos de sobrescrita. Não lembro a seqüência agora, mas é coisa do tipo: no primeiro passo, tudo recebe 1. No segundo, quatro 1's e quatro 0's intercalados. Num terceiro passo, o mesmo, só que invertido. Algo assim. Há uma norma pra isso, claro.
O nome pra essa necessidade é "paranóia". Para o DoD é uma coisa totalmente justificada. Pra nós nem tanto, mas sabe como é: o seguro morreu de "véio". :)))

MensagemEnviado: 28 Jul 2007 14:04
por Eolo
Legal.

E mais legal ainda é o alerta pra quem pensa que, deletando um arquivo pelo WinExplorer, ele realmente some...

Lembra do UnErase (acho que era esse o nome) do PcTools? Uma vez, sem querer, deletei uma pasta (ops, na época, ainda era "diretório"!), com TODOS os fontes de um programa que tinha acabado de terminar. Pânico geral. Mas aí alguém me apresentou o PcTools e trouxe tudo de volta...

MensagemEnviado: 28 Jul 2007 14:09
por Maligno
Esse tipo de recurso de recuperação é que fez a fama e fortuna do já aposentado Peter Norton. Mas, pra evitar qualquer tipo de recuperação de informações, sigilosas, WIPE.

MensagemEnviado: 28 Jul 2007 14:16
por Pablo César
Maligno escreveu:você pode usar essa característica pra fechar algum aplicativo que você mesmo tenha invocado para desempenhar alguma tarefa específica, por exemplo.
Sim disto eu sei. Acho que foi por motivo de alguém estar precisando fechar a sessão, não lembro bem... Vou procurar depois.

WIPE é um método de apagamento especial de arquivos, que os torna absolutamente irrecuperáveis.
Ahhh pensei que eram arquivos que não dessem para serem deletados. Agora entendo sua nova proposta de função, acho legal. Eu mesmo faço isso quando crio arquivo de login e senhas para o FTP interpretar. Beleza !

MensagemEnviado: 29 Jul 2007 08:57
por Pablo César
Pablo César escreveu:
Maligno escreveu:você pode usar essa característica pra fechar algum aplicativo que você mesmo tenha invocado para desempenhar alguma tarefa específica, por exemplo.
Sim disto eu sei. Acho que foi por motivo de alguém estar precisando fechar a sessão, não lembro bem...
Achei a minha mensagem era para elaborar um servidor de impressão atarvés do USB.EXE (do Heveraldo) que ficava "ouvindo" se tem arquivo para ser impresso no BEMATECH que só imprimia no servidor. O colega Sergio Cabral tinha exposto seu problema aqui, só que o Sergio não respondeu se solucionou o seu problema ainda.

Mas de todas formas, fica valendo para muitas outras utilidades e conciência de cada um. Mas ainda acho bem válido essa função.

MensagemEnviado: 30 Jul 2007 18:12
por Maligno
pelo esquema do DoD, são utilizados até 3 passos de sobrescrita

Exatamente. São três passos, mas os valores são outros do que eu disse. Se alguém quiser um exemplo de paranóia, segurança e organização no mesmo lugar, nada melhor que ler o PDF que encontrei. É a norma DoD 5220.22-M, que traz diversas regras de segurança. Está na minha área "pub", diretório "manuals". Não li tudo, mas vi coisas bem interessantes. Ensina até como se deve redigir material confidencial sobre armas atômicas. Muito útil. :)

Leitura de dispositivos em USB no Clipper através da WAPI

MensagemEnviado: 31 Jul 2007 08:16
por Pablo César
O argentino, não respondeu se conseguiu fazer funcionar a WAPI.LIB na sua compilação.

Estive pensando... quantas dificuldades temos no Clipper com o avanço de novas tecnologias. Sabemos que podemos utilizar LIBs para capturar o sinal vindo pela saída serial (teclados, modens, leitor óptico, etc..). Mas esta mesma opção não temos para USB. Será que seria viável fazer isso através de APIs e elaborar um LIB em C ?

Se fosse possível, imaginem a importância desta LIB, pois estamos de mãos atadas quando se refere a leitor de digitais para fazer biometria, utilizar teclado USB (que são mais comuns e mais baratos), leitor de código de barras... e lá vai...

Não precisa Maligno, sentirse no compromisso de fazer. Sua resposta é mais do que aceitável se isto é viável ou não. Mas já não tenho como pedir mais nada para você. É simplesmente uma idéia e uma necessidade também, mas seria um passo a mais a ser dado pro futuro se for possível é claro.

MensagemEnviado: 31 Jul 2007 10:15
por ilovewindev
Pablo Cesar / Maligno

No consegui linkear la libreria sin tener error en tiempo de ejecucion (Error 6003) para ser mas exacto asi que la estoy usando como programa ejecutable directamente.

Con respecto a las dificultades de comunicar clipper con windows vengo investigando metodos alternativos para poder mejorar los programas con algunos resultados buenos a traves de programas similar a WAPI. Por ejemplo tengo un programa al que le envio un archivo de texto con una impresion configurada como si fuera para una impresora epson y lo imprime en la impresora por defecto en windows, pudiendo hacer una vista previa si uno lo desea.

He tratado de encontrar la vuelta al problema de comunicaciones DOS - windows pero no encuentro como realizar desde DOS una conexion DDE o algo similar con lo que pueda enviarle datos a un servidor DDE (Dynamic Data Exchange) escrito en Windows al que le pueda agregar prestaciones a gusto.


ILW

MensagemEnviado: 31 Jul 2007 10:50
por Pablo César
Hablando del ILW, el ILW se asoma... jijiji (un bromita).

ILW, creo que la solucion para esse erro fijate en este LINK: http://www.pctoledo.com.br/forum/viewto ... light=6003

Por ejemplo tengo un programa al que le envio un archivo de texto con una impresion configurada como si fuera para una impresora epson y lo imprime en la impresora por defecto en windows, pudiendo hacer una vista previa si uno lo desea.
Si claro, esto ya alcanzamos a este recurso. Ya viste el USB del colega Heveraldo, el USBPRINT del colega MarcosV ? Hay otros como el PRINTER.EXE y otros recursos de impresion que se pueden hacer por medio de creacion de arquivo de impresion sea en formato HTML tambien. Cual seria ese programa que usás podés decirnos y podés compartirlo con nosotros ?.

Cuanto a tu inquietud sobre DOS vs WINDOWS tambien es nuestro dilema tambien. Todo lo que puedas ofrecernos, será de gran utilidad, mismo que sean apenas questionamientos. Todo eso ayuda. Y como verás, hacemos cuestion que todo sea disponibilizado al público (mejor dicho a programadores) sin costos y sin exigencias. lo único que pedimos es participacion en ideas y tambien soluciones.

Ahora esa tu cuestion de DDE, yo no tengo know-how sobre eso. Hay mucho colegas aqui que trabajan con diversos BD y que talvez puedan pronunciarse. Esperemos que surja algo de ellos.

Re: Leitura de dispositivos em USB no Clipper através da WAP

MensagemEnviado: 31 Jul 2007 12:10
por Maligno
Será que seria viável fazer isso através de APIs e elaborar um LIB em C ?

Sempre existe uma possibilidade técnica. Agora, antes de entrar na questão de ser viável ou não, eu precisaria estudar cada caso. No que diz respeito ao leitor biométrico, por exemplo, precisaria de um leitor. Sei que você apenas citou exemplos, mas o teclado USB funciona de forma transparente no Windows. Não acho que faria diferença no DOS. Pelo menos com relação às impressoras, isso parece resolvido. A não ser no caso da tal Lexmark que o o Leonardo comentou. Mas se foi pro spooler, não há motivo para não funcionar. Acho que pode ter acontecido de terem testado com códigos não-específicos para essa impressora.

A questão ainda é flutuante, já que não há um "alvo" específico. A porta USB em si não representa o problema. O problema está no dispositivo. Minha resposta, portanto, fica no ar. Quando tiver um dispositivo "alvo" a atacar, aí sim eu poderia dar uma resposta mais objetiva. Por ora, a resposta é: à primeira vista é viável. :)

MensagemEnviado: 31 Jul 2007 12:29
por Maligno
ilovewindev escreveu:No consegui linkear la libreria sin tener error en tiempo de ejecucion (Error 6003)

In my earlier example I oriented you to link the file CT52.LIB. The CATools library has a bug that generate the error R6003 in faster machines. To fix it, you need actualize that library. In the "pub" area of my site (link in my signature), directory clipper/libs, download the patcher catools3_patch_l_3.zip to kill the problem. Try it. If the problem persist, warn us.

con lo que pueda enviarle datos a un servidor DDE (Dynamic Data Exchange) escrito en Windows

To answer your question I need to research a bit more about DDE (or even OLE). But, I think that's not so problematic to do in Clipper throught WAPI. I'll see and I'll return to this matter soon.

MensagemEnviado: 31 Jul 2007 15:31
por Pablo César
Mas se o teclado USB funciona de forma transparente no Windows, como faria para capturar essa bufferização ?.

A questão ainda é flutuante, já que não há um "alvo" específico. A porta USB em si não representa o problema.
Mas tudo que entra pela USB, pode ser escrito em arquivo por exemplo ?. Também haveria de identificar qual é a porta, isto é, USB001, USB002, etc. acho que é assim a identificação.

Quanto a questão DDE ou OLE, isto possibilitaria a aplicações Clipper acessar um .mdb ou até mesmo uma planilha Excel ? Ou então qual seria a finalidade disso ?

MensagemEnviado: 31 Jul 2007 15:48
por Maligno
Pablo César escreveu:Mas tudo que entra pela USB, pode ser escrito em arquivo por exemplo ?

Imagine o seguinte: você tem um hub USB com 10 portas, nas quais estão conectados 10 dispositivos totalmente diferentes. Você não manipular porta alguma. O Windows, ao detectar essas portas, vai identificar cada uma delas de maneira única e associar um certo driver a cada uma delas, conforme for o tipo do dispositivo. Por isso, se for, por exemplo, um teclado, ele não vai funcionar sem um software apropriado que receba os códigos vindos pela USB e injete-os no buffer do teclado, como se tivessem sido realmente digitados. Nunca vi teclado desse tipo, mas acredito que, sendo uma máquina virtual (NT), o DOS receba esses códigos de tecla normalmente.

Também haveria de identificar qual é a porta, isto é, USB001, USB002, etc. acho que é assim a identificação.

A identificação é diferente, mas isso é matéria apenas para o SO. Não tem muita importância pra nós.

Quanto a questão DDE ou OLE, isto possibilitaria a aplicações Clipper acessar um .mdb ou até mesmo uma planilha Excel ? Ou então qual seria a finalidade disso ?

Comentei sobre OLE por comentar. Na verdade, o DDE me parece ser bem mais fácil de utilizar (é mais antigo), apesar de não ter muita experiência com nenhum deles. OLE também se presta a isso, claro, mas acho o DDE mais "amigável". Inclusive, a aplicabilidade é interessante. Por DDE você poderia, por exemplo, preencher uma certa célula do Excel com um valor qualquer.

MensagemEnviado: 31 Jul 2007 15:55
por Pablo César
Quando fui ver por segunda vez sua mensagem tinha sumido... hihi (você a estava re-editando).

Maligno escreveu:Você não manipular porta alguma. O Windows, ao detectar essas portas, vai identificar cada uma delas de maneira única e associar um certo driver a cada uma delas
Pois é, mas essa associação podia ser forçada para que o conteúdo vindo de determinada porta venha a ser gavado em arquivo texto ? Digamos.

Maligno escreveu:A identificação é diferente, mas isso é matéria apenas para o SO. Não tem muita importância pra nós.
Se for atribuir uma função uma determinada porta, com certeza terá um nome essa porta, certo ?.

Maligno escreveu:você poderia, por exemplo, preencher uma certa célula do Excel com um valor qualquer.
A isso a que me referia. Inclusive gravar em .mdb ?

MensagemEnviado: 31 Jul 2007 16:18
por Maligno
Pois é, mas essa associação podia ser forçada para que o conteúdo vindo de determinada porta venha a ser gavado em arquivo texto ? Digamos.

Sim, poderia, mas não parece ter muita utilidade.

Se for atribuir uma função uma determinada porta, com certeza terá um nome essa porta, certo ?.

Com certeza. Será um nome do tipo USB34098DUTU2938FH23, como o Windows costuma fazer. :)))

Inclusive gravar em .mdb ?

Que eu saiba não diretamente no banco de dados. Aí você utilizaria OLEDB, por exemplo. Talvez por meio do próprio Access. Talvez. :)

MensagemEnviado: 31 Jul 2007 16:25
por ilovewindev
Pablo Cesar,

con DDE se crea una comunicacion Cliente - Servidor entre dos programas con lo que se podria desde el programa Clipper pedirle al programa Servidor que muestre datos procesados en clipper con un formato mas Windows, generar reportes de cualquier tipo con preview, exportar los datos a cualquier formato, leer datos de un dispositivo y enviarlos de la aplicacion servidor a la aplicacion clipper, etc. Inclusive armar un menu bajo windows que llame a pantallas de carga en el programa Clipper y vuelva al menu una vez concluido. Los procesos de migracion de los sistemas en clipper a otra herramienta de desarrollo serian un placer (esto sin desmerecer a clipper), pero la vida de clipper se podria extender varios años mas.

ILW

MensagemEnviado: 31 Jul 2007 16:39
por Pablo César
Si entiendo, lo más interesante que desde el aplicativo Clipper se pueda leer datos de un dsipositivo y exportar tambien para cualquier formato. Seria estupendo, esperamos que Maligno pueda realizar este milagro.

MensagemEnviado: 04 Ago 2007 17:28
por Maligno
Terminei a função de encerramento de aplicações. Testada tanto no XP quanto no Win98, ela pode receber o handle de uma aplicação específica ou o nome do seu arquivo executável. Neste último caso, se existirem, por exemplo, duas instâncias do NotePad, todas serão fechadas. E esse fechamento é imediato. Logo, se os dados não tiverem sido gravados, serão perdidos.

MensagemEnviado: 04 Ago 2007 17:41
por Maligno
Em tempo: só vou liberar o novo ZIP na madrugada de segunda. Vou fazer mais algumas coisas na WAPI. :)

MensagemEnviado: 05 Ago 2007 05:31
por Pablo César
Ok Maligno, good working for you !

Revisando os novos tópicos abertos desde o meu ultimo acesso, me interessei em saber e concordar que em alguns clientes que utilizam-se de protetores de tela (do próprio Windows), não só atrapalham como também tornam o ambiente pesado (lento). Aí pergunto Maligno: tem como fazer para desabilitar o protetor de telas do Windows através de APIs ?

MensagemEnviado: 05 Ago 2007 08:40
por Maligno
Boa idéia. Tanto tem que já incluí na TODO list. :)

MensagemEnviado: 06 Ago 2007 09:01
por Maligno
Lista de funções removidas. Procure-a numa mensagem mais nova.

MensagemEnviado: 06 Ago 2007 22:24
por Pablo César
Parabéns Maligno. Testei as duas novas funções em modo RUNTIME e funcionou como esperado. O único que tenhoa comentar é sobre dois errinhos que notei no WAPI.C nas seguintes funções:

-SCREENSAVER:{GET|SET};{resultFile|{ON|OFF}}
* Lê o estado do screenSaver ou o reconfigura. O primeiro parâmetro deve ser a palavra de
* definição da tarefa, conforme se queira ler (GET) ou configurar (
GET)... sendo que era para ser SET

-KILLAPPLICATION:<handle>[;<fileName>] ficou faltando a letra "L"

Era isso o único que pude criticar... hehe... Dei-me conta dos erros de escrita porque eu sempre gosto de ler o arquivo WAPI.C

Estas duas novas funções, ficaram muito bom. E inclusive em WIN98. Valeu Maligno. Essa funçãod do SCREENSAVER eu já vou usar na minha BATCH para desabilitar esse protetor de tela que as vezes trava e incomoda.

MensagemEnviado: 06 Ago 2007 22:38
por Maligno
Obrigado pelas correções, Pablo. Passaram batido. Deve ter sido a pressa ou o sono. :)
Já corrigi, mas não sou subir a correção agora. Nem tem tanta pressa, já que logo haverá outra atualização. Ademais, nas funções de abstração, no que me consta, está tudo certo. São essas três funções que mais importam.

MensagemEnviado: 06 Ago 2007 23:03
por Pablo César
Pois é percebí a data e hora dos arquivos, muito tarde...

Também percebí que no seu TODO LIST ficaram faltando os seguintes itens:

- Cancelamento de jobs de impressão do spooler
- Função para o modo residente no tray, "escutando" certo diretório em busca de certo arquivo a fim de que seja executado determinado aplicativo.

Não sei se esta ultima você ficou em analisar e fazer alguns testes. Assim como a questão de captura de resultados em USB e possibilidade de uso de DDE com o Clipper.

Outra questão que eu ainda não esqueço, é aquela questão de identificar se a sessão está em modo JANELA ou TELA-CHEIA. Nesta questão eu tinha sugerido a verificação de @ 00,00 da janela (ou o seu valor em pixels) para saber se nessa posição exite algum caracter ASCII ou se é gráfico. Só sei que ficou em que você ainda iria fazer uns testes.

MensagemEnviado: 06 Ago 2007 23:29
por Maligno
Pablo César escreveu:Pois é percebí a data e hora dos arquivos, muito tarde...

Fui tentar dormir naquela hora. Só tentei. :)

- Cancelamento de jobs de impressão do spooler

Ah, sim. Esqueci de comentar. Estive pensando com meus botões e acho que o cancelamento de uma tarefa de impressão é algo meio supérfluo e inútil. Supérfluo porque nem sempre se vai querer cancelar. E inútil porque muitas vezes o spooler demora uma pá de tempo pra cancelar a impressão. Não sei se vale o esforço de fazer isso.

- Função para o modo residente no tray

Veja de novo. Esta é a primeira da lista. Chamei de modo RES.

Não sei se esta ultima você ficou em analisar e fazer alguns testes. Assim como a questão de captura de resultados em USB e possibilidade de uso de DDE com o Clipper.

Capturar resultados em USB, já tinha comentado, é algo extremamente vago. Um monte de coisas pode vir pela USB. Seja impressora, scanner, mouse, teclado, etc. O que chega pela USB tem que passar por um driver do Windows. E sobre qual dispositivo? Para qual finalidade? Acho que o que mais interessava era a impressora USB, que é um problema praticamente resolvido. Mas de entrada, realmente não vejo o quê.
Sobre o DDE eu esqueci de colocar na nova sub-lista de "Possibilidades não confirmadas", que você pode ver na TODO list que acompanha a WAPI. Vou colocar agora.

Outra questão que eu ainda não esqueço, é aquela questão de identificar se a sessão está em modo JANELA ou TELA-CHEIA.

Sim, faltaram os testes, mas não esqueci. Só faltou tempo. :)

MensagemEnviado: 06 Ago 2007 23:39
por Pablo César
Maligno escreveu:inútil porque muitas vezes o spooler demora uma pá de tempo pra cancelar a impressão.
Ahhh é ? Eu pensei que essa demora pudesse ser encurtada, como você disse tem vezes que demora uma pá mesmo !. Então sendo assim, eu não a considero tão útil assim. Ao menos que você consiga encurtar caminhos e fazer alguma mágica no sistema do spooler.

Maligno escreveu:
- Função para o modo residente no tray

Veja de novo. Esta é a primeira da lista. Chamei de modo RES.
Esta função poderá ser vinculada como ouvidora, isto é verificar a todo instante determinado arquivo e executar determinado aplicativo ?.

Maligno escreveu:Sim, faltaram os testes, mas não esqueci. Só faltou tempo.
Ahhh bom ! Porque esse WIN98 é um KHARMA para você e para mim um suplício que tenho que conviver... Além de que este recurso iria possibilitar alternar a sessão com ALT-ENTER ora seja manual (dando mensagem ao usuário pra fazé-lo) ou através da futura função do WAPI.

MensagemEnviado: 07 Ago 2007 01:10
por Maligno
Pablo César escreveu:Então sendo assim, eu não a considero tão útil assim. Ao menos que você consiga encurtar caminhos e fazer alguma mágica no sistema do spooler.

O que eu poderia fazer é exatamente o que o próprio spooler faz. Então, daria no mesmo. :)

Esta função poderá ser vinculada como ouvidora, isto é verificar a todo instante determinado arquivo e executar determinado aplicativo ?.

Acho que você não está bem lembrado, mas já conversamos sobre isso em algumas oportunidades. É exatamente a funcão do modo residente: monitorar certo diretório para a carga de comandos via arquivo. Aliás, para até mesmo executar várias tarefas ao mesmo tempo, já que ele vai trabalhar com um sistema multi-threading.

este recurso iria possibilitar alternar a sessão com ALT-ENTER ora seja manual (dando mensagem ao usuário pra fazé-lo) ou através da futura função do WAPI.

A função de injeção de atalhos no buffer do teclado?

MensagemEnviado: 07 Ago 2007 07:49
por Pablo César
Maligno escreveu:A função de injeção de atalhos no buffer do teclado?
Ou até, eu disse. Se não for viável pela injeção do atalho com o WAPI, eu ficaria louco de contente, apenas avisando por usuário:

ALERT("Pressione as teclas ALT ENTER simultaneamente para mudança de exibição da tela.")

Puxa, a sua função de habilitar/desabilitar o SAVESCREEN do Windows, ficou muito bom. Testei hoje novamente, em situações de mudança de tipos de protetores e ainda com senha, no entanto funcionou legal. Ficou bom isso, gostei.

MensagemEnviado: 07 Ago 2007 08:56
por Pablo César
Maligno escreveu:eu esqueci de colocar na nova sub-lista de "Possibilidades não confirmadas", que você pode ver na TODO list que acompanha a WAPI. Vou colocar agora.
Não esqueça também de adicionar testes de avaliação de desativar/ativar mouse do OS.

MensagemEnviado: 07 Ago 2007 09:46
por Maligno
Não esqueça também de adicionar testes de avaliação de desativar/ativar mouse do OS.

Esqueci de colocar na lista. Boa lembrança. Vou colocar agora, antes que esqueça de novo. :)

MensagemEnviado: 07 Ago 2007 09:50
por Pablo César
Maligno escreveu:Não entendo por quê você utiliza RunWAPICmd() diretamente, se existem as funções da biblioteca que fazem todo o trabalho por você de forma mais fácil e segura.
Lembro deste puxão de orelhas (acho que merecido) pois tenho aind aum vício de utilizar o WAPI.EXE como RUNTIM e não usufruir da WAPI.LIB. E estou mudando os chamado das funções da WAPI para acesso direto.

Deram certo a compilação e execução na utilização das funções:

GETMYHANDLE()
WINDOW2TOP()
FLASHTBAR()

Mas quando precisei compilar meu aplicativo para uso do SENDTORECYCLEBIN() não deu certo, dando a seguinte mensagem de erro na link-edição:

BLINKER : 1115 : LOCAR12.OBJ(LOCAR12) : ´SENDTORECY´ : unresolved external

Sei que esse erro deu porque não encontrou a função na LIb ou em lugar algum. Mas a minha sintaxe de link-edição é correta e fiz assim:

BLINKER FI %1,__WAIT,ERRORSYS,HELP,TIMESLIC LIB CT,WAPI

Acredito que este tipo de erro deveu-se a que o nome da função é muito grande ou seria porque não foi declarada essa função para ser interpretada no procedimento que foi criada a WAPI.LIB ?.

MensagemEnviado: 07 Ago 2007 10:01
por Maligno
E estou mudando os chamado das funções da WAPI para acesso direto.

As funções da biblioteca tanto fazem a chamada da forma sempre correta (você não precisa se preocupar com a formatação) como também faz o tratamento automático do retorno, se houver. Você não precisa esquentar a cabeça com nada. E até fica parecendo que acessar a API do Windows é natural para o Clipper. :)

Mas quando precisei compilar meu aplicativo para uso do SENDTORECYCLEBIN() não deu certo, dando a seguinte mensagem de erro na link-edição:

BLINKER : 1115 : LOCAR12.OBJ(LOCAR12) : ´SENDTORECY´ : unresolved external

Que bom que você resolveu finalmente abandonar o RTLink. Vai ver só. Ficará muito melhor daqui pra frente.

Mas o nome da função está completamente errado. O correto é Del2RecBin(). Infelizmente, com a limitação dos nomes dos símbolos em Clipper para 10 caracteres, tenho que inventar nomes mais curtos. Aliás, há vários casos semelhantes. Veja o README.

BLINKER FI %1,__WAIT,ERRORSYS,HELP,TIMESLIC LIB CT,WAPI

Se você usar a função BliCPURel() do próprio BLinker, não precisará mais da função FreeTSlice(). Seu funcionamento é semelhante, com a vantagem de também funcionar no CLD, o que não acontece com a FreeTSlice().

MensagemEnviado: 07 Ago 2007 10:21
por Maligno
Acabo de detectar um erro na função SetWinSSav(). Nem se pode chamar de erro, propriamente. Uma falha. Se desativar o protetor de tela no XP, ele realmente desativa, mas ao reiniciar a máquina, ele volta ao estado anterior. É fácil observar. Ao mudar para desabilitado, vendo nas "propriedade" do DeskTop, nota-se se que o protetor continua configurado. No Windows 98, entretanto, não acontece. Ao desabilitar o protetor de tela, ele muda o protetor para "nenhum".

Mas como o programa Clipper sempre vai executar essa verificação e desativar se estiver ativado, o problema não será sentido em tempo de execução deste programa. Mas ainda assim, vou verificar isso. Se for coisa simples, até posso alterar, mas não é crítico. Nem causa prejuízo.

MensagemEnviado: 07 Ago 2007 10:29
por Pablo César
Maligno escreveu:Que bom que você resolveu finalmente abandonar o RTLink.
hihi não fique tão feliz, ainda devo fazer várias mudanças, principalmente a instalação do BLINKER Versão 7 pois estou com a 5.10. Ora também como disse em outras ocasiões, eu utilizo o BLINKER mas para certos módulos. No entanto tenho conciência que o BLINKER é muito melhor que o RTLINK (mas tenho que fazer adaptabilidades no meu CT.LIB) para que funcione bem com o BLINKER. Você inclusive mencionou no seu TODO LIST:

Remover a dependência das bibliotecas CATools e NanFor
Ao quê se refere você disto ?

Mas o nome da função está completamente errado. O correto é Del2RecBin().
Ahhh era como tinha pensado mesmo, até ví esse nome no seu PRG mas pensei que fosse só exemplo. Então podemos considerar que tais exemplo estão também incorporados na WAPI.LIB ? Ousimplesmentye coincidiu ? Eu tenho o costume de ler diretamente no WAPI.C, que alias a sua documentação é realmente fantástica (você é muito detalhista, gosto disso colega). Mas será que seria muito confuso mencionar as SWITCHES e ao lado como funções da LIb ?

Se você usar a função BliCPURel() do próprio BLinker, não precisará mais da função FreeTSlice()... a vantagem de também funcionar no CLD
Ahhh bom ter mencionado.

MensagemEnviado: 07 Ago 2007 10:57
por Maligno
Ao quê se refere você disto ?

Quero deixar a WAPI independente de qualquer outra LIB. É isso.

Então podemos considerar que tais exemplo estão também incorporados na WAPI.LIB ?

Mas de quais exemplos você está falando? Não tem exemplo nenhum no ZIP.

Mas será que seria muito confuso mencionar as SWITCHES e ao lado como funções da LIb ?

O utilitário WAPI.EXE tem seus switches que nada têm a ver com as funções da biblioteca. Portanto, prefiro manter essas descrições separadas. Até porque, os comentários que existem em WAPI.C estão lá apenas por quê eles têm que existir. Mas sempre peço pra usarem o README.TXT da biblioteca para se nortearem.

MensagemEnviado: 07 Ago 2007 15:03
por Pablo César
Maligno escreveu:
Então podemos considerar que tais exemplo estão também incorporados na WAPI.LIB ?

Mas de quais exemplos você está falando? Não tem exemplo nenhum no ZIP.
Cómo não ? Tem sim:

\LIB\APP\APPSINFO.PRG
\LIB\APP\APPTITLE.PRG
\LIB\APP\DIRORIGN.PRG
\LIB\APP\FLASHBAR.PRG
\LIB\APP\KILLAPPL.PRG
\LIB\APP\MYHANDLE.PRG
\LIB\APP\SETBUTNX.PRG
\LIB\APP\SETSTART.PRG
\LIB\APP\SETTASKB.PRG
\LIB\APP\WIND2TOP.PRG
\LIB\FILE\DEL2RBIN.PRG
\LIB\FILE\MAKEPATH.PRG
\LIB\FILE\SEEKPATH.PRG
\LIB\FILE\UNIQFNAM.PRG
\LIB\GENERIC\COMPATIB.PRG
\LIB\GENERIC\COMPVLRS.PRG
\LIB\GENERIC\GETHDINF.PRG
\LIB\GENERIC\RANDOMIC.PRG
\LIB\INTERNET\DOWNFILE.PRG
\LIB\INTERNET\ISINTERN.PRG
\LIB\OS\GETCLIPB.PRG
\LIB\OS\OS_STATE.PRG
\LIB\OS\SCRSAVER.PRG
\LIB\OS\SETCLIPB.PRG
\LIB\OS\SYS_INFO.PRG
\LIB\OS\WIN_INFO.PRG
\LIB\PRINTER\DEFPRINT.PRG
\LIB\PRINTER\GETPRINT.PRG
\LIB\PRINTER\PRINTFIL.PRG
\LIB\REGISTRY\DELETREG.PRG
\LIB\REGISTRY\READ_REG.PRG
\LIB\REGISTRY\WRITEREG.PRG
\LIB\SOUND\PLAYWAVE.PRG
\LIB\STRING\LTRIMSTR.PRG
\LIB\STRING\QUOTESTR.PRG
\LIB\STRING\XALLTRIM.PRG
\LIB\WAPIFCTS\EXECWAPI.PRG
\LIB\WAPIFCTS\READRETF.PRG
\LIB\WAPIFCTS\WAPIERRO.PRG
\LIB\WAPIFCTS\WAPISETS.PRG

Mas desconsidere a minha pergunta, pois o que eu ví não tem a haver. Quero dizer a função Del2RecBin() não é o mesmo nome que o DEL2RBIN.PRG.

Mas sempre peço pra usarem o README.TXT da biblioteca para se nortearem.
Okay, you are right !

MensagemEnviado: 07 Ago 2007 15:12
por Maligno
Cómo não ? Tem sim:

Mas esses arquivos não são exemplos. São fontes. :)

MensagemEnviado: 07 Ago 2007 15:16
por Pablo César
Ahhh é ? Quê igênuo eu fui. Claro agora entendo, esses fontes são os que compõem a LIB. Tá certo, eu tinha pensado isso no começo e depois me confundí. Mas é claro, agora faz sentido. Puxa... fui tolo em não perceber isso. Só pode !.

MensagemEnviado: 07 Ago 2007 15:17
por Maligno
Mudando de assunto:
Eu estava protelando colocar isso no WAPI, mas não tive escapatória. Vou ter que alterar o utilitário WAPI.EXE, mais precisamente na função do parâmetro PRINT, para poder fazer impressão parcial, da página X a Y, ou mesmo uma lista de páginas, em certa quantidade de impressões e com possibilidade de impressão com ordem invertida. De forma semelhante ao que se faz no Windows. Já estou trabalhando nisso e à noite deve ficar pronto. Alguma sugestão? Aproveite que estou com a mão na massa. :)

MensagemEnviado: 07 Ago 2007 15:18
por Maligno
fui tolo em não perceber isso. Só pode !.

Acontece mas melhores famílias. Às vezes eu também tenho uns "brancos" que até me dão vergonha. :)

MensagemEnviado: 07 Ago 2007 15:33
por Pablo César
Maligno escreveu:função do parâmetro PRINT, para poder fazer impressão parcial, da página X a Y
Wauu legal ! E dá pra fazer isso ? Qual seria a referência ? O CHR(12) ?.

ou mesmo uma lista de páginas, em certa quantidade de impressões e com possibilidade de impressão com ordem invertida.
Puxa legal esse recurso. Legal mesmo !

Maligno você não se ofende se eu passar essa idéia pro MarcosV fazer no seu aplicativo ? No final, eu ja não sei com o quê ficar... É que a formatação feita de forma variavel, me interessa muito sem precisar de comando algum de impressão. A idéia que eu passei pro Marcos sobre seleção da fonte, modo de impressão (rascunho/otimizado), orientação do papel (paisagem/retrato) e tamanho e modo das fontes (normal/negrito), utdo isso ajudaria muito.

Então se não for muito pedir... ao menos faça a orientação do papel (se possível).

MensagemEnviado: 07 Ago 2007 16:35
por Maligno
Pablo César escreveu:Wauu legal ! E dá pra fazer isso ? Qual seria a referência ? O CHR(12) ?.

Não. O CHR(12) é comando de ejeção. Ele sempre fica no final da página. Eu preciso de um código no início. E como ele não será repassado ao spooler, vou escolher depois um código qualquer. :)

Maligno você não se ofende se eu passar essa idéia pro MarcosV fazer no seu aplicativo ?

Imagina, Pablo. Nem precisava perguntar. A idéia nem é minha. Só estou copiando o que vemos no Windows todos os dias. :)

Então se não for muito pedir... ao menos faça a orientação do papel (se possível).

Como eu já disse pra você várias vezes, não é necessário isso tudo. Se você tiver um conjunto de funções de abstração para uso no seu programa, vai notar que tudo ficará muito simples. Aliás, vai notar também que só faltaria a impressão do modo que vou colocar no WAPI agora. :))

Ademais, acho o esquema dos programas do Marcos e do Heveraldo, só pra citar dois, um tanto amarrado. Se fosse fazer assim, deixaria a criação das tags por conta de quem vai usar o programa. Não digo apenas com relação aos nomes em si, mas também a quais tags seriam criadas e a quais códigos elas seriam vinculadas. Seria mais ou menos o que eu tenho hoje no meu programa. Mais dinâmico, entende?
Sem falar, claro, que eu jamais usaria o modo gráfico. Só texto mesmo, como faço hoje.

MensagemEnviado: 07 Ago 2007 17:11
por Pablo César
Maligno, como eu disse antes, irei testar a WAPI.LIB e fiz assim:

RunWAPICmd("-SENDTORECYCLEBIN:"+Quote(VDIR+"\"+VCAIX[nCurElement])+";TESTE.TXT")

* e também assim:

IF DEL2RECBIN(VDIR+"\"+VCAIX[nCurElement])=.T.
   ALERT("Arquivo "+VCAIX[nCurElement]+" deletado com sucesso !.")
ENDIF


Rapaz... ele deletou ja vários arquivos mas em ambos os casos, não colocou na lixeira do Windows (WIN98). Em contra-partida, fiz o teste na linha de comando com WAPI.EXE e funcionou normal.

Estaria eu fazendo algo errado ? Ahh e também me aconteceu que depois de executar os dois exemplos de funções da WAPI.LIB, o cursor fica ativo e não tem "xHarbour" que possa desativar...

MensagemEnviado: 07 Ago 2007 17:26
por sygecom
Ahh e também me aconteceu que depois de executar os dois exemplos de funções da WAPI.LIB, o cursor fica ativo e não tem "xHarbour" que possa desativar...

Tche, Pablo.....o que tem Haver o xharbour com a Wapi ?...deixa pra lah...toh só brincando...não esquenta a cabeça com o xharbour...ele não morde,não desgasta, não desbota no sol.....hehe...

Abraços
Leonardo Machado

MensagemEnviado: 07 Ago 2007 17:29
por Maligno
Só há duas formas do arquivo ser apagado e não ir pra lixeira: 1) a lixeira não está configurada para receber arquivos (parece que não é esse o caso) e 2) o nome do caminho não está sendo informado completamente.
Em todo caso, vou fazer uma nova checagem. Mas a princípio, posso adiantar que a função Del2RBin() funcionou perfeitamente. Veja o meu código de teste a seguir. Ele foi usado para teste no XP.

function Main()
local cDir := "d:\work\wapi\demos\"
local aFil := {"tst1.xxx",;
               "tst2.xxx",;
               "tst3.xxx",;
               "tst4.xxx",;
               "tst5.xxx" ;
               }

clear
AEval(aFil,{|c,i|aFil[i] := cDir+c})
Del2RecBin(aFil)
quit

É um código meio tosco, mas funcionou certinho. :)
Vou fazer outros testes e retorno a seguir.

MensagemEnviado: 07 Ago 2007 17:37
por Pablo César
Maligno escreveu:2) o nome do caminho não está sendo informado completamente.
De fato a minha varável VDIR está faltando a unidade (neste meu caso, deveria ser "C:"), e era isso mesmo. O caminho estava completo porém sem a identificação da unidade dá o resultando não esperado. Eu acho que essa questão da unidade poderia ser insentada, pois não para todas as estações a unidade sempre é a mesma LETRA, também nada impede de obter também a LETRA da unidade com VVOL:=SUBSTR(ALLTRIM(EXENAME()),1,2). No entanto se a WAPI verificar que esse arquivo existe, poderia insentar a unidade, você não acha Maligno ?

E quanto a questão de retorno com o cursor em "ON" cómo será que resolvo isso ?

MensagemEnviado: 07 Ago 2007 17:52
por Maligno
De fato a minha varável VDIR está faltando a unidade

Então está resolvido o mistério. Não vou nem mais me preocupar em testar de novo.

E quanto a questão de retorno com o cursor em "ON" cómo será que resolvo isso ?

Só posso dizer que isso não é coisa do utilitário WAPI. Provavelmente é algo relacionado ao RUN ou mesmo ao SwpRunCmd(). Mas isso não acontece comigo. Isso que o executor do WAPI.EXE não tem um "salvador" de estado do cursor, como já usei numa função minha para "sair" pro DOS, justamente pra evitar esse tipo de problema.

Se bem que isso deveria acontecer com qualquer função da biblioteca, já que o executor é sempre o mesmo. Acontece? E em qual SO?

MensagemEnviado: 07 Ago 2007 18:11
por Pablo César
Pablo escreveu:Eu acho que essa questão da unidade poderia ser insentada, pois não para todas as estações a unidade sempre é a mesma LETRA, também nada impede de obter também a LETRA da unidade com VVOL:=SUBSTR(ALLTRIM(EXENAME()),1,2). No entanto se a WAPI verificar que esse arquivo existe, poderia insentar a unidade, você não acha Maligno ?
O quê você acha ?

Maligno escreveu:isso deveria acontecer com qualquer função da biblioteca, já que o executor é sempre o mesmo. Acontece? E em qual SO?
Não sei ainda, pois estou avaliando a possibilidade de usar a WAPI.LIB ou o WAPI.EXE. Porque como eu disse, meu sistema é por módulos gerenciados através de uma batch, e este problema não transparece na linha de comando. SO ? WIN98 e XP, em ambos acontece o mesmo do cursor persistir. Talvez seja porque estou dentro de uma função controladora do ACHOICE ?. Achei estranho, ja que não é exibido em tela coisa alguma.

MensagemEnviado: 07 Ago 2007 19:06
por Maligno
O quê você acha ?

Eu acho que o problema é simples de resolver. Se você agora já sabe que deve incluir a letra do drive, basta não se esquecer de incluir a letra do drive. :)
O que de mais diferente poderia ser feito seria incluir um parâmetro lógico que, se verdadeiro, usaria o drive/caminho atualmente selecionado pelo programa. Este drive/caminho seria automaticamente incluído na linha de comando para o WAPI.EXE. Eu jamais usaria isso. Em todo caso,...

No WAPI.C eu não vou mexer. Acho que não é função dele fazer verificação e/ou suposição sobre a existência dos arquivos. E nem precisa. Pode-se resolver isso na biblioteca.

Achei estranho, ja que não é exibido em tela coisa alguma.

Façamos o seguinte: eu incluo na biblioteca um "salvador" de estado do cursor. Assim, quando for executar o WAPI, ele salva o estado e desliga o cursor. Ao retornar, ele restaura o estado e tudo volta a ser como antes.

MensagemEnviado: 11 Ago 2007 08:19
por Pablo César
Bom dia, benemérito colega !

Maligno escreveu:Façamos o seguinte: eu incluo na biblioteca um "salvador" de estado do cursor. Assim, quando for executar o WAPI, ele salva o estado e desliga o cursor. Ao retornar, ele restaura o estado e tudo volta a ser como antes.
Ahhh ora pois, acho que agora entendí. Você se refere a fazer uma nova função no WAPI ?. Tinha pensado que você estava caçoando de mim... ahhh com essa função acredito que irá resolver qualquer problema de cursor. Ou será que é uma questão do SO ? (espero que não). Se você quiser me mandar uma versão do WAPI de teste (já com essa função) eu vejo se resolveu, senão penso que não irá ter jeito...

MensagemEnviado: 11 Ago 2007 08:25
por Pablo César
Maligno, gostaria de te perguntar sobre esse novo item que irás desenvolver:

- Funções de FTP: list, delete, upload, download, etc...

Você pensa incluir uma opção que verifique a existência de determinado arquivo ? Assim como existe o comando "ls" no FTP ?

Nessa questão do WAPI trabalhando em background (no tray, seria ?) teria como colocar essa nova função de FTP nesse recurso no tray ?

MensagemEnviado: 11 Ago 2007 12:33
por Maligno
Se você quiser me mandar uma versão do WAPI de teste

Creio eu não ser necessário, uma vez que não é uma função propriamente. É apenas um recurso a mais no executor do WAPI, a função RunWAPICmd(). Uma variável guardará o estado do cursor e o fará invisível. No retorno, recupera-se esse estado. Só isso. Se funcionar (acredito que sim), ótimo. Se não funcionar, não fará mal algum.

Agora, o por quê disso acontecer eu não sei. É um mistério pra mim. Comigo não aconteceu nem mesmo uma única vez.

MensagemEnviado: 11 Ago 2007 12:40
por Maligno
Você pensa incluir uma opção que verifique a existência de determinado arquivo ? Assim como existe o comando "ls" no FTP ?

Com certeza. LS é parte do "etc" que eu mencionei. :)

Nessa questão do WAPI trabalhando em background (no tray, seria ?) teria como colocar essa nova função de FTP nesse recurso no tray ?

Qualquer coisa vai funcionar no modo residente da mesma forma como funciona no modo transiente. O objetivo do modo residente é tornar o trabalho mais fácil. E dinâmico, como a execução de múltiplas tarefas (multi-threading).

MensagemEnviado: 11 Ago 2007 20:40
por Pablo César
Beleza ! You are really, a good fellow !

MensagemEnviado: 16 Ago 2007 00:32
por Maligno
Percebi um erro na versão 1.02 da WAPI: as funções de internet não foram incluídas na LIB. Errei no meu batch de compilação e deixei esse diretório de fora. Apesar da outra versão já estar pra sair, corriji esta e já substituí o ZIP.

MensagemEnviado: 16 Ago 2007 08:50
por Pablo César
Bom você ter mencionado o erro e eu ja baixei a versão 1.02, pois eu uso a função URL2FILE do WAPI.EXE. O que percebí que a WAPI.LIB está evidentemente maior (tamanho do arquivo) do que a anterior, mas o WAPI.EXE continua com a mesma data e tamanho. Será que ficou faltando atualização no executável também ?

MensagemEnviado: 16 Ago 2007 09:21
por Maligno
Não. O problema foi apenas o esquecimento de incluir as funções de Internet na LIB. Nada mudou no WAPI.EXE.
Aliás, se você usa o parâmetro URL2FILE, é porque não está usando as funções da biblioteca. :)))

MensagemEnviado: 16 Ago 2007 17:56
por Pablo César
Ahh sim entendo, foi o seu procedimento de elaboração da própria LIB que tinha ficado de fora tais funções e não no WAPI.EXE.

Estou ainda utilizando o WAPI.EXE porque na minha situação é mais "prático" utilizar o executável no próprio arquivo de lote onde gerencio o meu acesso do sistema modular.

MensagemEnviado: 16 Ago 2007 18:03
por Maligno
Aliás, falando em praticidade,... Na thread a respeito do problema do Andril, para apagar um arquivo no servidor, pelo PHP daria pra fazer tudo o que se faz pelo FTP. Ou, pelo menos, quase tudo. Basta montar um script apropriado e executá-lo pela função DLoadFile() ou, caso você ainda prefira, pelo parâmetro URF2FILE. Listagem de arquivos, apagamentos, etc.
Mas é só uma divagação da minha parte. É claro que eu ainda prefiro fazer o FTP. Fica parecendo menos gambiarrístico. :)))

MensagemEnviado: 18 Ago 2007 15:23
por Pablo César
Maligno, eu estou usando muito a função WINDOW2TOP e gostaria que não aparecesse "handle: <aparece o handle passado como parâmetro>" na tela. Teria como silenciar isso ?

MensagemEnviado: 18 Ago 2007 18:14
por Maligno
Opa! Desculpe, Pablo. É uma string de teste que eu deveria ter me lembrado de apagar. Vou subir junto com o novo PRINT amanhã.

MensagemEnviado: 18 Ago 2007 19:32
por Pablo César
Ahh beleza ! Eu achei meio estranho, mas claro isso acontece, nem precisa pedir desculpas. Esse WAPI está ficando um baita de biblioteca e uma grandiosa contribuição ao Clipper.

MensagemEnviado: 18 Ago 2007 19:55
por Maligno
Aconteceu por quê o Murphy sentou do meu lado e não arredou pé até eu subir o ZIP. Aquele desgraçado! :)))

MensagemEnviado: 18 Ago 2007 20:28
por Eolo
Maligno, vi o seu termo "gambiarrístico" e não resisti. Consultei o dicionário mas nada. Aí GOOGLEei "Gambiarra" e... olha o que eu achei no "Desciclopédia" (http://www.desciclo.pedia.ws/wiki/POG):

POG - Programação Orientada a Gambiarras ou
WOP - Workaround-Oriented programming

E sabe qual a segunda citação no site?
"Foi Murphy quem inventou o POG." :-)

MensagemEnviado: 18 Ago 2007 21:59
por Maligno
Ah, sim. Essa enciclopédia é muito boa. Gostei da frase: 'Professor... Eu sou programadora há uns cinco anos... Só não entendi aquele comando "IF"... '
:)))

MensagemEnviado: 27 Ago 2007 18:58
por Pablo César
Olá caríssimo colega Maligno, gostei do seu novo avátar. Estamos aqui de volta após cirugia para extrair um cáculo na visícula, quase posso dizer que ja consigo andar e comer (quase) que normalmente. Fico sentindo necessidades de acessar aqui o nosso fórum e ver a evolução do WAPI e do USBPRINT do Marcos que deixam-me realmente muito ancioso de ver resultados. Uma coisa que ja notei e agora posso afirmar que a opção -SCREENSAVER:SET;OFF do WAPI.EXE não me está funcionando em WINDOWS XP. A versão do WAPI.EXE é a 1.02 e também testei a SetWinSSav(.F.) mas também não desabilitou. Mas o incrível foi que quando testei pela primeira vez (06 Agosto 22:24) funcionou, o quê seria ?

A "Desciclopédia" que o colega Eolo indicou está me servindo para melhor ainda mais o meu português.... hihihi (o quê não tem nessa INTERNET ?), procurei "http://desciclo.pedia.ws/wiki/WOP" e me deu o seguinte resultado:

"Esta páxina non ecziste!"

Essa é demais ! Agora tenho que rever tudo o que aprendí sobre a lingua portuguesa... hihihihi Valeu Vô Eolo...

MensagemEnviado: 27 Ago 2007 19:06
por Maligno
Pablo César escreveu:Olá caríssimo colega Maligno, gostei do seu novo avátar. Estamos aqui de volta após cirugia para extrair um cáculo na visícula, quase posso dizer que ja consigo andar e comer (quase) que normalmente.

Vixe! Não sabia que tinha sido operado. Por isso ficou sumido. Estimo melhoras. :)

posso afirmar que a opção -SCREENSAVER:SET;OFF do WAPI.EXE não me está funcionando em WINDOWS XP.

Funciona. Mas, com a ressalva que fiz à época: ele desabilita o protetor de tela na sessão do Windows. Ao rebootar a máquina, no retorno, o protetor de tela volta ao que era. Mas, como o programa Clipper testará o estado do protetor de tela ao ser executado, é só desabilitar de novo, que ele fica desabilitado. Aliás, deixei meu protetor de tela ativado e todos os dias executo essa função. E funciona.

A versão do WAPI.EXE é a 1.02 e também testei a SetWinSSav(.F.) mas também não desabilitou. Mas o incrível foi que quando testei pela primeira vez (06 Agosto 22:24) funcionou, o quê seria ?

Boa pergunta. Jogue enxofre nesse computador. :)))
Não estaria você, por acaso, usando a LIB atual, mas com um WAPI.EXE antigo? Essa confusão acontece. Experimente colocar no seu programa uma chamada EraseWAPI(.T.), que por default é falso.

MensagemEnviado: 27 Ago 2007 19:27
por Pablo César
Maligno escreveu:Funciona. Mas, com a ressalva que fiz à época: ele desabilita o protetor de tela na sessão do Windows.
Fiz novamente o teste só que dei um PAUSE no teste para ver a propriedade enquanto estava aquela sessão... mas nada !. Não funcionou. Vou colocar enxofre mesmo !. Quanto a versão do WAPI.EXE e a LIB, sei desse cuidado que ambos tem que estar juntos (ou ter acesso pelo path). Ja tomo esse cuidado, mas como você disse pode acontecer, aliás ja tinha baixado do seu site novamente (que via de passo, gostei da sua organização no seu site quanto ao item XBASE).

MensagemEnviado: 28 Ago 2007 16:41
por Maligno
Pablo César escreveu:Não funcionou.

Acabei de testar o WAPI.EXE do pacote que está no meu site. Liguei o protetor de tela, verifiquei e estava ligado mesmo. Em seguida, desliguei e ao verificar, vi que foi mesmo desligado. O único detalhe a observar é o que eu disse: se desligado pelo WAPI, ao reiniciar a máquina, o protetor de tela volta ao estado anterior. Mas isso não é problema. :)

MensagemEnviado: 30 Ago 2007 18:45
por Pablo César
Desculpe Maligno que não tenha retornado antes. Estes dias tive que sair a visitar clientes (novas instalações/treinamentos) e isso leva algum tempo dependendo a intimidade do cliente vs PC. E quando voltava a casa ficava exausto e com muita fome, só queria comer e dormir.

se desligado pelo WAPI, ao reiniciar a máquina, o protetor de tela volta ao estado anterior. Mas isso não é problema.
Não, certamente não é problema algum. O importante que o protetor de tela não venha influenciar na nova sessão que é iniciada com o sistema em modo console. Até mesmo poderia tão somente funcionar a desabilitação do protetor só para aquela sessão.

O meu problema está sendo em WINXP em WIN98 por incrível que pareça SEMPRE funciona. Na verdade, no meu primeiro teste, não lembro de ter testado em WINXP com sucesso. Fiz testes com diferentes protetores (default do Windows, sem senhas) no Xp, mas nada feito. Eu vinha percebendo que esta função (de desabilitar o protetor) não estaria funcionando quando em 3 clientes com WINXP não tinham desabilitado o protetor de tela. Só para nformação, meu caso tenho 2 HDs gêmeos (não particionados) em um com WIN 98 e em outro com WINXP professional. E eu escolho qual SO irei iniciar conforme eu dou a proriedade do BOOT no SETUP da máquina.

Gostaria muito saber se teve alguém que tenha testado o -SCREENSAVER:SET;OFF do WAPI.EXE ou SetWinSSav(.F.) da WAPI.LIB em condições normais. Digo normais, porque mesmo que meu caso não esteja o mesmo HD particionado e o seu caso que emula uma versão ou outra. Não sei apenas uma suposição.

MensagemEnviado: 30 Ago 2007 18:50
por Maligno
O que eu posso dizer é que no Windows98, como você já viu, funciona. E no XP também. A diferença é que, ao reiniciar o XP, o protetor volta. Mas no ato da desativação, funciona. Se você, hipoteticamente, nunca reiniciar o XP, o protetor nunca entrará. O comportamento que você observa é esse?

MensagemEnviado: 30 Ago 2007 18:59
por Pablo César
Se você, hipoteticamente, nunca reiniciar o XP, o protetor nunca entrará. O comportamento que você observa é esse?
Não, não é isso. O que eu observo que no WINXP quando executo a função ou aplicativo do WAPI para desabilitar o protetor de tela, simplesmente não desabilita em momento algum. Ja no WIN98 todas as tentativas são bem sucedidas na desabilitação do Prot.Tela.

funciona. E no XP também. A diferença é que, ao reiniciar o XP, o protetor volta.
Como foi dito, isso não seria problema o importante que naquele momento para aquela sessão o protetor de tela esteja desabilitado, não seria tão necessário que essa desabilitação venha ocorrer de forma definitiva (mesmo desligado/ligando a máquina), pois sempre iria passar pela rotina de desabilitação do prot.tela. Faço isso através de arquivo .BAT logo no início do arquivo (antes do looping, claro) e depois chamo minha aplicação.

Inclusive, vou fazer teste na linha de comando (sem ser em BATCH FILE) no WIN XP, me espere que irei bootar minha máquina e te respondo se funcionou.

MensagemEnviado: 30 Ago 2007 19:02
por Maligno
simplesmente não desabilita em momento algum

Aí a coisa complicou. Já fiz inúmeros testes no XP. Não falhou uma única vez. Boiei! :(

MensagemEnviado: 30 Ago 2007 19:12
por Pablo César
Pois é... pra mim não funciona em XP (mesmo ter feito na linha de comando) e o estranho que em 3 clientes também não funcionou. E olha que não fui eu que formatei tais máquinas. Pois caso contrário, poderiamos dizer que seria tal cópia do WINDOWS que estaria com problemas. Também não sei o quê seria, bom é saber se alguém obteve sucesso e em que Windows funcionou.

MensagemEnviado: 01 Set 2007 01:34
por Maligno
Da minha parte digo que comigo funcionou como esperado em todas as versões. Mas, ainda assim, vou pesquisar um pouco mais na Internet pra ver se encontro alguém que tenha passado por dificuldade semelhante. Volto ao assunto depois.

MensagemEnviado: 03 Set 2007 17:07
por Pablo César
Venho tendo uma semana congestionada... meus clientes decidiram me chamar uma trá do outro parece (muito deles decorrente de problema causados por hardware e novas instalações), não posso reclamar pois eu cobro a minha visita. Mas o que mais aprecio nestes momento é um pouco mais de descanso. Parecem que minha pilhas estão baixas... Até parece que eu deixei tudo acumular... mas não posso reclamar o único que não estou tendo tempo para me dedicar a programação (que é o que mais gosto de fazer). Enfim olhe só o que eu percebí o que está ocorrendo no meu XP:

- Utilizando o parâmetro GET da função SCREENSAVER para arquivo, está indicando perfeita correto. Isto é 0 (zero) quando desativado e 1 quando está ativado o protetor de telas. Porém como eu ja disse antes, a opção SET não está funcionando neste XP.

Fiz este PRG para testes:
N:=1
DO WHILE GetWinSSav()
   SETWINSSAV(.F.)
   @ 24,00 SAY N
   N++
ENDDO


- Quando executado o teste acima por 1ª vez (após ativar o protetor de tela do Windows). Este entra no looping apenas uma só vez e teoricamente executa a função SETWINSSAV(.F.) só que nas propriedades do protetor de tela do Windows fica ativo, isto é, não está desabilitando (lá na propriedades do prot.tela do Windows).
- Quando executado por 2ª ou subsequentemente, não entra no looping mas ainda fica ativo segundo as propriedades do protetor de tela.

Mas uma coisa interessante observei. Que mesmo que deixe setado como ativo qualquer protetor seja padrão do Windows ou outros (ja testei todos), o protetor de telas não entra nunca mais em funcionamento quando esperado o tempo configurado. Desliguei/liguei o PC e mesmo assim meus protetores de telas não estão funcionando. Ahh outro detalhe: eu ainda uso o Norton antivirus, que eu ainda não desinstalei e segundo ele minha máquina não possue vírus.

Muito estranho. E até agora ninguém se manifestou sobre a SCREENSAVER do WAPI para nós obter alguma referência. Vou fazer testes no meus clientes com XP, mas eu lembro que não tinha desabilitado (pelo menos aparentemente nas propriedades).

MensagemEnviado: 03 Set 2007 17:17
por Maligno
Venho tendo uma semana congestionada...

Nem me fale. Os últimos tempos têm sido difíceis mesmo. Até agora não consegui terminar de testar as modificações na impressão pelo WAPI. Mas também não posso reclamar. Não passei por nenhuma cirurgia. :)

Mas uma coisa interessante observei. Que mesmo que deixe setado como ativo qualquer protetor seja padrão do Windows ou outros (ja testei todos), o protetor de telas não entra nunca mais em funcionamento quando esperado o tempo configurado.

AHA!!! Mas foi exatamente isso o que eu quis dizer nas minhas últimas mensagens. O protetor de tela fica desligado até que o Windows seja reiniciado. Mas ao se verificar as propriedades do vídeo, ele aparece como ligado. E o que você me dizia é que ele ainda funcionava. Daí minha estranheza. Mas então estamos percebendo a mesma situação. Seu XP está igual ao meu. Menos mal. :)

MensagemEnviado: 03 Set 2007 18:01
por Pablo César
Maligno escreveu:O protetor de tela fica desligado até que o Windows seja reiniciado. Mas ao se verificar as propriedades do vídeo, ele aparece como ligado.
Então você tem a mesma situação ?. E colocando o SET como ON (através do WAPI), o seu protetor volta a funcionar ?. Pois o meu não. Nem mesmo após resetando a máquina. Estanho... meus protetores não funcionam mais...

MensagemEnviado: 03 Set 2007 18:20
por Maligno
Consigo reativar normalmente. Faça um teste:

1) Reinicie a máquina, entre na configuração do protetor de tela e certifique-se de que algum protetor está configurado. Coloque o tempo em 1 minuto. Teste o tempo. Depois de 1 minuto ele deverá ser apresentado.

2) Pelo WAPI, desative o protetor de tela e espere o tempo configurado passar. Ele não deve ser apresentado.

3) Mesma coisa, mas agora ative o protetor pelo WAPI. Depois do tempo configurado passar, ele terá de ser apresentado.

Comigo funciona perfeitamente desse jeito. A única coisa estranha, conforme já comentei várias vezes, é que na configuração do protetor de tela continua aparecendo um protetor, ao contrário do que acontece com o Windows 98.

MensagemEnviado: 04 Set 2007 07:30
por Pablo César
Incrível que pareça, mas já tinha feito esse teste. Simplesmente os protetores de telas não funcionam mais no XP. Mas nem se preocupe, que eu ainda irei formatar esta máquina assim me libero do NAV e hoje irei testar num novo cliente em Morretes e verificarei se lá funciona bem e depois posto se funcionou legal (só espero que tenham Windows XP).

MensagemEnviado: 05 Set 2007 15:13
por Adriano
Estou testando a WAPI para imprimir e não estou conseguindo, fiz o seguinte PRG de teste:

if PrintFile("#","IMP.TXT","Teste")
@ 10,10 say 'Impressao OK'
else
@ 10,10 say 'Erro na impressao'
endif
inkey(0)

Na execução deste programa só aparece ERRO NA IMPRESSÃO ou seja algo esta dando errado.

Alguem pode me ajudar a descobrir o que estou fazendo errado

Estou utilizando CLIPPER 5.2E + Blinker 6

MensagemEnviado: 05 Set 2007 15:21
por Maligno
Primeiro de tudo faça um teste simples e rápido. Forneça não só o nome, mas o caminho completo do arquivo IMP.TXT.
Se isso não resolver, precisamos identificar o erro. Na seção do IF que sinaliza o erro, inclua um ? Str(WAPIError()). Depois, já com o código do erro visualizado, veja a quê ele se refere, pesquisando o arquivo WAPI.H, que se encontra no diretório WAPI/INC.

MensagemEnviado: 05 Set 2007 16:10
por Adriano
Maligno, fiz o teste conforme sua orientação, colocando o caminho completo e continuou com problema coloquei o WAPIERROR e o resultado foi 0 (muito estranho pois pelo WAPI.H 0 = sucesso) mas a impressão não sai de forma alguma.

Fiz um outro teste e omiti o parâmetro #, deixando o comando assim: PrintFile("IMP.TXT","Teste") o resultado foi que o relatório foi impresso na LPT1

Será que vc tem alguma idéia de onde posso estar errando?

Valeu pela força.

MensagemEnviado: 05 Set 2007 16:46
por Maligno
coloquei o WAPIERROR e o resultado foi 0

Executou a função WAPIError() apenas uma vez, não é? Se executar uma segunda vez, o código anterior é apagado e ela passa a devolver zero.

Você tem uma impressora default, não tem? Se não tiver, configure uma. Se tiver, troque o "#" pelo nome da impressora. Tente assim. Depois diga se deu certo.
Aliás, qual é o seu Windows? XP?

MensagemEnviado: 05 Set 2007 17:02
por Adriano
Executei a função WAIPError apenas uma vez.

Tenho uma impressora default, já fiz um teste colocando o nome da impressora, porém também não funcionou, testei também colocando o caminho da impressora e também não funcionou, esqueci de mencionar estou utilizando Windows XP e a impressora está em rede (Novell), não sei se este é o problema.

MensagemEnviado: 05 Set 2007 17:09
por Maligno
Veja: o trabalho da função PrintFile() é apenas e tão somente transportar o conteúdo do seu arquivo de impressão para o spooler do Windows. É ele que vai direcionar sua impressão para esta ou aquela impressora, conforme você a tenha configurado. Se a impressora está compartilhada, disponível e corretamente configurada no Painel de Controle, não há motivo para o spooler não receber a impressão passada pela WAPI. Por acaso o spooler aparece na sua bandeja de ícones?
Inclusive, eu próprio, por duas ou três vezes, tive "enroscos" parecidos. A solução, se bem me lembro, foi cancelar todas as impressões do spooler, reiniciar a máquina e mandar imprimir novamente. A partir daí voltou a funcionar corretamente.

MensagemEnviado: 05 Set 2007 17:10
por Maligno
Em tempo: a impressora está configurada para usar o spooler? Ou está para impressão direta?

MensagemEnviado: 05 Set 2007 18:02
por sygecom
Adriano, vc consegue usar a impressora no windows normal ? qual a marca e modelo da impressora ?

MensagemEnviado: 05 Set 2007 18:18
por Maligno
Ele acabou de dizer que conseguiu, sem querer, imprimir na LPT1.

MensagemEnviado: 05 Set 2007 19:02
por sygecom
e qual impressora não funcionou ? marca modelo ?

MensagemEnviado: 05 Set 2007 19:20
por Maligno
Acho que a questão nem é essa. Sendo ou não "for windows", a WAPI manda a impressão pro spooler de qualquer maneira. E aí está a razão do destaque que coloquei: a WAPI não imprime nada. Ela apenas envia pro spooler. Se dali pra frente der algum problema, será um problema entre o spooler e o Windows. E o problema parece estar na dificuldade de enviar para o spooler.

MensagemEnviado: 06 Set 2007 08:10
por Adriano
A impressora é uma HP Laserjet 1320, a impressão funciona normalmante tanto via Windows quanto via DOS, confirmei na configuração da impressora e está ativado o spool.

Me parece que a impressão não foi descarregada para o Spool, visto que a função PrintFile está retornando um valor .F., o estranho é que ela retorna um valor .F. porém o código do erro é 0

MensagemEnviado: 06 Set 2007 08:42
por Pablo César
Não seria questão de configurar o formato do spool (em configuração do spool), isto é, setar para RAW ?

Eu faria primeiramente testes na linha de comando (que é mais rápido, porque não precisaria compilar e você veria os resultados tanto no arquivo como em tela (deixando a visualização da fila de impressão em modo janelado, para saber se estaria enviando ou não). E também colocaria o nome certo da impressora em que desejo imprimir (conforme o nome obtido pela função -GETDEFPRINTER:PRINTERS.TXT do WAPI.EXE

MensagemEnviado: 06 Set 2007 09:01
por Pablo César
Maligno, testei em outras máquinas XP e funcionou a desabilitação do protetor de tla do Windows, porém como foi observado (não é setado nas propriedades da tela). Mas o importante que não é ativado o protetor de telas durante a execução do sistema. Já isso é uma grande coisa.

Ahh, os meus protetores de tela no XP, estão funcionando, também de acordo. Acho que eu me precipitei a dizer que não funcionam mais os meus protetores (desculpe). Mas a função do SCREENSAVER trabalh como foi descrito, desativa e ativa (mas nas propriedades não é mudado, ao menos na versão do Windows XP) ja no WIN98 funciona e muda nas propriedades da tela (engraçado, ao final com WIN98, sempre é esperado não funcionar). Mas enfim, para mim está aprovado, me desclpe se fiz confusão e o que realmente importa é desabilitar o protetor de tela do Windows durante a sessão, assim que a WAPI como está sobre esta função, está de bom tamanho.

MensagemEnviado: 06 Set 2007 10:04
por Pablo César
Maligno, gostaria fazer mais uma solicitação (se for possível) de mais dois elementos de retorno sobre a função GETSYSTEMINFO.

Acho importante saber onde se encontra o Menu iniciar (All user e usuário vigente) para poder inserir alguma rotina de confguração na inicialização da máquina. Assim como era feito através do AUTOEXEC.BAT

Hoje eu poderia pegar a SUBSTRING (até onde começa DESKTOP) dos elementos (9,10,11 e 12) de retorno e adicionar logo após o resto do caminho na STRING de "Menu Iniciar\Programas\Inicializar" ou "MENUIN~1\PROGRA~1\INICIA~1" para indicar o caminho completo onde deve ser gravado o arquivo .LNK. Mas se tiver na WAPI mais estes elementos de retorno, irá ser com certeza mais preciso, se não for muito pedir, é claro.

MensagemEnviado: 06 Set 2007 11:15
por Maligno
Adriano escreveu:A impressora é uma HP Laserjet 1320
...
o estranho é que ela retorna um valor .F. porém o código do erro é 0

Nesta impressora ficaria bem simples mesmo. Vou fazer um programa de teste e te mandar ou subir pro meu site. Depois do almoço. Daí te aviso.

MensagemEnviado: 06 Set 2007 11:17
por Maligno
Pablo César escreveu:Mas enfim, para mim está aprovado

Que bom. Pelo menos está tudo funcionando. Eu já estava quase contratando uma mãe-de-santo pra fazer uma sessão de descarrego. :)))

MensagemEnviado: 06 Set 2007 11:21
por Maligno
Acho importante saber onde se encontra o Menu iniciar (All user e usuário vigente) para poder inserir alguma rotina de confguração na inicialização da máquina.

Ok. Vou incluir na TODO list. Aliás, já incluí também um controle de volume de som.

MensagemEnviado: 06 Set 2007 11:22
por Pablo César
Eu já estava quase contratando uma mãe-de-santo pra fazer uma sessão de descarrego.


Pois é... desculpa, colega. Parece que eu me embarralhei tanto ao ver as propriedades que pensei que nunca mais iria ver o protetor de tela (graças a Deus)... Sorry :)

Ok. Vou incluir na TODO list.
Beleza !. Obrigaduuuuu.

MensagemEnviado: 06 Set 2007 11:24
por Maligno
Pablo César escreveu:Pois é... desculpa, colega. Parece que eu me embarralhei tanto ao ver as propriedades que pensei que nunca mais iria ver o protetor de tela (graças a Deus)... Sorry :)

Não precisa se desculpar. Eu sei que isso acontece. Por isso que, às vezes, até acho que pareço chato dando um passo-a-passo tão esmiuçado e detalhista. Mas é que assim a gente acaba pegando os próprios errinhos bobos que passam despercebidos. :)

MensagemEnviado: 06 Set 2007 11:27
por Pablo César
Maligno escreveu:Por isso que, às vezes, até acho que pareço chato dando um passo-a-passo tão esmiuçado e detalhista.
Está certo você ! Quem programa e dá suporte (na verdade todos, nós) sabemos que é assim, por isso me desculpo porque até eu mesmo acreditei no erro. Mas é tão bão se livrar o protetor de telas do Windows... pois para isso eu tenho os meus protetores feito no próprio sistema que aliás acho bem mais convenientes.

MensagemEnviado: 07 Set 2007 10:00
por Maligno
Maligno escreveu:
Adriano escreveu:A impressora é uma HP Laserjet 1320
...
o estranho é que ela retorna um valor .F. porém o código do erro é 0

Vou fazer um programa de teste e te mandar ou subir pro meu site. Depois do almoço. Daí te aviso.

Pegue o programa de teste clicando aqui.
O executável já está pronto. Não precisa gerar nenhum arquivo de impressão. Apenas execute o pograma sem argumento, para imprimir uma simples frase na impressora default. Se quiser, use como argumento o nome da impressora destino. Se o nome contiver espaços, informe-o entre aspas.
Testei na minha HP-LJ1022, que é parente da sua. Funcionou de imediato. Então, teste aí e depois diga qual foi o resultado. :)

MensagemEnviado: 14 Set 2007 11:06
por Maligno
A TODO list atualizada:
  • Controle de volume do som
  • Inclusão da informação acerca do diretório "iniciar" na informação do sistema
  • Execução do WAPI no modo residente (codinome RES)
  • Bloqueio do teclado e mouse em nível global (requer RES)
  • Cancelamento de execução de WAVs (requer RES)
  • Execução de sons em lote (funcionalmente melhor com RES)
  • Apagamento seguro de arquivos (wipe file)
  • Execução de atalhos de teclado, próprios do windows (ex: Alt+Enter)
  • Criação de links para execução de programas
  • Funções de FTP: list, delete, upload, download, etc...
  • Criação de um help no estilo NG (Norton Guides)
  • Criação de um programa demo completo, com todas as opções da WAPI
  • Remover a dependência das bibliotecas CATools e NanFor

MensagemEnviado: 14 Set 2007 11:27
por Pablo César
Legal ! Você é rápido mesmo para edição (enquanto eu escrevia a mensagem lá você ja tinha feito aqui... coisa de escrivão de polícia... hihihi)

Remover a dependência das bibliotecas CATools e NanFor
Será que isto vai valer a pena ?. Sei do quanto é importante desvincular-se do uso de outra LIB, mas será que o trabalho vai valer tanto a pena, digo ?. Pensei na possibilidade de incluir parte das LIB CT e Nanfor em forma de objeto e incluir na sua LIB. Mas iria acusar duplicidade quando o programador incluir as CT e Nanfor novamente na link edição para outros fins. Ou haveria alguma forma de renomear tais funções inscritas na sua fonte nativa ?.

MensagemEnviado: 14 Set 2007 11:35
por Maligno
Pablo César escreveu:será que o trabalho vai valer tanto a pena, digo ?. Pensei na possibilidade de incluir parte das LIB CT e Nanfor em forma de objeto e incluir na sua LIB.

Sua preocupação é válida. Mas acho que vale a pena sim. Pelo menos ninguém fica dependendo da CATools (não usei a NanFor). Mas só vou mexer nisso quando tiver um bom tempo sobrando. Por ora nem penso nessa questão. :)

MensagemEnviado: 14 Set 2007 12:05
por Maligno
Aliás, em tempo: não tem relevância alguma pra quem vai utilizar a biblioteca, mas também há uma possibilidade de precisar segmentar o fonte do WAPI.C no futuro. Conforme foi passando o tempo, a oferta de funções cresceu bastante e, como se pode ver na TODO list, vai crescer muito mais. Do jeito que está não tenho qualquer problema com novas inclusões ou alterações, mas se isso se tornar incômodo, mesmo que ligeiramente, vou segmentar o fonte.

MensagemEnviado: 14 Set 2007 12:50
por Pablo César
Do jeito que está não tenho qualquer problema com novas inclusões ou alterações, mas se isso se tornar incômodo, mesmo que ligeiramente, vou segmentar o fonte.
Acho bom isso, pois considerando o modo de execução do WAPI isto poderia se tornar muito grande para executar através do RUN para aqueles que usam o RTLINK no caso e não utilizam a memória de forma mais específica com o BLINKER. Isto é, ficaria mais enxuto e mais fácil na utilização específica de cada caso. Se bem que eu guardo todas as versões do WAPI e se precisar utilizar "todas" as funções (atualmente existentes) terei como recorrer ao meu arquivo.

Obs.: lembre de corrigir aquela questão da função WINDOWS2TOP que está aparecendo resultado na tela. Eu aguardo seu proximo release para atualizar essaquestão, pois disposiciona a minha tela quando executo essa opção no meu sistema modular.

MensagemEnviado: 14 Set 2007 12:55
por Maligno
considerando o modo de execução do WAPI isto poderia se tornar muito grande para executar através do RUN

Não. Você não entendeu. A segmentação a que me referi é apenas e tão somente a separação do fonte principal em fontes separados, a fim de facilitar a manutenção. Eu disse que é algo irrelevante pra quem vai utilizar a biblioteca.

O executável por si só não mudaria um único byte se eu o segmentasse. E nem precisa se preocupar com o tamanho. Hoje ele tem apenas uns 20KB. Mais enxuto que isso, (quase) impossível. Se o RUN der pau com 20KB será por falha do Clipper.

Se eu forçar demais, ele crescerá só mais uns 10KB. Isso que estou considerando algumas idéias que você não sabe. Não adianta perguntar. Não digo o que é. :)

lembre de corrigir aquela questão da função WINDOWS2TOP

Já consertei naquele mesmo momento que você pediu. Sempre alerta! :)

MensagemEnviado: 14 Set 2007 13:10
por Pablo César
Maligno escreveu:O executável por si só não mudaria um único byte se eu o segmentasse.
Ahhh é ? Puxa o C é demais mesmo !. Então com certeza não é para se preocupar com o tamanho final do aplicativo.

Se eu forçar demais, ele crescerá só mais uns 10KB. Isso que estou considerando algumas idéias que você não sabe. Não adianta perguntar. Não digo o que é.
KAKAKA, você me faz rir... eu ainda não almocei mas estou morrendo de curiosidade.... (você faz supense de propósito !). Já sei ! Você está elaborando algo sobre a questão de impressão. E por falar disso, você tinha dito que faria alguma coisa referente a impressão parcial de arquivo e não consta no seu TODO LIST.

Maligno escreveu:
Pablo escreveu:lembre de corrigir aquela questão da função WINDOWS2TOP
Já consertei naquele mesmo momento que você pediu. Sempre alerta! :)
Como dizem os argentinos: SOS UN CAPO !

MensagemEnviado: 14 Set 2007 13:25
por Maligno
Pablo César escreveu:Já sei ! Você está elaborando algo sobre a questão de impressão.

Meretriz que deu a luz!!! Como adivinhou? :)))

E por falar disso, você tinha dito que faria alguma coisa referente a impressão parcial de arquivo e não consta no seu TODO LIST.

Não consta mesmo. Mas já está pronto. Só que tive que refazer (problema de performance) e ainda não terminei os testes (é bem complicado testar isso). Como é pro próprio cliente que me pegou pra Cristo, tenho que terminar o que ele pediu e aí terminar os testes da impressão e entregar pra ele. Depois eu libero no meu site.

Mas pelo menos aumentei a gama de recursos. Agora temos impressão total, parcial (lista de páginas), na ordem inversa, com quantidade e ainda agrupada (exemplo: se quantidade=2, pode-se imprimir 1,1,2,2,3,3 ou 1,2,3,1,2,3).

Como dizem os argentinos: SOS UN CAPO !

Espero que seja um elogio. :)))

MensagemEnviado: 14 Set 2007 13:47
por Pablo César
Maligno escreveu:Meretriz que deu a luz!!! Como adivinhou?
KAKAKA o meu arroz me espera ainda... mas sabe como adivinhei. Lembra daquela questão ComTurbante ou SemTurbante ? hihihihi Quê bom saber desse novo recurso, talvez eu até nem precise do plano B.

Agora temos impressão total, parcial (lista de páginas), na ordem inversa, com quantidade e ainda agrupada (exemplo: se quantidade=2, pode-se imprimir 1,1,2,2,3,3 ou 1,2,3,1,2,3).
Naaasssaaa ! Essa sim que é boa, muito boa. Mas que trabalheira, eihn colega ?.

Espero que seja um elogio.
KAKAKA e dá pra entender outra coisa ?. Mah como ? Tu non capice da parola CAPO ? Tu soi uno vero CAPO. Sempre em alta estima !.

MensagemEnviado: 14 Set 2007 13:55
por Maligno
Pablo César escreveu:Quê bom saber desse novo recurso, talvez eu até nem precise do plano B.

Que recurso? Você adivinhou ONDE é, mas não adivinhou O QUE é.

Naaasssaaa ! Essa sim que é boa, muito boa. Mas que trabalheira, eihn colega ?.

Se eu te contasse, com certeza você não conseguiria comer nada por 3 dias seguidos, de tanto chorar. :)))

MensagemEnviado: 14 Set 2007 14:42
por Pablo César
Maligno escreveu:Que recurso? Você adivinhou ONDE é, mas não adivinhou O QUE é.
Deixe eu aqui ver com meu turbante... Esse projeto teria a ver com esta idéia:

http://www.pctoledo.com.br/forum/viewto ... &start=150

Maligno escreveu:
Naaasssaaa ! Essa sim que é boa, muito boa. Mas que trabalheira, eihn colega ?.
Se eu te contasse, com certeza você não conseguiria comer nada por 3 dias seguidos, de tanto chorar.
Ao final de contas aqui tem mais uma prova de como nós gostamos de ser "as vezes" um pouco mais "perfeicionistas". Pois toda essa trabalhera no final de contas acaba compensando.

MensagemEnviado: 14 Set 2007 14:49
por Maligno
Pablo César escreveu:Deixe eu aqui ver com meu turbante... Esse projeto teria a ver com esta idéia:

Boa memória. Eu nem lembrava disso. Mas olhe: é só uma idéia, por enquanto. Não estou prometendo nada. E só posso adiantar que não seria com DBF.

toda essa trabalhera no final de contas acaba compensando.

Ah, sim. Sem dúvida. Não gosto de fazer nada meia-boca, nem que tenha que criar calos nas pontas dos dedos. :)

MensagemEnviado: 14 Set 2007 15:17
por Pablo César
é só uma idéia, por enquanto. Não estou prometendo nada. E só posso adiantar que não seria com DBF
Me permita uma sugestão ?. Se a sua intenção é montar um BD que possua os comando de cada impressora, então não digo nada. Mas se for como eu discriminei na minha sugestão ao MarcosV de poder passar parâmetros de alguma forma (ora seja também por um tipo de TAG mais elaborado) que possibilite a escolha da fonte, tamanho e modo (daí seria genial) porque iria imprimir em qualquer impressora e em vários tamanho de fontes e estilo sem precisar montar um BD de impressoras e seus comandos.

MensagemEnviado: 14 Set 2007 20:09
por Maligno
Eu montar um arquivo com os comandos de várias impressoras. Mas nem morta! :)))

Se eu for fazer, só vou montar a estrutura para que o usuário faça isso, crie suas tags, comandos, etc. O WAPI só interpretaria, como um robozinho. :)

MensagemEnviado: 19 Set 2007 17:34
por Pablo César
Que bom, fico no aguardo essa nova função de impressão e formatação de imrpessão.

Agora retornando a um assunto antigo, você viu o tópico:
http://www.pctoledo.com.br/forum/viewtopic.php?t=658

Não ví você quase em todo o dia (acho que você deve estar bem ocupado), mas desculpe reiterar este assunto (caso você o tenha lido) mas que fiquei empolgado saber que ao menos apara o WIN98 e 95 funciona perfeitamente o Z.COM pena que em XP não funciona... buahhh

MensagemEnviado: 19 Set 2007 19:03
por Maligno
Vi o tópico, baixei, mas não testei. E, realmente, hoje o dia estava meio tumultuado. Fui correr atrás do din-din. Felizmente, peguei o desalmado pelo rabo. :)

MensagemEnviado: 21 Set 2007 10:14
por clodoaldomonteiro
Malígno!

Tentei usar ontem a fonção da WAPI que roda um WAV como se segue abaixo:

mTime:=left(time(),2)
IF MTIME$'00,01,02,03,04,05,06,07,08,09,10,11'
PLAYWAVE("bomdia.wav")
ELSEIF MTIME$'12,13,14,15,16,17'
PLAYWAVE("boatarde.wav")
ELSEIF MTIME$'18,19,20,21,22,23'
PLAYWAVE("boanoite.wav")
ENDIF

... e mostra o seguinte erro:
POEHORA (0) Unrecoverable error 667: Eval stack fault

A função poehora() é uma função do GASpro para mostrar um relógio contando as horas na tela.

Eu uso o GASPRO para gerar meus sistemas, depois altero muita coisa no braço.

Você tem alguma dica para esse erro?

MensagemEnviado: 21 Set 2007 10:46
por Pablo César
Clodoaldo, eu uso algumas funções do GAS, não tenho problemas com a compilação e não lembro de nenhuma função com esse nome de POEHORA(), você poderia listar caso seja uma função própria sua (mas por favor utilizando a opção de edição do forum com CODE), assim poderemos ver o que estaria de errado. Você ja conhece a função SHOWTIME da CT.LIB ?

O Maligno ainda vai elaborar uma função que vai viabilizar a emissão continua (ou em lote) dos arquivo .WAV. No entanto, seria interessante reunir números, saudações e algumas respostas básicas e gostaria de ver a qualidade de esses seus WAV, Clodoaldo

MensagemEnviado: 21 Set 2007 14:07
por Maligno
Pelo nome da função, imagino que não seja do GAS. Mas se está dando uma mensagem "Eval Stack Fault", é por quê esta função (ou alguma outra) pode estar fazendo chamadas recursivas e estourando a capacidade da pilha. Sugiro então que você aumente o espaço para pilha, incluindo o comando STACK <bytes>. O valor default é 6148. Comece com 10240 pra ver que bixo dá. Se passar, ótimo. Senão, vá aumentando.
Ou, se for possível consertar algum possível erro nessa função, conserte. Seria melhor.

MensagemEnviado: 21 Set 2007 14:29
por Pablo César
pode estar fazendo chamadas recursivas e estourando a capacidade da pilha. Sugiro então que você aumente o espaço para pilha, incluindo o comando STACK <bytes>.
Pensei nisto, mas logo imaginei que se antes funcionava por quê agora não ?. Fois por tal razaão que solicitei ao Clodoaldo que postasse o seu código POEHORA que talvez tenha algum erro e ao mesmo tempo sinalei para o SHOWTIME da CT.LIB que é muito usada inclusive eu mesmo a utilizo e nunca tive problemas dessa natureza mesmo usando a WAPI.LIB juntas.

MensagemEnviado: 21 Set 2007 15:53
por clodoaldomonteiro
Pablo César!
A função POEHORA() está na lib do GASpro, mas não tem comentário dela no NG do GAS. Ela serve para colocar um relógio em tempo real na tela.
A lib GAS tem várias funções que não estão no NG, eu descobri várias funções usando o Valkiria5.0.

Malígno!
Fui a ajuda do windows XP e lá diz que a variável de ambiente STACKS pode ser representa assim:
stacks=n,s
onde: "n" varia de 8 a 64, e "s" vai de 32 a 512.

Eu testei várias configurações e ainda não deu certo, continua dando a mesma menssagem de erro.

Daí tirei a função POEHORA() para ver no que dava e agora aparece o seguinte erro:
" RESTSCR (0) Unrecoverable error 667: Eval stack faults "
... essa função restaura telas gravadass previamente.

Queria saber se a lib WAPI é compatível com a rotina de programação do GASpro.

Obrigado pela atenção.

MensagemEnviado: 21 Set 2007 16:50
por Maligno
Fui a ajuda do windows XP e lá diz que a variável de ambiente STACKS

Desculpe. Esqueci de mencionar: eu estava me referindo ao BLinker.

Queria saber se a lib WAPI é compatível com a rotina de programação do GASpro.

De momento, não vejo por quê haveria qualquer conflito. A não ser que uma utilize um nome de símbolo que a outra também utilize, o que eu acho difícil.

MensagemEnviado: 21 Set 2007 19:05
por Pablo César
clodoaldomonteiro escreveu:A função POEHORA() está na lib do GASpro, mas não tem comentário dela no NG do GAS.
Olha só não sabia. Valeu pelo esclarecimento.

Ela serve para colocar um relógio em tempo real na tela.
Tentou com a função SHOWTIME da CT.LIB ?

" RESTSCR (0) Unrecoverable error 667: Eval stack faults "
... essa função restaura telas gravadass previamente.
Será que o problema não está na utilização de várias SAVESCREEN ? Salvar as muitas telas consome muita memória, talvez esteja ali seu problema. Utilizo o CLD e verificou quantas variáveis estão vigentes ?

Mas tenho a grande impressão que não tem a ver com WAPI. Por acaso você estaria o RTLINK ou BLINKER ?. O WAPI.EXE estaria no diretório corrente da sua aplicação ?

TODO LIST

MensagemEnviado: 21 Set 2007 19:42
por Pablo César
Maligno escreveu:A TODO list atualizada:
  • Controle de volume do som
  • Inclusão da informação acerca do diretório "iniciar" na informação do sistema
  • Execução do WAPI no modo residente (codinome RES)
  • Bloqueio do teclado e mouse em nível global (requer RES)
  • Cancelamento de execução de WAVs (requer RES)
  • Execução de sons em lote (funcionalmente melhor com RES)
  • Apagamento seguro de arquivos (wipe file)
  • Execução de atalhos de teclado, próprios do windows (ex: Alt+Enter)
  • Criação de links para execução de programas
  • Funções de FTP: list, delete, upload, download, etc...
  • Criação de um help no estilo NG (Norton Guides)
  • Criação de um programa demo completo, com todas as opções da WAPI
  • Remover a dependência das bibliotecas CATools e NanFor
Neste ultimo TODO LIST, não estaria faltando aquela função de verificação e retorno em arquivo do modo em que exibida a sessão ?.

Entendo que você iria ver ainda se é viável, mas seria muito estimulador ver mais esse item como mais uma possível função. A outra questão também foi que você iria ver a possibilidade sobre DDE ou OLE com a WAPI. Revisando ainda mais para trás temos também a promessa de:

- Cancelamento de jobs de impressão do spooler
- Execução no TRAY para verificação de arquivo em referência a sua msg ou esta outra msg . Não sei se isto está incluso no primeiro item do TODO LIST acima descrito ?

Desculpe a minha insistência, pareceu que estaria te cobrando (e não tem cómo), mas fiz com o intuito de recompilar o que já foi assimilado. Sendo assim espero que sirva para manter o TODO LIST atualizado e mais completo. Então dessa forma todos nós seremos beneficiados.

MensagemEnviado: 21 Set 2007 20:10
por Maligno
Neste ultimo TODO LIST, não estaria faltando aquela função de verificação e retorno em arquivo do modo em que exibida a sessão.

Uma possibilidade (remota) que ainda está pendente. Mas nem precisa constar na lista. Não consigo esquecer disso nem que eu queira. Até pesadelo tenho. :)))

- Cancelamento de jobs de impressão do spooler

Isso eu não coloquei de propósito. Achei melhor deixar o cancelamento a cargo do usuário, ao invés de você oferecer isso a ele. Além do quê, cancelamento de job de impressão é coisa tão esporádica que nem compensa queimar a pestana com isso.

- Execução no TRAY para verificação de arquivo

Repare que a idéia é de um tipo de scheduler. Não coloquei na lista por quê não passa de uma idéia. Como ele depende do modo residente, vou analisar isso só no fim dos finalmentes. Mas também não é crítico, não é essencial. Talvez eu nem faça. :)

- Impressão parcial e com formatação

O esquema que eu imaginei é bem complicado e trabalhoso, dada a flexibilidade que eu acho que deveria ter. Mas também é só uma idéia. Fica pra depois.

Desculpe a minha insistência, pareceu que estaria te cobrando

Tudo bem. Eu entendo. É que você bem sabe, como eu já disse antes: o din-din vem em primeiro lugar. Em outubro as coisas voltam aos eixos e ficará mais fácil e rápido esvaziar essa lista. :)

MensagemEnviado: 21 Set 2007 20:26
por Pablo César
Maligno escreveu:
Cancelamento de jobs de impressão do spooler
Isso eu não coloquei de propósito. Achei melhor deixar o cancelamento a cargo do usuário, ao invés de você oferecer isso a ele.
Uê, esta decisão sua, é recente ?. Eu tenho alguns casos de impressão que ainda utilizo o USB do Heveraldo (que imprime em forma gráfica) e quando quero cancelar a impressão me dá uma trabalheira. Sem contar o trabalho que dá esvaziar o spool de impressão que ja está na própria impressora. Pensei que incluindo essa opção seria mais rápido a eliminação do job no spooler.

Maligno escreveu:
- Execução no TRAY para verificação de arquivo
Repare que a idéia é de um tipo de scheduler. Não coloquei na lista por quê não passa de uma idéia. Como ele depende do modo residente, vou analisar isso só no fim dos finalmentes. Mas também não é crítico, não é essencial. Talvez eu nem faça.
Lembra que esta idéia surgiu na realização de mesnagens BORDACASTING ?. A principal idéia seria verificação de determinado arquivo e execução de uma BATCH pelo ouvidor no tray com o WAPI.

o din-din vem em primeiro lugar. Em outubro as coisas voltam aos eixos e ficará mais fácil e rápido esvaziar essa lista.
Mas é claro colega. Pagar as contas é primordial e eu aqui estou demandado mais trabalho para você... (não ligue para a minha anciedade). Temos que ficar agradecidos a você por esta oportunidade única.

MensagemEnviado: 21 Set 2007 22:26
por Maligno
Pensei que incluindo essa opção seria mais rápido a eliminação do job no spooler.

Pode acreditar, o trabalho de cancelar pelo seu programa seria o mesmo. Ou seja, sem garantia de que cancelaria de fato. É a mesma dificuldade que cancelar pelo spooler, justamente por quê se usa a interface do spooler. Seria trocar 6 por meia dúzia, mas com um agravante: fazendo pelo programa talvez o usuário nem perceba que o cancelamento não foi feito.

Lembra que esta idéia surgiu na realização de mesnagens BORDACASTING?. A principal idéia seria verificação de determinado arquivo e execução de uma BATCH pelo ouvidor no tray com o WAPI.

Broadcasting. Sim, isso também é viável, em conjunto com o scheduler. Aliás, isso me lembra que há alguns anos eu tinha um projeto de compartilhamento de tarefas entre máquinas distintas. Algo totalmente factível, SE eu levar adiante essa característica. Muito embora, eu próprio, no presente momento, não tenha mais a intenção de usar. Mas falar disso agora é colocar a carroça na frente dos bois. É melhor deixar para o momento oportuno. :)

MensagemEnviado: 21 Set 2007 22:56
por clodoaldomonteiro
Malígno!
Quando eu compilo o sistema só com a lib WAPI.LIB aparece o seguinte erro:
RMAKE 1.4 Copyright (c) 1989-1993 Computer Associates International, Inc.
RMAKE=/XS8000
BLINKER @ESTOQUE.LNK
__ __
(«») («») BLINKER DOS Extender and Windows Linker 7.00

___ Blink and you'll miss it !!

Copyright (c) Assembler Software Manufacturers, Inc. 1990-2002
All Rights Reserved. Serial # BR-055934. Fax (804) 784-2357.

BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'DIRCHANGE' : unresolved external
BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'DIRMAKE' : unresolved external
BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'DIRNAME' : unresolved external
BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'DISKNAME' : unresolved external
BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'RAND' : unresolved external
BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'RANDOM' : unresolved external

BLINKER : 0 Warning error(s), 6 Fatal error(s)

ESTOQUE.EXE (not created) (0.2 seconds)
Error RMAKE/R2001 Exit 1: 'BLINKER @ESTOQUE.LNK'


... daí eu coloco a CT.LIB e compila legal, mas na execução do sistema aparece o seguinte erro:

BLX286 : 1313 : exception error 0D : general protection fault, code = B800h

Active host is DPMI (v7.00 iP? 15360 Kb)

Reg Value Limit Base Flags Segment Module File
CS 023F 02FD 02A24264 FB00 08 ESTOQUE C:\...TOQUE\ESTOQUE.EXE
DS 02A7 FFFF 02996618 F300 15 ESTOQUE C:\...TOQUE\ESTOQUE.EXE
ES 038F 5FFF 02A26664 F300 ****
SS 02A7 FFFF 02996618 F300 15 ESTOQUE C:\...TOQUE\ESTOQUE.EXE

[Code byte CS] 17 83 E9 06 89 0E 70 17 [IP] 8E C3 33 FF B4 FE CD 10 8C C3

[Registers] AX=0003 BX=B800 CX=03D4 DX=E49A CS:IP=023F:01CA
SI=5056 DI=B39E BP=B354 SP=B344
FL=3206 NV UP EI NT PL NZ NA PE NC

[Stack value SS] 023F 017F 801C 038F B39E B354 02A7 5003 B354 018D 023F 3246
[SP] 0001 25A6 0247 0000 B39E 5056 B39E 0082 B35C 203C 0247 0000

[Stack frame SS] B354 018D 023F 3246 0001 25A6 0247 0000 B39E 5056 B39E 0082
[BP] B35C 203C 0247 0000 B366 2605 0247 0000 452E 0000 B5C6 021F


... bom, quando eu comprei o pagote de arquivos da GAS Informática para usar os índices NSX, veio um arquivo .obj e umas libs, dentre elas a PRO_EXO, bom ai eu substitui a CT.LIB pela PRO_EXO.LIB no arquivo .LNK...
... ai ele mostra o seguinte erro quando eu abro um arquivo qualquer no browser ou quando edito qualquer registro para getar campos, na hora de filtrar uma sequencia de registros, veja:

(b)INDTMP (0) Unrecoverable error 650: Processor stack fault


... dessa vez ele deu erro numa função que cria um índice temporário, mas outras vezes deu erra na função RESTSCR() e POEHORA(), vai depender do valor da variável STACK no script do blinker, quanto menor o sistema vai mais longe, ou seja, é inversamente proporcional, e ainda assim quebra a execução do sistema.

... pode ser que meu arquivo script do blinker, o ESTOQUE.LNK, esteja errado, veja ele:

BLINKER EXECUTABLE EXTEND
BLINKER EXECUTABLE COMPRESS 1
BLINKER INCREMENTAL OFF
BLINKER OVERLAY UMB ON
BLINKER OVERLAY OPSIZE 40
STACK 150
BLI EXE CLI //F:101 //DYNF:8 //SWAPK:65535 //SWAPPATH:"C:\TEMP" //TEMPPATH:"C:

OUTPUT ESTOQUE.EXE

BEGINAREA
FI ESTOQUE
FI NOTAS
FI SAIDAS
FI PRO_01F9
FI EST_FUN2
FI EST_OUTR
ENDAREA

LIB \GASPRO40\GASP52PM, DBFNSX, BLXCLP52
LIB WAPI
//LIB CT
LIB PRO_EXO


Posso mandar prá ti todo esse projeto e as libs para que tu tenha uma melhor visualização desse erro.

Desde já, agradeço a atenção.

MensagemEnviado: 22 Set 2007 00:54
por Maligno
BLX286 : 1313 : exception error 0D : general protection fault, code = B800h

Seu sistema está tentanto acessar diretamente a RAM de vídeo, o que não se pode fazer quando o programa roda em modo protegido. Troque a CT.LIB (modo real) pela CTP.LIB (protegido).

substitui a CT.LIB pela PRO_EXO.LIB

Não conheço essa LIB, mas eu, particularmente, não faria isso. Mas se assim dá erro de pilha, o que se pode fazer é aumentar o espaço da pilha no script do BLinker, pelo comando STACK. Eu vi que você já fez isso, mas você informou 150 bytes. O valor default é 6148. Você diminuiu.

MensagemEnviado: 22 Set 2007 16:14
por clodoaldomonteiro
É, realmente tem uma funfão de tratamento de vídeo, vou tirar ela prá ver o que acontece.

Link de sistema gerado em GAS usando o NODISIMP.
http://suportegas.com.br/portal/downloa ... ST_USB.ZIP

Link do sistema em GAS tentando usar a WAPI.
http://suportegas.com.br/portal/downloa ... STOQUE.ZIP

MensagemEnviado: 22 Set 2007 19:09
por Maligno
Desculpe. Mas pra mim não vai dar pra baixar e testar nada. Estou sem tempo algum. :)

MensagemEnviado: 22 Set 2007 19:24
por sygecom
Clodoaldo, abra um novo post sobre o seu problema...

MensagemEnviado: 22 Set 2007 19:36
por clodoaldomonteiro
Foi mal, num quis ofender.

MensagemEnviado: 22 Set 2007 21:10
por Maligno
Não ofendeu em nada. E se você tiver alguma questão relacionada à WAPI, pode postá-la aqui mesmo, se quiser.

MensagemEnviado: 24 Set 2007 01:38
por Maligno
Maligno escreveu:O valor default é 6148. Você diminuiu.

Tentou aumentar o valor de STACKS no script do BLinker? Ficou no mesmo?

MensagemEnviado: 24 Set 2007 23:07
por clodoaldomonteiro
Olá!
Tava tentando tocar .WAV com a WAPI mais da um erro de STACK FULL e resolvi o problema com o aplicativo WAV.EXE encontrado no site http://www.powerbasic.com/files/pub/pbwin/tools/, ficou rápido e não deu erro nenhum.

Valeu a atenção de todos.

MensagemEnviado: 24 Set 2007 23:19
por Maligno
Seria equivalente a desconsiderar a WAPI.LIB e executar diretamente o utilitário:

WAPI.EXE -PLAYWAVE:ARQ.WAV,

com a vantagem de também poder reproduzir os sons do sistema. :)

MensagemEnviado: 24 Set 2007 23:27
por clodoaldomonteiro
hum! não lembrei disso.
É que eu tava cego tentando achar uma lib para fazer isso e nem lembrei que a WAPI dá essa opção.

Valeu a dica.

MensagemEnviado: 24 Set 2007 23:35
por clodoaldomonteiro
E dá prá rodar MP3?

MensagemEnviado: 25 Set 2007 01:05
por Maligno
E dá prá rodar MP3?

Não do jeito que a WAPI está. Teria que ser utilizado outro recurso, ou dependente do Windows Media Player ou algo mais complexo. A idéia era fazer algo simples, com WAV apenas. :)

MensagemEnviado: 25 Set 2007 01:07
por Maligno
É que eu tava cego tentando achar uma lib para fazer isso e nem lembrei que a WAPI dá essa opção.

A única coisa que fica devendo pra esse programa em VB é o cancelamento de som. Não que seja essencial. Até por quê, normalmente, os WAVs reproduzidos são pequenos. De qualquer forma, isso também está nos planos.

MensagemEnviado: 29 Set 2007 15:26
por ANDRIL
Maligno, o WAPI tem função para verif o que esta no Spooler do Windows, ou seja, uma listagem dos processos pendentes p/ impressao.

Pergunto por algum tempo atras acompanhei a discussao sobre a WAPI e inclusive baixei o wapi_v1.02 e n encontrei nenhuma funcao relacionada a isso.

Eu precisava apenas da listagem, o cancelamento nem era necessario.

Onde consigo a versao mais recente do WAPI?

Ate mais,

MensagemEnviado: 29 Set 2007 15:51
por Maligno
Maligno, o WAPI tem função para verif o que esta no Spooler do Windows, ou seja, uma listagem dos processos pendentes p/ impressao.

Não tem. A versão 1.02 é a última. Mas vou dar uma pesquisada a respeito da possibilidade de incluir isso. Volto ao assunto depois. :)

MensagemEnviado: 04 Out 2007 17:24
por Sergio_ASSilva
Maligno, nao estou conseguindo imprimir com a funcao PrintFile() em uma impressora HP 1020, mandei imprimir o relatorio fica na fila de impressao com o status imprimindo. quando desligo e ligo a impressora desaparece. estou usando WIN 98 e o PRG e este:

FUNCTION MAIN()
PRINTFILE("#","TESTE.TXT")
RETURN


compilando clipper teste /n
linkando blinker fi teste li wapi,ct


O que pode esta acontecendo ?


Grato

Ségio

MensagemEnviado: 04 Out 2007 18:05
por Maligno
Minha impressora é prima da sua (1022) e já passei por esse problema umas 2 ou 3 vezes. Não consegui explicar. De repente resolveu imprimir normalmente. Imprimi com e sem códigos HP/PCL5e e funcionou.

Mas você chegou a observar o tamanho do arquivo a imprimir? Note um detalhe: a função da WAPI não é imprimir, mas repassar o conteúdo da sua impressão para o spooler, byte a byte, sem qualquer tradução (RAW). Se o spooler aparece com um arquivo cujo conteúdo é maior que zero, significa que a WAPI cumpriu sua função corretamente. Daí pra frente, é coisa do spooler. Infelizmente sobre ele não tenho como precisar o que acontece. Faz parte dos mistérios do Windows. O melhor que posso dizer é que seu código eu já testei e funcionou.

MensagemEnviado: 04 Out 2007 18:34
por Sergio_ASSilva
Maligno, fiz os teste com USB e foncionou mas quando tento imprimir com prinfile da wapi nao consigo, a impressora da inicio os leds ficam piscando depos apagam e fica na fila de impressao.

MensagemEnviado: 04 Out 2007 18:42
por Maligno
Experimente com o demo que tenho no meu site. Clique aqui pra baixar. A sintaxe é TESTE [<printerName>]. Sem o nome da impressão, ele fará exatamente como o pedaço de código que você mostrou acima. Aliás, já tem o EXE pronto. É só executar.

MensagemEnviado: 05 Out 2007 08:36
por Sergio_ASSilva
Obrigago Maligno pela atencao, baixei o exemplo e fiz o teste em dois computadores o de casa e o do trabalho e nao funcionou a impressora é acionada fica o arquivos na fila de imprressao com o status imprimindo, tambem nao imprime nada ate ser deligada e ligada novamente.


Grato


Sérgio Augusto

MensagemEnviado: 05 Out 2007 08:39
por Maligno
O problema poderia estar na instalação da impressora? Eu tentaria reinstalar. Ou pelo menos dar uma conferida na configuração dela. Muito embora funcione em outro programa.

Aliás, acabei de refazer o teste com o ZIP que indiquei e funcionou novamente, como esperado.

MensagemEnviado: 05 Out 2007 10:29
por ANDRIL
Maligno tbem nao consegui imprimir via WAPI.EXE e a LIB numa Epson Styllus C20UX porta USB, Win XP.

Notei que entra o documento no Spooler e as luzes da impressora ficam piscando como se houvesse falha. Ja configurei ela p modo RAW, mais continua o mesmo.

Ja com o utilitario USB.EXE ou PRINTER.EXE consegui normalmente. Notei que entra o documento no Spooler e é direcionado rapidamente à impressora.

Onde sera que esta a diferença????

Ate+,

MensagemEnviado: 05 Out 2007 10:39
por Maligno
Onde sera que esta a diferença????

Essa é uma excelente pergunta. O pior dessa história que é não dá problema comigo. Se desse erro seria uma maravilha. Agora, como corrigir um erro que eu não conheço? :)
E eu estou com essa mesma WAPI imprimindo normalmente no cliente em Epson matricial e HPs laser e deskjet.

A única coisa que eu posso fazer é pedir a alguém o seguinte favor: montar um texto pequeno, que normalmente não imprime pela WAPI, reconfigurar a impressora para direcionar a impressão para um arquivo, imprimir pela WAPI e me mandar esse arquivo. Aí eu analiso o conteúdo e tento descobrir alguma "anomalia". Se possível em HP LaserJet, que é igual a que eu tenho aqui. Alguém pode me fazer esse favor? Se afirmativo: news#buzinello.com (troque o #). :)

MensagemEnviado: 05 Out 2007 11:05
por Pablo César
Não querendo empiorar a situação, mas lembra Maligno que eu também relatei problemas com HP D1300 USB. Me permita fazer uma dedução: eu acho que o problema todo está nas impressoras USB. Como você mesmo falou, que a função PRINTFILE da WAPI coloca a impressão apenas no spooler mas é que são vários os modelos que não estão dando certo e o engraçado que com o USB e acredito USBPRINT do Marcos também dá certo. Por isso acho que haveria necessidade de revisar a questão toda quando forem impressoras USBs. Digo isto também porque na minha LX-300 nunca tive problemas ao executar pelo WAPI.

Se afirmativo: news#buzinello.com (troque o #).
Não entendí direito sua colocação. news#buzinello.com seria o quê ?. O que eu entendí é que subtituisse o 1º parametro onde coloca-se o nome da impressora o que comumente é colocado "#" para identificar a impressora padrão. Mas esse teste eu ja fiz e não resultou em nada. Quanto a impressoras LASER, eu não possuo nenhuma aquela impressora que mencionei (HP D1300 USB) foi emprestada de um cliente.

MensagemEnviado: 05 Out 2007 11:21
por Sergio_ASSilva
Maligno, no exemplo que vc fez tem um parametro o cPrinter como devo digitar no prompt ? teste <enter> ou teste + alguma informacao ?

Grande Abraço

Sérgio

MensagemEnviado: 05 Out 2007 11:28
por Pablo César
Sergio, esse TESTE.EXE do Maligno pede para você chamar o TESTE.EXE com parâmetro que seria o nome da impressora (conforme está sendo reconhecida pelo WAPI) ou apenas pelo caracter "#" que indicaria a impressora padrão.

Exemplo 1, faça:

WAPI -GETPRINTERS:IMPS.TXT
// leia agora o IMPS.TXT e veja como está cadastrada a impressora em questão
TESTE "Epson LX-300" // No meu caso é assim que aparece após ler o arquivo IMPS.TXT

Notar que neste caso (quando contém espaço) no parâmetro deve estar englobado entre aspas. Obedecendo as regras "UNIVERSAL" de parametrização.

Exemplo 2, faça:

TESTE #


É dessa forma que você pode fazer testes com o TESTE.EXE do Maligno. Favor reportar resultados.

MensagemEnviado: 05 Out 2007 12:00
por Sergio_ASSilva
Pablo, testei as duas formas e nao imprimiu, o primeiro comando funcionou e gerou o arquivos com essa informacao - 1,HP LaserJet 1020,USB001.


Grato

Sergio

MensagemEnviado: 05 Out 2007 12:00
por Maligno
Por isso acho que haveria necessidade de revisar a questão toda quando forem impressoras USBs.

A minha impressora, onde tudo funciona, é USB: HP Laserjet 1022. Nos clientes, só não é USB a Epson matricial. O resto é USB. Em todas funciona normalmente. Daí que comentei que o *pior* de tudo é que tudo funciona. Se não funcionasse comigo, o problema estaria resolvido. :)

Não entendí direito sua colocação. news#buzinello.com seria o quê ?

É o meu endereço de eMail. Onde estiver # troque por @. :)

MensagemEnviado: 05 Out 2007 12:03
por Maligno
Maligno, no exemplo que vc fez tem um parametro o cPrinter como devo digitar no prompt ? teste <enter> ou teste + alguma informacao ?

Neste exemplo a sintax é TESTE [<printerName>]. Ou seja, se quiser a impressora default, apenas execute o programa. Caso contrário, informe o nome da uma impressora qualquer que esteja cadastrada no seu Windows. Ex: TESTE "HP LaserJet 1020". Se o nome da impressora contiver espaços, deve estar entre aspas.

MensagemEnviado: 05 Out 2007 12:16
por Pablo César
Maligno escreveu:O resto é USB. Em todas funciona normalmente. Daí que comentei que o *pior* de tudo é que tudo funciona.
Desculpe falar isto, pois é apenas uma simples dedução. Pois em todos esses casos que não funcionou com o WAPI, foram USB (não tem nenhuma reclamação quando a paralelas). Quem sabe alguns modelos exigem alguma propriedade extra na porta onde identifica como USB001, USB002 ??

Sergio escreveu:gerou o arquivos com essa informacao - 1,HP LaserJet 1020,USB001
Então faça o teste digitando:

TESTE "HP LaserJet 1020"


E teoricamente irá imprimir: MARIA TINHA UM CARNEIRINHO E SEU PELO ERA BRANCO COMO A NEVE

MensagemEnviado: 05 Out 2007 12:25
por Maligno
Sergio_ASSilva escreveu:Obrigago Maligno pela atencao, baixei o exemplo e fiz o teste em dois computadores o de casa e o do trabalho e nao funcionou a impressora é acionada fica o arquivos na fila de imprressao com o status imprimindo, tambem nao imprime nada ate ser deligada e ligada novamente.

Aliás, você poderia me fazer um favor? Usando esse mesmo programa, do jeito que está, coloque sua impressora laser como impressora padrão, reconfigure para ela direcionar a impressão para um arquivo e execute esse mesmo TESTE.EXE, que eu já sei que não funciona com você. Aí me envie o arquivo pro email news#buzinello.com (troque o # por @). Assim, eu já sei qual é o conteúdo e posso analisá-lo. Não sei se vai adiantar muito, mas é alguma coisa. :)

MensagemEnviado: 05 Out 2007 12:26
por Maligno
Quem sabe alguns modelos exigem alguma propriedade extra na porta onde identifica como USB001, USB002 ??

Não deveria e nem acho que falte qualquer configuração. E o direcionamento para esta ou aquela porta é função do Windows. Além do mais, a impressora do Sérgio, onde não funciona, é a HP1020. A minha, também USB, é a HP1022. Nela funciona sem problema.

MensagemEnviado: 05 Out 2007 12:56
por Pablo César
Não sei se isto irá ajudar, mas vale a pena revisar todos estes procedimentos. Porque imprimir em USB continua sendo um problema e as vezes o problema está diante de nós e não precebemos. Vale a penas checar:

http://h10025.www1.hp.com/ewfrf/wc/fast ... eUrl=true&

MensagemEnviado: 05 Out 2007 13:28
por Pablo César
Maligno escreveu:E o direcionamento para esta ou aquela porta é função do Windows.
Não sei lhe dizer colega, pelo pouco que lí percebí que há duas formas de se mandar a impressão pela USB e pelo driver da impressora. Nesse caso eu não tenho como avaliar, mas encontrei material que provavelmente venha a ser útil:

http://www.codeguru.com/forum/archive/i ... 35886.html
http://www.usb.org/developers/devclass_ ... rint11.pdf
http://blog.peter.skarpetis.com/?s=USB

Gostaria de saber se o WIN32PRN que o USB utiliza, faz algum chamado para usbprint.sys ? Claro isto só serviria como referência. Talvez eu esteja enganado ao fazer referência do acesso direto. Mas quem sabe seja a melhor saída para impressão em USB ?

MensagemEnviado: 05 Out 2007 14:53
por sygecom
Melhor saida para impressão USB é fazer um App pequeno com o xharbour algo facil...qualquer um pode fazer para suas nescessidade e correr pro abraço...

MensagemEnviado: 05 Out 2007 14:58
por Maligno
Gostaria de saber se o WIN32PRN que o USB utiliza, faz algum chamado para usbprint.sys ?

Não que eu saiba. Mas é quase certo que não. Vou ver isso depois, com mais calma. Eu quero antes disso, ver o arquivo que vão me enviar. Se o Sérgio puder, claro. Ele também deve ter os afazeres dele.

MensagemEnviado: 05 Out 2007 15:03
por Pablo César
Maligno escreveu:Eu quero antes disso, ver o arquivo que vão me enviar. Se o Sérgio puder, claro.
Mas Maligno, você acredita que esse arquivo de impressão possa a vir a conter alguma coisa que impossibilite o spooler a acionar a impressão ? Ou na verdade você quer o arquivo de retorno ?. Porque você não especificou quais dos arquivos.

MensagemEnviado: 05 Out 2007 15:19
por Sergio_ASSilva
Maligno, desculpe mas nao consegui configurar a impressora para direcionar a impressao para arquivo.


Sérgio

MensagemEnviado: 05 Out 2007 15:21
por Maligno
Porque você não especificou quais dos arquivos.

Especifiquei sim. Eu quero o arquivo gerado pelo spooler, depois de reconfigurada a impressora para direcionar a saída para arquivo.

MensagemEnviado: 05 Out 2007 15:25
por Maligno
Sergio_ASSilva escreveu:nao consegui configurar a impressora para direcionar a impressao para arquivo.

Vou te dar o caminho de como é no XP. Se usa Win98, é mais ou menos parecido. Estou sem meu VMware instalado.
Pelo Painel de Controle, abra o quadro de propriedades da impressora. Clique na aba chamada "Portas". Na relação de portas deve ter algo como "FILE: ... Imprimir em arquivo". Marque esta opção, clique em OK e manda ver. :)

MensagemEnviado: 05 Out 2007 15:30
por Pablo César
Maligno escreveu:
Porque você não especificou quais dos arquivos.

Especifiquei sim. Eu quero o arquivo gerado pelo spooler, depois de reconfigurada a impressora para direcionar a saída para arquivo.
Em outras palavras... você está pedindo para capturar a impressão em arquivo (pelo próprio Windows). Será interessante ver o seu conteúdo, visto que não há impressão alguma. Mas tudo bem vale a pena checar.

MensagemEnviado: 05 Out 2007 15:50
por Sergio_ASSilva
Já mandei pro seu e-mail !

Grato

MensagemEnviado: 05 Out 2007 15:56
por Maligno
Chegou. Vou ver e retorno assim que puder. :)

MensagemEnviado: 05 Out 2007 16:07
por Maligno
Fiz também o mesmo redirecionamento. Imprimi pelo programa demo TESTE.EXE e vi que o arquivo gerado pela minha impressão ficou idêntico ao seu, byte a byte. Em seguida mandei o seu arquivo direto pelo WAPI.EXE e imprimiu na hora, como deveria ser.

Então, volto à pergunta anteriormente feita: tentou reinstalar a impressora? E acrescento: qual é o seu Windows? Qual o número de versão? Tem algum service pack instalado?

MensagemEnviado: 05 Out 2007 16:41
por Sergio_ASSilva
Maligno, Reinstalei a impressora fiz os teste -nao imprime, o So é Windows 98 - 4.10.2222A, quanto ao Service Pack eu não sei o que é, o corioso e que com outros utilitarios ela esta imprimindo, fix teste com xHarnour e imprimiu normal.

Até +

MensagemEnviado: 05 Out 2007 16:43
por Pablo César
Obrigado por retornarem. Imaginei que esse arquivo (capturado) tivesse sido com o tamanho de zero byte. Então aparentemente é enviado ao spooler. sabe dizer Sergio se a fila de impressão fica "pausado" ? E se aparece alguma descrição de ERRO na fila de impressão (pois isto estava acontencendo comigo na HP D1300 que eu tinha intentado imprimir naquela época. Despois disto, Maligno você poderia ver se tem uma outra forma de direcionar a impressão quando for USB ?

MensagemEnviado: 05 Out 2007 17:04
por Maligno
é Windows 98

Danou-se. Estou sem o VMware pra testar o Win98 virtual.
O intrigante é que nos programas feitos no XHarbour funcionou. Então, é óbvio que há alguma diferença, pois pelo que sei, a função de impressão em baixo nível usa a mesmíssima função da API que a WAPI utiliza. A não ser por uma pequena coisinha que deixei de fora. Não achei necessário incluir. Vou ver isso com calma. Retorno depois.

MensagemEnviado: 05 Out 2007 17:06
por Maligno
você poderia ver se tem uma outra forma de direcionar a impressão quando for USB ?

Mas pelo spooler eu não preciso me prender ao fato de ser ou não USB. E outra: se comigo funciona, com ele também deveria funcionar. O X da questão é encontrar o que exatamente está fazendo a diferença. Vou tentar reinstalar meu VMware pra usar o Win98.

Aliás, relembrando: alguém reportou o mesmo problema usando o XP?

MensagemEnviado: 05 Out 2007 17:37
por Maligno
Reinstalei o VMware. Utilizei o mesmo demo TESTE.EXE e adivinha? Imprimiu normalmente. :)))) Só rindo mesmo.

Agora passo pra fase de alquimia. Vou fazer algumas experiências às cegas e, contando com a ajuda de vocês, tentar fazer esse trem imprimir direito onde está dando problema. Volto ao assunto. Mas acho que só no domingo.

MensagemEnviado: 05 Out 2007 18:01
por Pablo César
Isso não é surpresa para mim. Sempre questionei a fiel reprodução do WIN98 pelo VMware. Mas enfim, não está aqui quem disse.

Eu não lembro naquela época que fiz testes com a HP Deskjet D1360 USB, menciono que foi em WINXP, pode confirir htp://www.pctoledo.com.br/forum/viewtop ... 2677#22677

Poderei lhe auxiliar fazendo testes na minha Epson LX300 (paralela). Nela funciona SEMPRE e estou fazendo testes em WIN98, o engraçado que notei que o título que dou para o job de impressão, não aparece na fila de impressão. Isso ocorre quando configuro o spool para imprimir diretamente na impressora (tem essa opção na propriedades da impressora). Mas quando defino para "colocar os trabalhos no spool para que a impressão termine mais rapidamente" daí o título atribuido aparece normalmente. Isso que ocorre seria normal ?

MensagemEnviado: 05 Out 2007 18:12
por Maligno
Isso não é surpresa para mim. Sempre questionei a fiel reprodução do WIN98 pelo VMware.

E eu sempre disse que tudo funciona como se fosse o original. Até o presente momento não vi nada diferente disso. :)

sso ocorre quando configuro o spool para imprimir diretamente na impressora (tem essa opção na propriedades da impressora). Mas quando defino para "colocar os trabalhos no spool para que a impressão termine mais rapidamente" daí o título atribuido aparece normalmente. Isso que ocorre seria normal ?

Se você define como impressão direta para a impressora não há o que pensar em título de um job que fica pendente, por quê não fica pendente. Ele segue direto. Ao deixar o job a cargo do spooler, fica a pendência. Daí teria mesmo que aparecer o título. Está normal.

MensagemEnviado: 05 Out 2007 18:23
por Pablo César
How can I discuss with anyone if I have not experience with it. Mas meu sexto sentido me diz que não é a mesma coisa... sorry to disagree...

não fica pendente. Ele segue direto. Ao deixar o job a cargo do spooler, fica a pendência. Daí teria mesmo que aparecer o título. Está normal.
Tudo bem mas então por quê então daria para cancelar o job de impressão (isto eu sei porque mandei um relatorio grande) e parou na hora que cancelei (mesmo sem visualizar descrição alguma), dá pra entender ?

MensagemEnviado: 05 Out 2007 18:32
por Maligno
Tudo bem mas então por quê então daria para cancelar o job de impressão (isto eu sei porque mandei um relatorio grande) e parou na hora que cancelei (mesmo sem visualizar descrição alguma), dá pra entender ?

Não entendi muito bem. Você mandou imprimir direto pra impressora e cancelou o job pelo spooler?

MensagemEnviado: 05 Out 2007 18:49
por Maligno
Mas você enviou pela WAPI. Daí vai acho que tem que ir pro spooler de qualquer maneira, mesmo que haja uma configuração pra impressão direta.

MensagemEnviado: 05 Out 2007 18:49
por Maligno
Ah, você apagou sua mensagem antes que eu pudesse postar. :)

MensagemEnviado: 05 Out 2007 19:03
por Pablo César
Opa... desculpe não é assim. Acho que eu me empolguei e acabei falando abobrinha... porque eu cancelei ao desligar a impressora e liguei daí deve ter ficado na ROM da impressora e acessei para cancelar. Foi uma falsa impressão... desculpe.

Tentei reproduzir o que eu falei e não dá para fazer isso pois como eu mesmo disse, a impressão segura a máquina e não dá para entrar nas propriedades nem pelo botão direito do mouse (dá a mensagem que não tem direitos para cancelar o job de impressão).

Mil desculpas, eu me embananei... hihih

MensagemEnviado: 05 Out 2007 19:06
por Pablo César
Maligno escreveu:Daí vai acho que tem que ir pro spooler de qualquer maneira, mesmo que haja uma configuração pra impressão direta.
É... eu também acho o mesmo, mas essa questão de impressão direta e a descrição na fila, não faz sentido fazer pois não dá para interagir.

MensagemEnviado: 05 Out 2007 19:23
por Maligno
Mil desculpas, eu me embananei... hihih

Não se preocupe. Isso acontece comigo o tempo todo. É o desgramado do Murphy. :)))

MensagemEnviado: 05 Out 2007 19:24
por Maligno
mas essa questão de impressão direta e a descrição na fila, não faz sentido fazer pois não dá para interagir.

Na impressão direta não deveria dar mesmo. Mas pelo spooler você pode cancelar. Teoricamente, já que o spooler de vez em quando encrespa de um jeito que não cancela piçiroca nenhuma.

MensagemEnviado: 05 Out 2007 19:38
por Pablo César
Maligno escreveu:A não ser por uma pequena coisinha que deixei de fora. Não achei necessário incluir. Vou ver isso com calma.
Voltando ao caso de impressões em USB, então quer dizer que você irá alterar a função ?. Espero que consiga lançar um novo release logo, pois estou esperando aquela função do WINDOW2TOP que mostrava na tela o numero do handle.

Mas pelo spooler você pode cancelar. Teoricamente, já que o spooler de vez em quando encrespa de um jeito que não cancela piçiroca nenhuma.
Sério ? Mas você disse que não irias fazer nada para cancelar os jobs do spooler ou você está dizendo-me que irá verificar se você irá fazer mais essa função ?...

MensagemEnviado: 05 Out 2007 19:41
por Maligno
Voltando ao caso de impressões em USB, então quer dizer que você irá alterar a função ?. Espero que consiga lançar um novo release logo, pois estou esperando aquela função do WINDOW2TOP que mostrava na tela o numero do handle.

Sim, vou fechar o paginamento do WAPI com a impressão do jeito que está. Depois vou tentar alterar a impressão, incluindo aquilo que comentei que havia deixado de fora. Afinal de contas, do jeito que está funciona. Pelo menos pra mim. Se for o caso, lanço a correção em seguida.

MensagemEnviado: 06 Out 2007 08:36
por Sergio_ASSilva
Oi Pabrlo,

Desculpe o retorno e que terminou o expediente e nao tinha como responder, respondendo a sua pergunta: A impressao é enviada para impressora aparece na fila de impressao como "Imprimindo" mas nao imprime nem permite outras impresoes, tentei excluir nao consegui, depois que desligo e ligo a impresora volta a imprimir.



Grato


Sérgio

MensagemEnviado: 06 Out 2007 09:22
por Maligno
Era exatamente isso o que acontecia comigo quando tive esse problema. Mas depois parou. Foram só 2 ou 3 vezes.

MensagemEnviado: 06 Out 2007 12:44
por Pablo César
Sergio escreveu:tentei excluir nao consegui, depois que desligo e ligo a impresora volta a imprimir
Tenho seguintes perguntas a fazer:

1. Você consegue entrar no gerenciador de filas de impressão (aquele que mostra a fila de impressão que tem no spooler) ?
2. A sua impressora cómo está setada o spool para "imprimir diretamente" ou "colocar todos os trabalhos em spool" ?. Tentou fazer um teste para "imprimir diretamente" ?
3. Fez o check list da instrução passada ?
Pablo César escreveu:Não sei se isto irá ajudar, mas vale a pena revisar todos estes procedimentos. Porque imprimir em USB continua sendo um problema e as vezes o problema está diante de nós e não precebemos. Vale a penas checar:

clique aqui ==> http://h10025.www1.hp.com/ewfrf/wc/fast ... eUrl=true&

4. Após teste com o WAPI. Consegue fazer o sétimo e o oitavo passo (por separado) da instrução passada ?

MensagemEnviado: 06 Out 2007 17:20
por Maligno
Só uma ressalva: se com outro programa ele consegue imprimir normalmente e com a WAPI não, a busca pela solução deve estar no código do WAPI.C e não nos procedimentos de impressão ou configuração da impressora.

MensagemEnviado: 07 Out 2007 11:24
por Pablo César
Maligno escreveu:se com outro programa ele consegue imprimir normalmente e com a WAPI não, a busca pela solução deve estar no código do WAPI.C
Positivo, mas para isso precisamos identificar onde pode estar o possível erro, visto que com o modelo da sua impressora funciona sempre. E achei propício solicitar alguma verificações para tentar auxiliar ao diagnóstico enquanto é analisado e possivelmente alterado o seu código WAPI.

MensagemEnviado: 07 Out 2007 12:44
por Maligno
Sim, mas acredito que não há como refutar o indício de que o problema é de código e não de procedimento. Foi isso o que eu quis dizer. :)

MensagemEnviado: 08 Out 2007 12:10
por sygecom
Sergio_ASSilva escreveu:Oi Pabrlo,

Desculpe o retorno e que terminou o expediente e nao tinha como responder, respondendo a sua pergunta: A impressao é enviada para impressora aparece na fila de impressao como "Imprimindo" mas nao imprime nem permite outras impresoes, tentei excluir nao consegui, depois que desligo e ligo a impresora volta a imprimir.

Grato

Sérgio

Não sei se já respondeu....mas qual o a Marca e modelo de sua impressora? tenho casos aqui que até mesmo com o xharbour em MODO RAW não funciona....agora com a CLASSE win32prn funciona em qualquer impressora !!!

MensagemEnviado: 08 Out 2007 12:34
por Maligno
Ele já disse: HP 1020.

MensagemEnviado: 08 Out 2007 13:15
por sygecom
Opa, a HP-1020 tenho em clientes e funciona com RAW....

MensagemEnviado: 08 Out 2007 13:21
por Maligno
Acabei de dizer logo acima que funciona na HP1022 que eu tenho.

MensagemEnviado: 08 Out 2007 13:25
por sygecom
é o jeito é usar o xharbour mesmo com a classe win32prn...ai não tem erro algum, nem duvida se vai ou não funcionar....boa sorte !!!

MensagemEnviado: 08 Out 2007 16:10
por Maligno
sygecom escreveu:o jeito é usar o xharbour mesmo com a classe win32prn

Não estamos tentando encontrar um método que permita imprimir sem erros. Estamos querendo descobrir qual erro da WAPI deve ser corrigido para que nela se possa imprimir normalmente. Observe o título deste tópico.

MensagemEnviado: 08 Out 2007 16:19
por sygecom
Apenas é uma opinião....

MensagemEnviado: 08 Out 2007 16:28
por Maligno
É sempre válida a opinião de qualquer um, mas note que o Sérgio já disse que utiliza o programa do Heveraldo (USB.EXE) com sucesso. Se tivesse lido do princípio, teria percebido qual é o foco da discussão.

MensagemEnviado: 08 Out 2007 16:30
por sygecom
ok

MensagemEnviado: 19 Out 2007 02:10
por Maligno
asimoes escreveu:Vi que você tem uma biblioteca chamada WAPI.
Eu baixei os fontes, depois de muito custo consegui chegar no SUCESSO e a biblioteca foi criada: tamanho dela: 67072kb

Mesmo tamanho da biblioteca que eu compilei.

Se você já tiver a biblioteca wapi.lib pronta, você poderia mandar para o meu email: asimoesluz@gmail.com

Mas o pacote ZIP, que provavelmente você pegou do meu site, já contém o arquivo WAPI.LIB pronto.

Aprinter:=GetPrinters() <-- Aqui acontece o erro.

Qual é o erro exatamente? Há um texto descritivo, imagino. Ou não?

MensagemEnviado: 19 Out 2007 02:43
por asimoes
Maligno,

Quando eu executo a wapi.exe no prompt wapi -getprinters:teste
Me retorna:

0,PrimoPDF,PrimoPort:
0,Microsoft Office Document Image Writer,Microsoft Document Imaging Writer Port:
1,hp1310,USB001

Quando eu chamo a função getprinters() me retorna 1, inclusive na função SetaImp(), que já foi postado no forum dá erro quando é atribuido ao veto.r

Estou usando clipper 5.2e
Blinker 7.0
Modo protegido.

O wapi.lib tem o tamnho 67072kb

O que pode estar errado?

Obrigado.

MensagemEnviado: 19 Out 2007 03:01
por Maligno
asimoes escreveu:Quando eu executo a wapi.exe no prompt wapi -getprinters:teste
Me retorna:

0,PrimoPDF,PrimoPort:
0,Microsoft Office Document Image Writer,Microsoft Document Imaging Writer Port:
1,hp1310,USB001

Em linha de comando, tudo bem. Esse é um típico retorno. Está normal. A impressora default é uma HP1310.

Quando eu chamo a função getprinters() me retorna 1

Você quer dizer que o retorno de GetPrinters(), ao invés de ser uma matriz, como esperado, é um dado numérico, cujo valor é 1?

E quanto ao erro em si, qual é a mensagem do erro? Ele ocorre exatamente naquela linha em que você executa GetPrinters()?

MensagemEnviado: 19 Out 2007 06:34
por asimoes
Exatamente, a função me retorna 1, que não é vetor.

Veja o meu script de linkedição:

BLINKER INCREMENTAL OFF
BLINKER OVERLAY PAGEFRAME ON
BLINKER EXECUTABLE SERIAL SC v2007.10
BLINKER EXECUTABLE CLIPPER //F:200 //DYNF:8 //INFO
BLINKER EXECUTABLE COMPRESS 1
BLINKER EXECUTABLE EXTEND
FI SC0000
OU SC
FI SC0101
FI SC0201
FI SC0202
FI SC0301
FI SC0401
FI TIMESLIC
LIB SCFUNC
LIB FAST52
LIB APIBLI
LIB DBFCDX
FI CTUSP,ERROS
LIB OSLIB
LIB CPMI
LIB VL2_52
LIB CTP52
SEARCH BLXCLP52
LIB WAPI


Maligno escreveu:
asimoes escreveu:Quando eu executo a wapi.exe no prompt wapi -getprinters:teste
Me retorna:

0,PrimoPDF,PrimoPort:
0,Microsoft Office Document Image Writer,Microsoft Document Imaging Writer Port:
1,hp1310,USB001

Em linha de comando, tudo bem. Esse é um típico retorno. Está normal. A impressora default é uma HP1310.

Quando eu chamo a função getprinters() me retorna 1

Você quer dizer que o retorno de GetPrinters(), ao invés de ser uma matriz, como esperado, é um dado numérico, cujo valor é 1?

E quanto ao erro em si, qual é a mensagem do erro? Ele ocorre exatamente naquela linha em que você executa GetPrinters()?

MensagemEnviado: 19 Out 2007 10:04
por Maligno
Uma experiência: coloque a WAPI como a primeira LIB na sua lista. Tente de novo e me diga qual o resultado.

MensagemEnviado: 19 Out 2007 19:07
por asimoes
Maligno,

Fiz o que você recomendou.

No meu código fiz um teste chmando a função GetPrinters()

? GetPrinters()
INKEY(0)

Quando eu executo o meu programa me retorna o seguinte erro:

D:\CDX\SC>sc
Clipper (R) 5.2e Intl. (Rev. 216) BRITISH - ASCII Collation
DS=0297:0000 DS avail=4KB OS avail=1023KB
(0) Unrecoverable error 667: Eval stack fault
(Fixed heap=0KB/0)VMZÉ

Maligno decobri uma coisa, a fastlib que eu uso tem uma função com o mesmo nome: GetPrinter() e ela retorna 0 ou 1, eis a função:

GetPrinter()

Gets printer state

Syntax:

GetPrinter( [nPrinter] ) -> nStatus

nPrinter : Printer Number. 0 = LPT1, 1 = LPT2...
Defect verify the printer 0

Description:

Determines if the printer is ready, out of paper, if is off or there
is no printer.

Return:

A number indicating the printer state over the next list.
Eu removi a biblioteca fast52.lib do meu script e mesmo assim quando executo me retorna o erro acima.

Maligno escreveu:Uma experiência: coloque a WAPI como a primeira LIB na sua lista. Tente de novo e me diga qual o resultado.

MensagemEnviado: 19 Out 2007 20:47
por Maligno
a fastlib que eu uso tem uma função com o mesmo nome: GetPrinter() e ela retorna 0 ou 1

Aha!!! Pois era essa a minha desconfiança. Você colocou a WAPI em primeiro na lista do seu script e agora deu erro de "eval stack fault"? É isso? Se sim, tentou aumentar o "stack" no BLinker?

Se bem que eu sou muito cabreiro com esse negócio de aumentar o tamanho da pilha. Nunca fiz isso na vida e nunca tive qualquer problema. :(

Aliás, teria você alguma função recursiva perdida por aí?

MensagemEnviado: 19 Out 2007 22:30
por asimoes
Maligno,

eu tentei usando o stack 512
Não deu o erro, mas também a função na me retornou nada.

Maligno escreveu:
a fastlib que eu uso tem uma função com o mesmo nome: GetPrinter() e ela retorna 0 ou 1

Aha!!! Pois era essa a minha desconfiança. Você colocou a WAPI em primeiro na lista do seu script e agora deu erro de "eval stack fault"? É isso? Se sim, tentou aumentar o "stack" no BLinker?

Se bem que eu sou muito cabreiro com esse negócio de aumentar o tamanho da pilha. Nunca fiz isso na vida e nunca tive qualquer problema. :(

Aliás, teria você alguma função recursiva perdida por aí?

MensagemEnviado: 19 Out 2007 22:32
por asimoes
Você se refere a recursiva:
Você diz, funções com o mesmo nome das que fazem parte da wapi.lib?
a resposta é não.

MensagemEnviado: 19 Out 2007 22:42
por asimoes
Maligno,

Eu mudei a lib para o final e funcinou, vou testar a impressão para ver qual é.
Qualquer novidade eu posto :)Pos

Maligno,

Continuo com o:
(0) Unrecoverable error 667: Eval stack fault

MensagemEnviado: 20 Out 2007 00:52
por Maligno
asimoes escreveu:Você se refere a recursiva:
Você diz, funções com o mesmo nome das que fazem parte da wapi.lib?
a resposta é não.

Uma função é dita recursiva quando executa ela própria. Acontece que, havendo algum descontrole no código, a função pode chamar ela própria muitas vezes. Aí o "eval stack fault" é certo.

MensagemEnviado: 20 Out 2007 00:55
por Maligno
asimoes escreveu:Eu mudei a lib para o final e funcinou, vou testar a impressão para ver qual é.

Mas a WAPI já estava no final. Não entendi.

(0) Unrecoverable error 667: Eval stack fault

Acrescentou o comando STACK <bytes>, como eu disse? Tenta colocar uns 10240 bytes pra ver se o pipoco continua. :)

MensagemEnviado: 20 Out 2007 09:59
por asimoes
Fiz como você recomendou e o erro, te diz algo?:

WAPITMPDIR (0) Unrecoverable error 667: Eval stack fault
(Fixed heap=26KB/1)

Maligno escreveu:
asimoes escreveu:Eu mudei a lib para o final e funcinou, vou testar a impressão para ver qual é.

Mas a WAPI já estava no final. Não entendi.

(0) Unrecoverable error 667: Eval stack fault

Acrescentou o comando STACK <bytes>, como eu disse? Tenta colocar uns 10240 bytes pra ver se o pipoco continua. :)

MensagemEnviado: 21 Out 2007 09:36
por Maligno
Mesmo com o STACKS aumentado esse erro continua?

MensagemEnviado: 24 Out 2007 03:59
por rochinha
...

MensagemEnviado: 31 Out 2007 09:45
por ANDRIL
Maligno estou usando a lib atraves da funcao GetMyHandle() e Window2Top() no WIN98 e nao consigo devolver o focu à janela ao chamar um aplicativo externo.

O q percebi é que quando o aplicativo esta janelado ele volta mais em tela cheia nao.
Sera que nao teria como colocar no buffer do windows um comando tipo KEYBOARD chr(13) ao final da chamada a funcao Window2Top() para que seja devolvido o foco ao aplicativo em tela cheia.

**Nota: digo isso pq ao retornar da funcao Window2Top() e o aplicativo estando em tela cheia a barra da janela fica ativa porem o foco nao volta sendo necessario teclar ENTER, por isso, acho q se dentro (digo no final) da funcao vir acompanhada de ENTER acho q resolveria.

Só nao sei se é possivel colocar tal instrução.

Ate+

MensagemEnviado: 31 Out 2007 10:02
por Maligno
Esse Windows 98 é um carma. :)))
Enxertar um código de tecla vai ficar complicado. Não sei se seria possível. Mas vou tentar olhar mais de perto o comportamento da função pra analisar alguma outra possibilidade. O diabo é que estou com a máquina meio parada. Estou instalando minhas tranqueiras num HD novo. Isso demora um pouquinho. Acho que só amanhã vou poder ver isso. Mas volto ao assunto. Pode aguardar.

RESP

MensagemEnviado: 31 Out 2007 12:14
por tonyx
NAO QUERENDO ME METER MAS A FUNCAO SWPRUNCMD
SERVIRIA NO XHARBOUR -
POIS O RUN START ARQUIVO,
ESTA TRAVANDO MEUS ARQUIVOS DE REDE LA, JA NO CLIP53 NAO

CARO MALIGUINO JA USOU O WORD EM SEUS SISTEMAS ???

Re: RESP

MensagemEnviado: 31 Out 2007 12:26
por sygecom
tonyx escreveu:NAO QUERENDO ME METER MAS A FUNCAO SWPRUNCMD
SERVIRIA NO XHARBOUR -
POIS O RUN START ARQUIVO,
ESTA TRAVANDO MEUS ARQUIVOS DE REDE LA, JA NO CLIP53 NAO

CARO MALIGUINO JA USOU O WORD EM SEUS SISTEMAS ???

Não serve para xHarbour, essa é uma função do Blinker, vc pode usar o WINEXEC() ao inves do RUN basta linkar a WHAT32.LIB.

MensagemEnviado: 31 Out 2007 12:27
por Maligno
Você deveria abrir um novo tópico específico para essa questão do RUN. E, respondendo à sua pergunta, não. Eu nunca usei o Word em programa Clipper.

MensagemEnviado: 01 Nov 2007 08:13
por Pablo César
ANDRIL escreveu:estou usando a lib atraves da funcao GetMyHandle() e Window2Top() no WIN98 e nao consigo devolver o focus à janela ao chamar um aplicativo externo.

Nota: digo isso pq ao retornar da funcao Window2Top() e o aplicativo estando em tela cheia a barra da janela fica ativa porem o foco nao volta sendo necessario teclar ENTER, por isso, acho q se dentro (digo no final) da funcao vir acompanhada de ENTER acho q resolveria.
Eu acho que fazer uma alteração desse tipo iria influenciar no aplicativo em execução nos outros casos que o WAPI funciona perfeitamente em WINXP ou até mesmo em modo janelado do WIN98. Para isso tem uma solução bem simples.

1. Eu crio uma variável de ambiente que indica qual é a versão do SO. Se preferir utilizar alguma biblioteca para fazer uso da definição da versão do WINDOWS vai da sua pessoa. Eu por exemplo não tive 100% de bom resultado no uso de biblioteca, pois me dava algumas divergências (não me pergunte o por quê ?). Mas decidí utilizar o comando VER do próprio Windows na linha de comando. Mas isso ja é outra questão que se precisar saber, podemos abordar mais tarde.

2. Uma vez que você de dentro da sua aplicação Clipper, identificar qual é o Ruindows utilizado, é dizer se for o WIN98, existe um aplicativo chamado Z.COM ora apresentado pelo Wagner que serve para identificar se a sessão está em modo JANELADO ou TELA-CHEIA (isso funciona somente para WIN98) e que você poderá conferir no seguinte link:

http://www.pctoledo.com.br/forum/viewto ... 3454#33454

3. Você sabendo que a aplicação está em TELA-CHEIA, dê uma mensagem em LOOPING pro usuário e que verifique se saiu dessa condição de TELA-CHEIA. Por tanto só irá pra frente até o usuário por si mesmo dar o ALT-ENTER.

Daí então, acho que irá funcionar perfeitamente para o seu caso, pois eu ja venho utilizando isto por causa de que não existe solução desse dilema. Bom seria se pudermos contar com uma opção no WAPI que desse o modo de exibição (em quaisquer versão do Windows). Mas isso é outro dilema... hihi

MensagemEnviado: 07 Nov 2007 12:59
por Pablo César
Maligno, me permita fazer uma colocação de hipótese. Você possue duas funções relacionadas ao CLIBOARD. Uma delas é a função GETCLIPBOARD que somente lê e grava em arquivo o conteúdo do CLIPBOARD se for tipo TEXTO, no entanto quando for tipo DIB (imagem) dá retorno no arquivo de resultado como -31 (o que significa: "Objeto do Clipboard não suportado").

A outra função é SETCLIPBOARD e esta tem por finalidade enviar para o clipboard a STRING que é passado como segundo parâmetro da sua função.

Pergunto:

1. Tem como capturar a tela toda da sessão e determinar que tipo é se é do tipo DIB ou tipo TXT ?

2. Se a sua resposta acima for SIM: teria como fazer mais uma opção para que o CLIPBOARD seja ZERADO ?

Digo tudo isto, porque me parece justamente o contrário do comportamento do PRINTNOW e HARDCOPY. Entendeu a lógica ?.

MensagemEnviado: 07 Nov 2007 13:42
por Pablo César
Estou impolgado neste assunto porque acho que você vai conseguir fazer uma função que determine se a sessão está em modo JANELADO ou TELA-CHEIA.

Fiz testes capturando a tela através do ALT-PRTSCRN em ambos modos (JANELADO e TELA-CHEIA) e o resultado pareceu coerente com a apresentação da tela.

Quê raro que você ainda não tenha me respondido. Você deve estar muito ocupado ou está chetado comigo pelos cutucões que eu te fiz nesta manhã....

MensagemEnviado: 07 Nov 2007 22:53
por asimoes
Olá Maligno,

Continuo fazendo os testes com a WAPI, mas infelizmente não consigo sucesso.
rodando direto no prompt:

wapi -PRINT:hp1310;teste.txt;"teste";resulta.txt

Não imprime.

O job fica retido e também não exclui.

Pelo programa do everaldo usb.exe consegui imprimir. Ele foi feito em harbour?
:( Alexandre

MensagemEnviado: 07 Nov 2007 23:08
por sygecom
asimoes escreveu:Olá Maligno,

Continuo fazendo os testes com a WAPI, mas infelizmente não consigo sucesso.
rodando direto no prompt:

wapi -PRINT:hp1310;teste.txt;"teste";resulta.txt

Não imprime.

O job fica retido e também não exclui.

Pelo programa do everaldo usb.exe consegui imprimir. Ele foi feito em harbour?
:( Alexandre

xHarbour, usando a Classe WIN32PRN

MensagemEnviado: 07 Nov 2007 23:41
por asimoes
Sygecom,

Eu queria passar um sistema pequeno meu para xharbour, é complicado?
Existe ALGUM tutorial FÁCIL para migrar?
O que é preciso?

[]´sjavascript:emoticon(':)Pos')
Positivo


sygecom escreveu:
asimoes escreveu:Olá Maligno,

Continuo fazendo os testes com a WAPI, mas infelizmente não consigo sucesso.
rodando direto no prompt:

wapi -PRINT:hp1310;teste.txt;"teste";resulta.txt

Não imprime.

O job fica retido e também não exclui.

Pelo programa do everaldo usb.exe consegui imprimir. Ele foi feito em harbour?
:( Alexandre

xHarbour, usando a Classe WIN32PRN
:)Pos :)Pos

MensagemEnviado: 08 Nov 2007 07:34
por Maligno
Continuo fazendo os testes com a WAPI, mas infelizmente não consigo sucesso. rodando direto no prompt:

A versão 4.03 sai no final da semana com uma alteração na impressão. Se quiser aguardar para testar novavamente,...

Se bem quê, do jeito que você fez eu consigo imprimir normalmente na HP1022. :|

MensagemEnviado: 08 Nov 2007 07:35
por Maligno
asimoes escreveu:Sygecom,

Eu queria passar um sistema pequeno meu para xharbour, é complicado?

Na seção de xharbour tem várias mensagens nesse sentido. Deu uma olhada lá?

MensagemEnviado: 08 Nov 2007 07:37
por Pablo César
Bom dia Maligno, a WAPI ja está versão 4.03 ? Ou acho que você quiz dizer 1.03 ?

MensagemEnviado: 08 Nov 2007 07:37
por Maligno
Pablo César escreveu:1. Tem como capturar a tela toda da sessão e determinar que tipo é se é do tipo DIB ou tipo TXT ?

Provavelmente. Mas nunca nem passei perto disso. Vou ter que pesquisar a respeito.

2. Se a sua resposta acima for SIM: teria como fazer mais uma opção para que o CLIPBOARD seja ZERADO ?

Isso é fácil.

Digo tudo isto, porque me parece justamente o contrário do comportamento do PRINTNOW e HARDCOPY. Entendeu a lógica ?.

Ainda não li o PrintNOW. Só baixei. Não sei o que é feito nele.

MensagemEnviado: 08 Nov 2007 07:39
por Maligno
Pablo César escreveu:Estou impolgado neste assunto porque acho que você vai conseguir fazer uma função que determine se a sessão está em modo JANELADO ou TELA-CHEIA.

Às vezes um efeito colateral pode resolver a parada. :)

Quê raro que você ainda não tenha me respondido. Você deve estar muito ocupado ou está chetado comigo pelos cutucões que eu te fiz nesta manhã....

Não parei ontem depois do almoço. Só voltei tarde da noite. Agora que li tudo. :)

MensagemEnviado: 08 Nov 2007 07:39
por Pablo César
Maligno escreveu:Vou ter que pesquisar a respeito.

Ainda não li o PrintNOW. Só baixei. Não sei o que é feito nele.
Bom, vou aguardar a sua posição. Pois não sei se percebeu, andou meio ancioso... hihih

Não parei ontem depois do almoço. Só voltei tarde da noite. Agora que li tudo.
Ainda bem que é assim... o fórum a tarde toda ficou quase sem novos tópicos... e achei que era alguma punição divina... hihi

MensagemEnviado: 08 Nov 2007 07:40
por Maligno
Pablo César escreveu:Bom dia Maligno, a WAPI ja está versão 4.03 ? Ou acho que você quiz dizer 1.03 ?

Cacilda!!!! É verdade. Estou colocando a coisa muito à frente. Acho que é o sono. :)))))

MensagemEnviado: 08 Nov 2007 07:48
por Pablo César
Às vezes um efeito colateral pode resolver a parada.
Você sabe que estou básicamente apostando nisso. Embora não se consiga uma definição para o conteúdo mas como você disse quem sabe ao obter retorno negativo para o conteúdo em busca de TEXTO venha a se deduzir que seja gráfico. Bom seria mesmo achar uma técnica precisa que não difera nem com as diferentes versões do Ruindows.

MensagemEnviado: 08 Nov 2007 07:59
por Maligno
Não pesquisei nada disso ainda, mas só pra me adiantar: o que é esse tal de DIB?

MensagemEnviado: 08 Nov 2007 08:02
por Maligno
Deixa pra lá. Já saquei: Device Independent Bitmap. :)

MensagemEnviado: 08 Nov 2007 08:09
por Pablo César
Device independent Bitmap.
Até onde eu sei, é um conjunto de funções que tratam essa questão gráfica que você irá encontrar no arquivo fonte DIBAPI.CPP daquele aplicativo PRINTNOW, por isso em todas as minhas mensagens que mencionei a plavra "DIB" coloquei ao lado entre parentese (gráfico) o certo ter dito de ordem BITMAP.

MensagemEnviado: 08 Nov 2007 08:11
por Maligno
Sim, eu vi. Mas DIB não é um conjunto de funções. É um bitmap metido a besta. Vou ver depois com calma. Obrigado. :)

MensagemEnviado: 08 Nov 2007 08:12
por Pablo César
Sim mas tem alguma instrução da própria Microsoft.

MensagemEnviado: 08 Nov 2007 08:13
por Maligno
Deve ser algum conjunto de tags pra orientação e/ou configuração. Algo assim.

MensagemEnviado: 08 Nov 2007 08:20
por Pablo César
GO AHEAD my friend !. Eu lei o código C como se fosse em chinês ainda. Sei que você é a pessoa para decifrar isso, pois aqui no fórum ninguém teve o peito de siquer questionar ou opinar algo quando eu questionei. Claro que devo fazer algum desconto, naqueles que ainda não tiveram oportunidade de ler meu questionamento ao respeito.

MensagemEnviado: 08 Nov 2007 08:21
por Maligno
De qual questionamento você está falando?

MensagemEnviado: 08 Nov 2007 08:40
por Pablo César
Bem, não posso dizer que não tive nenhuma resposta, embora não tenha atendido a essa questão sobre o conteúdo DIB o querido colega Rochinha fez uma menção muito importante que era a razão principal daquele tópico de acionar/detectar a tecla PRTSCRN, que por instrução da Microsoft não é possível.

O meu questionamento foi lançado neste tópico: http://www.pctoledo.com.br/forum/viewto ... 6559#36559 e consequentemente deste: http://www.pctoledo.com.br/forum/viewto ... 6729#36729

Mas é claro que não culpo a ninguém, pois isto é liguagem C e a minha intenção era confirmar tal teoria.

MensagemEnviado: 08 Nov 2007 08:43
por Maligno
Ah, sim. Agora que entendi. Tinha vista. Meio por cima, mas tinha visto. E a resposta, com 99% de certeza, é sim: dá pra diferenciar DIB de texto. Por isso comentei sobre o "efeito colateral". Mas só não sei dizer se o comportamente será padrão para todas as versões do Windows. É a razão de faltar 1%. :)

MensagemEnviado: 08 Nov 2007 08:55
por Pablo César
Maligno escreveu:E a resposta, com 99% de certeza, é sim
Ahhh fico muito aliviado e contente em saber. Então podemos dizer que básicamente todas as probabilidades levam a dizer que você irá conseguir compor essa lógica para criar uma nova função no WAPI que retorne se a aplicação é modo JANELA ou TELA-CHEIA e ao mesmo tempo isto servirá para poder capturar a tela e pôr na área de transferência pelo WAPI.

Pelo que ví assim por cima... ví que o enquadramento do conteúdo do Clipboard serve tanto para WIN95 e NT versions (é mencionado como comentário nos fontes, está no PNDLG.CPP). Tomara seja assim embora esse aplicativo tenho utilizado em WIN98 e funcionou perfeitamente.

Obrigado colega, por responder. Essa questão tem um valor muito estimável.

MensagemEnviado: 08 Nov 2007 10:40
por sygecom
asimoes escreveu:Sygecom,
Eu queria passar um sistema pequeno meu para xharbour, é complicado?
Existe ALGUM tutorial FÁCIL para migrar?
O que é preciso?

É facil, comece abrindo um topico novo na sessão do xharbour para nos poder lhe auxiliar melhor.

MensagemEnviado: 08 Nov 2007 15:34
por Maligno
Pablo César escreveu:aquele aplicativo PRINTNOW

Falando nesse programa, o que é aquele outro tal de HARDCOPY sobre o qual você comentou noutra mensagem?

MensagemEnviado: 08 Nov 2007 16:01
por Pablo César
Foi apresentado outro aplicativo pelo "asimoes" que faz o mesmo e mais alguns outros recursos como: grava em disco, envia por email, insirir imagem direto no Word/Excel, editar conteúdo, etc... veja no link abaixo para download:

http://www.hardcopy.de/hardcopy/english/

Mas este aplicativo não traz consigo os códigos-fontes (é claro). A diferença deste aplicativo com o PRINTNOW, é que o PRINTNOW não precisa ficar residente é só executar (e para mim isso é uma vantagem).

MensagemEnviado: 08 Nov 2007 16:36
por Maligno
Mesmo não tendo disponíveis os códigos fontes, ainda é uma fonte de inspiração. Já ajuda. :)

MensagemEnviado: 08 Nov 2007 16:43
por ANDRIL
Maligno, consegui algo a respeito da funcao Window2Top() retornar no keyboard o ENTER? Acha que é possivel?

MensagemEnviado: 08 Nov 2007 16:53
por Pablo César
Desculpa mais uma vez Andril eu me intrometer no assunto. Mas por favor me confirme a seguinte postura: se Maligno conseguir resolver a velha questão de saber se a sessão em que o aplicativo-Clipper estiver em modo JANELADA ou TELA-CHEIA. E com isso nós possamos dar uma mensagem ou atém mesmo quem sabe reproduzir as teclas combinas ALT-ENTER (para alternar de modo) ja não seria o suficiente sem ter que arriscar a reprodução de um ENTER que até isto poderia significar a confirmação de alguma situação no sistema-Clipper ?.

Creio que o Maligno anda muito perto de conseguir e será um grande triunfo, porque com essa outra função você em modo janelado SEMPRE conseguirá retornar ao focus da sua sessão principal. Não acha Andril ?

MensagemEnviado: 08 Nov 2007 16:57
por Pablo César
Você estava com dificuldades para o retorno da aplicação após executar a função WINDOW2TOP da WAPI quando a sessão em modo TELA-CHEIA (ou FULLSCREEN, como queira chamar), isto em WIN98 somente e então eu sugerí a utilização do aplicativo Z.COM, você a usou como recomendei ?. Pois estou seguro que você resolveria por enquanto a sua questão.

MensagemEnviado: 08 Nov 2007 17:08
por Maligno
O tal Z.COM não tem fontes. Vou ter que desmontar.

MensagemEnviado: 08 Nov 2007 17:13
por Pablo César
Lembre que este só funciona bem em WIN98 não em WINXP.

MensagemEnviado: 08 Nov 2007 17:14
por ANDRIL
Pablo, entendo a sua linha de raciocinio. O meu problema nao esta só no fato de ser JANELADO ou TELA-CHEIA, mais sim o FOCO da janela. Quando o sistema esta em janela a funcao WINDOWN2TOP() retorna a janela corretamente, só que a questão tambem se aplica nos clientes que nao querem utilizar o sistema em modo janelado por motivos deles (eles sempre inventam algo).

Entao se uso a TELA CHEIA e chamo um aplicativo externo, exemplo WORDPAD ele abre e fica com o FOCO e meu sistema MINIMIZADO. Se eu mando ele imprimir diretamente (sem exibir o documento) ele devolve o focO ao sistema ( só que nao volta a ficar em TELA-CHEIA ) necessitando teclar ENTER.

Bom para encurtar, espero que o Maligno tenha exito em uma das duas hipoteses (ou quem sabe nas duas).

Ate+

Detecta modo da sessão só no WIN98

MensagemEnviado: 08 Nov 2007 17:41
por Pablo César
ANDRIL escreveu:Pablo, entendo a sua linha de raciocinio. O meu problema nao esta só no fato de ser JANELADO ou TELA-CHEIA, mais sim o FOCO da janela.
Acho que não entendeu ainda. Se você ler o link onde menciono cómo fazer a detecção de que modo está a janela ( A este tópico me refiro, clique aqui ), você verá que o objetivo é saber:

1. Se seu sistema está sendo executado em WIN98. Se for, OK sigamos enfrente, caso contrário não há necessidade de verificar o próximo passo (que é ver se está em modo JANELADO ou TELA-CHEIA), porque no WINXP o WINDO2TOP funciona SEMPRE.
2. Antes de chamar a aplicação GUI (seja qual for: NOTEPAD, WINWORD, etc.), você deve verificar se a sessão está em modo JANELADO, a fim de que possa retornar a sessão principal após execução do aplicativo GUI. E para isso você deve fazer aquela função que utiliza o Z.COM. Daí se a sessão estiver em modo TELA-CHEIA (entendo que muitos gostam de usar assim), então você faz um DO WHILE onde dará uma mensagem na tela dizendo que deve pressionar a teclas ALT-ENTER para mudar para o modo janelado, após essa mensagem verifique em looping o modo da sessão novamente através do Z.COM, no site do nosso colega Wagner. Em sintese: não permita ir pra frente se o usuário não mudar a tela para o modo JANELADO, isto é se não utilizar as teclas ALT ENTER.
4. Verifique o HANDLE da sessão chamadora para depois restaurar-la
5. Execute normalmente sua aplicação GUI como sempre o fez. Meu conselho é utiliza o START /W
6. Após execução do aplicativo GUI, retornará à sessão chamadora (naturtalmente, mas pode forçar com a função WINDOW2TOP para garantir).
7. Depois disso, se quiser pode dar a mensagem pro usuário dizendo que pode retornar a TELA-CHEIA como estava antes.

Entao se uso a TELA CHEIA e chamo um aplicativo externo, exemplo WORDPAD ele abre e fica com o FOCO e meu sistema MINIMIZADO. Se eu mando ele imprimir diretamente (sem exibir o documento)

ANDRIL escreveu:ele devolve o focO ao sistema ( só que nao volta a ficar em TELA-CHEIA ) necessitando teclar ENTER.
Você diz que devolve foco, mas na verdade nessa condição o focus não se estabeleceu, senão estaria retornando a aplicação e não teria esse problema. Mas isso só é necessário tão somente e apenas nessa condição (WIN98+MODO TELA-CHEIA) no resto ele funciona e se o Maligno fizer um ENTER a mais nas outras condições poderá interferir no seu aplicativo porque o focus se estabeleceu.

Essa questão do modo JANELADO em WIN98 e creio que em 95 também, após executar um aplicativo GUI a sessão principal fica minimizado mesmo. E o Maligno ja disse que não tinha solução para isso.

Espero que agora você tenha entendido. Qualquer coisa é só perguntar, Andril.

Veja o exemplo em looping que verifica o modo e não sai até atender ao modo da tela em que se deseja:

Fiz um aplcativo que verifica o modo (VERMODO.PRG)
PARAMETERS VMODO
IF VMODO=NIL
   VMODO="0" // Recebo como parâmetro e é quando quero que fique em modo JANELADO
ELSE
   VMODO=STR(VAL(VMODO),1,0)
ENDIF
DO CASE
   CASE "95" $ VER_WIN
        VRODA:="Z -F > C:MODO.TXT"
   CASE "98" $ VER_WIN
        VRODA:="Z -F > C:MODO.TXT"
    OTHERWISE
        VRODA:=""
ENDCASE
DO WHILE .T.
   IF !EMPTY(VRODA)
      SWPRUNCMD(VRODA)
      RESTSCREEN( 00,00,24,80,TELA_PRI )
      SETPOS(00,00)
   ENDIF
   IF FILE("C:MODO.TXT")
      VTXT:=MEMOREAD("C:MODO.TXT")
      IF "it's windowed mode." $ VTXT
         IF VMODO="0"
            EXIT
         ELSE
            IF ALERTAR(" necess rio alternar o modo de exibi‡„o da tela.;;Pressione as teclas <Alt><Enter> simultaneamente.;;Isto ir  deixar o modo de exibi‡„o em TELA INTEIRA.",{"Ok","Desconsiderar"},2)=2
               EXIT
            ENDIF
         ENDIF
      ELSE
         IF VMODO="0"
            IF ALERTAR("É necessário alternar o modo de exibição da tela.;;Pressione as teclas <Alt><Enter> simultaneamente.;;Isto ir  deixar a exibição da tela em modo JANELADO.",{"Ok","Desconsiderar"},2)=2
               EXIT
            ENDIF
         ELSE
            EXIT
         ENDIF
      ENDIF
      DELETE FILE("C:MODO.TXT")
   ELSE
      EXIT
   ENDIF
ENDDO
RETURN NIL

MensagemEnviado: 14 Nov 2007 09:03
por ANDRIL
Maligno estou fazendo testes com a sua Wapi.lib e notei que a funcao DloadFile("meusite/meuarquivo.exe",@cRet,"&cArq") retorna .F. na maioria das vezes.

Consigo baixar o arquivo de vez enquando, por que será? O arquivo esta sempre disponivel no meu site, não é limite de conecxao do site, não é o tamanho do arquivo ( ja tentei arquivo de 1kb ate 500kb) estou sem entender, será q vc saberia o por que???

Estou usando no win98, conecxao banda larga.

Ate+

MensagemEnviado: 14 Nov 2007 09:40
por Maligno
Tem firewall? O meu encrespa com essa função de vez em quando, pois quando o EXE é gerado, ele ainda não tem confirmada a alteração deste arquivo. Daí, até clicar no botão "Aceitar a modificação", o tempo de download passou e a função retorna FALSE. Se eu desligar o firewall o programa executa normalmente, sem qualquer retorno FALSE.

MensagemEnviado: 14 Nov 2007 10:10
por ANDRIL
Maligno, no teste que relatei ja havia desativado firewall e anti-virus. O estranho é que o modem começa a pista apos a solicitação e rapidinho retorna FALSE.

Coloquei a DloadFile("meusite/meuarquivo.exe",@cRet,"&cArq") em um loop com 3 tentativas e mesmo assim retorna FALSE.

A solução que encontrei "por enquanto" foi aumentar o TIMEOUT para 10 o padrao é 2.

Agora vou testar mais pois o meu acesso é ADSL e nao sei se servira p conecxao discada.


Qualquer novidade lhe aviso,

ate+

MensagemEnviado: 14 Nov 2007 11:00
por Maligno
Desconfiei de imediato do Firewall, pois passei por problema semelhante. O TimeOut seria a segunda opção. Se aumentando este valor funciona, tanto melhor. Pode ser alguma limitação da sua conexão, se é direta, em rede, proxy, etc.

MensagemEnviado: 16 Nov 2007 09:23
por Pablo César
Maligno escreveu:A versão 4.03 sai no final da semana com uma alteração na impressão.
How it is going ? I am still waiting for it... Não que eu precise essencialmente a questão de impressão mas o novo release do WINDOW2TOP. Imagem

MensagemEnviado: 16 Nov 2007 11:17
por Maligno
Está dando pau no meu computador. Não estou conseguindo compilar a WAPI. Quero ver se consigo consertar até a noite. Até lá estou atolado com um serviço de cliente. Triste sina! :(

MensagemEnviado: 17 Nov 2007 08:20
por Maligno
Resolvido: eu tinha um path de include invertido, o que fazia o compilador C utilizar um header impróprio, originando centenas de erros. Corrigi a função Window2Top, compilei e subi o pacote. É o mesmo número de versão. Só muda a data.

MensagemEnviado: 17 Nov 2007 09:00
por Pablo César
Corrigi a função Window2Top, compilei e subi o pacote. É o mesmo número de versão.
Ótimo, estava precisando disso, desculpe a minha pressa mas agora está beleza: não está ensujando a tela... hihi Obrigado, Maligno. Vai ter algum release neste fim-de-semana ?

MensagemEnviado: 17 Nov 2007 10:38
por Maligno
Cara, nem falo mais nada. Por quê a cada vez que falo, algum cliente ouve e resolve me ferrar. Agora vou ficar de bico fechado. :)

MensagemEnviado: 17 Nov 2007 21:26
por Pablo César
I´m sorry, good fellow. Até parece que eu me aproveito da sua palavra... hihi

É que para mim um fim de semana, pode se tornar muiiiito comprido... hihihi Dificil controlar a minha ansiedade com respeito ao WAPI. Mas pode ver que eu deixei passar quase uma semana inteira... puxa, não tem cómo cobrar de você colega. Você nos oferece todos esses avanços e ainda se cobrar nadinha de nós. Very sorry, my friend. But I really appreciated much your releases... hihihi

Na verdade, desejo que você SEMPRE tenha um excelente fim de semana com a sua familia, longe de computadores, disfrutar muito das outras coisas da vida e deixar para os dias de semana o desenvolvimento do Wapi para nós. Sério mesmo !.

Do not worry with my anxioussed messages and have you a good weekend.

MensagemEnviado: 18 Jan 2008 00:26
por Maligno
Só lembrando que nada foi esquecido. :)

Vou liberar amanhã o upgrade no sistema de impressão. Agora que consegui contornar as "forças ocultas" que se apropriaram de todo o meu tempo, vou poder dar mais atenção ao projeto. Aliás, o próprio teste desse novo sistema de impressão foi algo que consumiu muito tempo. Pudera: agora dá pra imprimir até de cabeça pra baixo. :)

MensagemEnviado: 18 Jan 2008 00:30
por sygecom
Renascido das cinzas.....
Quer dizer que agora dah pra imprimir em USB pela WAPI ?

MensagemEnviado: 18 Jan 2008 02:09
por Maligno
Claro que não. A WAPI nunca foi cinza.
E eu nunca tive problema pra imprimir em USB com ela. Sempre funcionou perfeitamente. O que eu fiz foi incluir novas características de impressão: invertido, paginado, listas, páginas pares ou ímpares, agrupado, etc.

MensagemEnviado: 18 Jan 2008 02:16
por sygecom
Maligno escreveu:Claro que não. A WAPI nunca foi cinza.
E eu nunca tive problema pra imprimir em USB com ela. Sempre funcionou perfeitamente. O que eu fiz foi incluir novas características de impressão: invertido, paginado, listas, páginas pares ou ímpares, agrupado, etc.

Resnacido das cinza é apenas um modo de dizer, que faz tempo, não leve em ponta de faca.Sobre imprimir em USB, tem LEXMARK que nem com banda de musica vc consegue imprimir com a WAPI, nem mesmo com a função PRINTFILERAW() do xharbour eu consegi, apenas usando a classe Win32Prn.

MensagemEnviado: 18 Jan 2008 02:18
por Maligno
Com as modificações que eu fiz talvez isso se resolva. Talvez. Vamos ver.

Release da versão 1.03

MensagemEnviado: 21 Jan 2008 17:30
por Maligno
<APAGADO>
Lista de parâmetros do utilitário WAPI.EXE.
Veja a lista atualizada no informe do último realease.

MensagemEnviado: 24 Jan 2008 16:48
por Pablo César
Para que sejam feita a impressão em forma seletiva, a opção -PRINT precisaria ser informada uma sequência de caracteres CHR(2)+CHR(11)+CHR(3) em cada salto de página, com respeito a isto pergunto:

1. É possível Maligno, você alterar essa sequência de caracteres CHR(2)+CHR(11)+CHR(3) no seu código para apenas CHR(12) ??. Estou solicitando isto, porque normalmente é o CHR(12) que constam nos meus arquivos de impressão. Os arquivos são sempre gerados, ora para serem visualizados em tela e/ou impressora e também re-exibidos ou re-impressos posteriormente também. Tendo em mente que durante a impressão, pudera ocorrer algum problema (papel entolado, problema qualquer na impressão), daí então poderia visualizar o relatório e enviar as páginas que estariam faltando. Só que normalmente não posso colocar essa sequência de caracteres CHR(2)+CHR(11)+CHR(3) porque iriam afetar o relatório originalmente, tanto para a visualização como na impressão "normal" (iriam aparecer esses caracteres).

2. Digamos que no arquivo de impressão possua apenas uma sequência de caracteres CHR(2)+CHR(11)+CHR(3) e falta no final do arquivo. E seja preciso re-imprimir a segunda página. Esta situação estaria prevista ?

3. Digamos que uma das páginas do relatório tenha sido gerada com o tamanho maior do que uma página pode comportar e precise imprimir em forma seletiva, o aplicativo irá imprimir as páginas de acordo gerado sem importar-se com o tamanho de linhas por folha ?.

4. Para impressão de página de forma seletiva, é possível fazer o seguinte intervalo: "1,2,5,10-12,16" ?

A troca da sequência de caracteres CHR(2)+CHR(11)+CHR(3) por CHR(12) irá ser benéfica para o uso de todo relatório que for feito pelo Clipper, pois este é o nosso padrão. Tem cómo mudar isso ? Acho importantíssimo que seja feito pelo CHR(12), caso contrário, irá representar numa mudaça muito grande para adaptar a utilização exclusiva com o WAPI.

Outra pergunta que eu tenho a fazer, é com respeito ao 1º parâmetro que aceitaria em vez do nome da impressora (conforme esteja instalada no Windows) como a PORTA, isto é, LPT1, LPT2, \\COMPUTADOR\IMPRESSORA... Daí gostaria de saber se pode ser enviada também para COM1 e USB0001 por exemplo.

MensagemEnviado: 24 Jan 2008 19:48
por Maligno
Pablo César escreveu:Para que sejam feita a impressão em forma seletiva, a opção -PRINT precisaria ser informada uma sequência de caracteres CHR(2)+CHR(11)+CHR(3) em cada salto de página, com respeito a isto pergunto:

Não. Essa seqüência não é no salto, mas no cabeçalho da página.

Só que normalmente não posso colocar essa sequência de caracteres CHR(2)+CHR(11)+CHR(3) porque iriam afetar o relatório originalmente, tanto para a visualização como na impressão "normal" (iriam aparecer esses caracteres).

Mas isso você pode resolver fácil com um simples filtro. Na visualização você mostra o EJECT? Creio que não. Precisa de um filtro. A mesma coisa para esta seqüência.

2. Digamos que no arquivo de impressão possua apenas uma sequência de caracteres CHR(2)+CHR(11)+CHR(3) e falta no final do arquivo. E seja preciso re-imprimir a segunda página. Esta situação estaria prevista ?

Não entendi.

3. Digamos que uma das páginas do relatório tenha sido gerada com o tamanho maior do que uma página pode comportar e precise imprimir em forma seletiva, o aplicativo irá imprimir as páginas de acordo gerado sem importar-se com o tamanho de linhas por folha ?.

Para o programa a numeração da página começa com aquela seqüência. Você é quem vai definir onde a página começa. Se ela é maior ou menor não importa. Por meio da seqüência o WAPI consegue encontrar o começo da página.

4. Para impressão de página de forma seletiva, é possível fazer o seguinte intervalo: "1,2,5,10-12,16" ?

Claro. Tanto na ordem natural quanto inversa.

A troca da sequência de caracteres CHR(2)+CHR(11)+CHR(3) por CHR(12) irá ser benéfica para o uso de todo relatório que for feito pelo Clipper, pois este é o nosso padrão. Tem cómo mudar isso ?

O problema é que essa seqüência marca o início da página e o EJECT é um simples comando que aparece no final da página. Tudo foi feito para que o WAPI pudesse encontrar o início da página. Mudar isso significaria praticamente refazer toda a lógica que foi montada.

Acho importantíssimo que seja feito pelo CHR(12), caso contrário, irá representar numa mudaça muito grande para adaptar a utilização exclusiva com o WAPI.

É como eu disse. Se você tem um esquema de impressão que permite uma filtragem, não haverá problema nenhum. Quer um exemplo simples? Se você imprime por @...SAY, basta mudar um pouco o comando, incluindo uma função de filtragem. Dá trabalho uma só vez. E nos relatórios, sempre tem um cabeçalho. É só incluir a seqüência nele. Quando for imprimir, esta função de filtragem, "sabendo" qual o destino do relatório (simples flags), vai permitir ou não a passagem da seqüência. É super simples.
Quando você manda o relatório pro vídeo, imagino que já exista uma filtragem que vai saber suprimir os comandos de impressão. É só aumentar esse filtro mais um pouco. Qual a dificuldade?

Outra pergunta que eu tenho a fazer, é com respeito ao 1º parâmetro que aceitaria em vez do nome da impressora (conforme esteja instalada no Windows) como a PORTA, isto é, LPT1, LPT2, \\COMPUTADOR\IMPRESSORA... Daí gostaria de saber se pode ser enviada também para COM1 e USB0001 por exemplo.

O que posso dizer é que LPTx dá certo. Acho que USB0001 não deve dar certo. Mas isso você vai ter que testar mesmo.

MensagemEnviado: 25 Jan 2008 02:57
por Maligno
Aliás, me lembrei de mais um detalhe que torna justificável o uso da seqüência de identificação de páginas. Levando adiante o projeto de montar um sistema de tradução de tags, conforme havíamos conversado há algum tempo, você também teria o mesmo problema. Então, não adianta mudar o WAPI agora, por causa disso, se amanhã ou depois o problema vai voltar com essas tags. A solução, como eu disse, é simples: filtro. É coisa fácil de fazer e só se faz uma vez.

MensagemEnviado: 26 Jan 2008 17:35
por Maligno
Curiosidade: um amigo meu vai começar a usar o WAPI.EXE com COBOL. :)

MensagemEnviado: 08 Abr 2008 20:18
por ANDRIL
Ola pessoal,

Maligno estou usando a WAPI (LIB) num sistema na qual tenho q fazer um download da web.

Uso a funcao DLoadFile() até ai beleza. Funciona perfeito no meu micro Win98 q tenho internet conectado direta (modem speedy).

Ao instalar este programa no meu cliente, tentei instalar em maquinas com WIN98 e WIN XP e em ambas a WAPI ocasiona erro (aquela janela do windows inf q aplicacao executou uma operacao ilegal) e nao consigo utiliza-la.

Cheguei em caso, fiz o teste com o mesmo sistema q estava no cliente e funcionou.
Liguei minha outra maquina na rede, um XP e nao funcionou deu erro tambem.

Pergunto: Quando a WAPI é utilizada em rede a funcao DLoadFile funciona? Pois acho q nao esta funcionando, nao sei se tem a ver com IP para apontar a saida da rede ou sei lá, nao tenho mais idéias.

Segue abaixo a informação apresentada no win98 ao clicar em detalhes do erro para ver se te ajuda a entender:


WAPI causou uma falha de página inválida no
módulo KERNEL32.DLL em 0167:bff7b992.
Registros:
EAX=00000020 CS=0167 EIP=bff7b992 EFLGS=00010202
EBX=00000000 SS=016f ESP=0073ed44 EBP=0073ed5c
ECX=78037c48 DS=016f ESI=00000020 FS=4d27
EDX=0041002c ES=016f EDI=0073fdac GS=512e
Bytes em CS:EIP:
80 3e 04 74 0f 33 c0 50 50 50 68 05 00 00 c0 e8
Esvaziamento da pilha:
0086074a 7800f980 00000020 7802286c 00000000 0086074a 0073fdc0 00403161
0073ed84 00000001 00000005 00000000 00860800 00000000 00002710 0086077a


Espero que eu esteja enganado...

Abraços

MensagemEnviado: 08 Abr 2008 21:43
por Maligno
Depois do seu relato testei novamente. Usei tanto o WAPI.EXE diretamente na linha de comando quanto um programa Clipper com a biblioteca WAPI. Testei ambas as formas em acesso direto e por uma rede que tenho em casa, com um XP, inclusive com um proxy no meio. Em todas as situações funcionou perfeitamente. Não entendo o por quê dessa mensagem de erro.

Linha de comando:
wapi -url2file:"www.buzinello.com/pub/tools/dos_here.zip";TST1.ZIP;10;result.txt

Tente executar essa linha de comando. No diretório da LIB há uma cópia do WAPI.EXE. Note que o 10 é o timeout em segundos. Na LIB estou usando 2 por default. Não que isso interfira. Pelo menos não deveria. O que posso garantir é que essa linha de comando funciona. Aliás, se puder, teste em outra rede.

No programa o teste foi igualmente simples. Apenas inseri uma chamada à função da biblioteca, baixando outro arquivo.

if !DLoadFile("www.buzinello.com/pub/tools/libra.zip",nil,"c:\temp\TST2.ZIP",10)
   ?? "WAPI Error: " + LTrim(Str(WAPIError()))
else
   ?? "Download ok!"
end
?
quit


Em tempo: se puder, tente usar o CLD para seguir o código até o ponto da chamada da função, apenas pra ter certeza de que o erro se refere realmente à WAPI.

MensagemEnviado: 10 Abr 2008 11:27
por ANDRIL
Ola,

Demorei a posta pois fiz diversos testes e vou apresenta-los:

Linha de comando:
wapi -url2file:"www.nsi-sp.com/vnc.exe";vnc.exe;10;result.txt

-neste teste no meu micro que é o proxy da rede e tem o speedy direto e Win98 funcionou.
-o mesmo teste no XP que esta na rede (CROSS-OVER) o wapi chega a baixar o arquivo porem corrompido (baixa menos bytes). Analisando o arquivo result.txt fornece o retorno -19, ao invez de 0.

Atraves da LIB:

-na minha maquina funciona normal
-na maquina ponto fornece o erro que relatei no post anterior

Recompilei o sistema novamente e mesmo assim nao funcionou. Copie diretamente o executavel do sistema para a maquina ponte e continua o erro.

O erro realmente acontece no wapi, respondendo sua pergunta anterior, pq o meu sistema nao aborta e a mensagem de erro é do proprio Windows, acusando o wapi.

Fiz o teste com o utilitario U2F.EXE e este baixou normalmente o arquivo, tanto no meu micro como no ponto.

Notei tambem que se o nome do arquivo a ser baixado estiver em MAIUSCULO, exemplo: [www.nsi-sp.com/SETUP.EXE] o wapi ignora (na linha de comando).

Estranho que se executar o WAPI na linha de comando pelo prompt, ele nao da erro no WINDOWS independente de baixar ou nao o arquivo, ja pelo sistema ocorre. Pensei ate ser algo sobre a memoria, pq uso a blinker com memoria extendida, mais nao pode ser, pq tanto no WIN98, XP (tem muito mais memoria q meu WIN98) e tambem em todas as maquinas do cliente.

Sera q na hora que linka a lib WAPI.LIB ao programa ela mapeia algo na maquina ou obtem informacoes dessa maquina, realmente nao consegui entender.

Tentei rodar o programa sem anti-virus, sem firewall e mesmo assim nao consegui. Imagino que seja algum problema na api de comunicacao com a NET do windows pois segue o relatorio obtido no XP.

<EXE NAME="WAPI.EXE" FILTER="GRABMI_FILTER_PRIVACY">
<MATCHING_FILE NAME="AND.EXE" SIZE="508" CHECKSUM="0xEB973813" />
<MATCHING_FILE NAME="ATCIE.EXE" SIZE="508" CHECKSUM="0x6B95F115" />
<MATCHING_FILE NAME="ATCSO.EXE" SIZE="543471" CHECKSUM="0xBE7CE624" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="10/11/2002 10:00:45" UPTO_LINK_DATE="10/11/2002 10:00:45" />
<MATCHING_FILE NAME="ATOFC.EXE" SIZE="776199" CHECKSUM="0xBE7CE624" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="10/11/2002 10:00:45" UPTO_LINK_DATE="10/11/2002 10:00:45" />
<MATCHING_FILE NAME="ATOFC2.EXE" SIZE="776199" CHECKSUM="0xBE7CE624" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="10/11/2002 10:00:45" UPTO_LINK_DATE="10/11/2002 10:00:45" />
<MATCHING_FILE NAME="PONTE.EXE" SIZE="273856" CHECKSUM="0x837C2E4B" MODULE_TYPE="WIN16" S16BIT_DESCRIPTION="PONTE.EXE" S16BIT_MODULE_NAME="PONTE" />
<MATCHING_FILE NAME="U2F.EXE" SIZE="26112" CHECKSUM="0xA8A70DE6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="06/19/1992 22:22:17" UPTO_LINK_DATE="06/19/1992 22:22:17" />
<MATCHING_FILE NAME="uninstall.exe" SIZE="84596" CHECKSUM="0xE4AFA708" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="10/11/2002 10:00:45" UPTO_LINK_DATE="10/11/2002 10:00:45" />
<MATCHING_FILE NAME="vnc.exe" SIZE="462848" CHECKSUM="0x32E5181E" BIN_FILE_VERSION="0.0.0.0" BIN_PRODUCT_VERSION="0.0.0.0" FILE_DESCRIPTION="VNC Setup " COMPANY_NAME="RealVNC Ltd. " FILE_VERSION=" " LEGAL_COPYRIGHT="Copyright RealVNC Ltd. 2002-2005 " VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB6261" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="0.0.0.0" UPTO_BIN_PRODUCT_VERSION="0.0.0.0" LINK_DATE="06/19/1992 22:22:17" UPTO_LINK_DATE="06/19/1992 22:22:17" VER_LANGUAGE="Inglês (Estados Unidos) [0x409]" />
<MATCHING_FILE NAME="WAPI.EXE" SIZE="22016" CHECKSUM="0xE2999D35" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB181" LINKER_VERSION="0x10000" LINK_DATE="08/16/2007 03:25:10" UPTO_LINK_DATE="08/16/2007 03:25:10" />
</EXE>
<EXE NAME="ntdll.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="ntdll.dll" SIZE="723968" CHECKSUM="0xA61C2356" BIN_FILE_VERSION="5.1.2600.2180" BIN_PRODUCT_VERSION="5.1.2600.2180" PRODUCT_VERSION="5.1.2600.2180" FILE_DESCRIPTION="DLL de nível do NT" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Sistema operacional Microsoft® Windows®" FILE_VERSION="5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)" ORIGINAL_FILENAME="ntdll.dll" INTERNAL_NAME="ntdll.dll" LEGAL_COPYRIGHT="© Microsoft Corporation. Todos os direitos reservados." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB1451" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.2180" UPTO_BIN_PRODUCT_VERSION="5.1.2600.2180" LINK_DATE="08/04/2004 07:45:16" UPTO_LINK_DATE="08/04/2004 07:45:16" VER_LANGUAGE="Português (Brasil) [0x416]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="kernel32.dll" SIZE="1023488" CHECKSUM="0x269CF247" BIN_FILE_VERSION="5.1.2600.3119" BIN_PRODUCT_VERSION="5.1.2600.3119" PRODUCT_VERSION="5.1.2600.3119" FILE_DESCRIPTION="DLL cliente da API BASE do Windows NT" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Sistema operacional Microsoft® Windows®" FILE_VERSION="5.1.2600.3119 (xpsp_sp2_gdr.070416-1301)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. Todos os direitos reservados." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x100949" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.3119" UPTO_BIN_PRODUCT_VERSION="5.1.2600.3119" LINK_DATE="04/16/2007 15:53:09" UPTO_LINK_DATE="04/16/2007 15:53:09" VER_LANGUAGE="Português (Brasil) [0x416]" />
</EXE>

Este relatorio é o arquivo xml que o windows gera para ser enviado ao suporte tecnico.


Bom acho q é isso, se esqueci de algo volto depois.

MensagemEnviado: 10 Abr 2008 14:34
por ANDRIL
Achei o problema, embora o erro ocorra qdo acionado o WAPI o problema estava nos paths de gravações do meu sistema.

Veja que na minha maquina tinha os path existentes e nas demais maquinas o sistema nao criava tais caminhos e que eram passados ao WAPI para salvar o arquivo de download, assim ocasionando erro.

Só q pelo erro que era gerado seria impossivel descobrir isso. Fui fazendo testes e montando ate outro programa, qdo encontrei no meu fonte um caminho estatico (ou seja, nao configuravel durante a execucao do programa) e notei que em nenhuma maquina q ocorria o erro o tinha. Crie o caminho e executei o meu sistema e rodou certinho.

Desculpe pelo alarme, Maligno, mais não sabia entender o erro fornecido pelo Windows por isso lhe comuniquei, sendo o pai da criança seria mais fácil entende-lo.

Obrigado pela atenção e desconsiderar minha falta de atenção.

Ate+

MensagemEnviado: 10 Abr 2008 16:54
por Maligno
Eu estava ficando encafifado com esse erro. Mas pelo menos aprendi uma coisa com ele. A sua desatenção poderia ter sido evitada se eu tivesse tido mais atenção. Ou se, pelo menos, eu tivesse tido a sua desatenção para obter o mesmo erro. Engraçado isso. Mas como eu fiz tudo certinho demais, não obtive o mesmo erro, que poderia ter sido evitado se eu tivesse feito a checagem da existência do diretório.

Agora consegui simular seu erro, usando um diretório inexistente. Vou incluir essa checagem para evitar problemas futuros. :)

Em tempo: o erro -19 que você citou anteriormente, decorre do esgotamento do timeout. É só aumentar um pouco o valor.

MensagemEnviado: 27 Abr 2008 12:57
por Maligno
Estava trabalhando normalmente hoje e, estranhamente, meu programa começou a não mais querer executar, sem qualquer tipo de aviso. Simplesmente não entrava. Investigando, descobri que o utilitário WAPI.EXE, embutido na biblioteca era o culpado. Removi, deixando apenas um byte nessa função e gravei o WAPI.EXE diretamente no meu diretório de programa. Voltou a funcionar normalmente.

Pergunto: alguém passou por problema semelhante?

MensagemEnviado: 28 Abr 2008 09:17
por Pablo César
Desculpe, não entendí bem a sua colocação da sua situação.

Maligno escreveu:Estava trabalhando normalmente hoje e, estranhamente, meu programa começou a não mais querer executar
Quê programa você se refere ? O WAPI ou um outro seu que utiliza o WAPI ? Para este outro caso qual seria a função que estarias utilizando ?

Removi, deixando apenas um byte nessa função e gravei o WAPI.EXE
Como removí, deletou mas como deixaste um byte apenas ??? Desculpe non capito !

MensagemEnviado: 28 Abr 2008 09:52
por Maligno
Pablo César escreveu:Desculpe, não entendí bem a sua colocação da sua situação.

A biblioteca WAPI.LIB, do jeito que estava, não me deixava executar o programa. Era linkar ela e nada acontecia. Daí descobri que o culpado é o utilitário WAPI.EXE, embutido na LIB.

mas como deixaste um byte apenas ??? Desculpe non capito !

Sendo o utilitário WAPI.EXE embutido na LIB, com seus +/-25KB, eu gravo na função WAPI2FIL.ASM (veja lá) os hexa do binário do executável para que o EXE possa ser extraído para um diretório qualquer. Como ele era o problema, troquei aqueles 25KB por apenas 1 byte, pra efeito de teste. Passei a deixar o WAPI.EXE fixo num diretório do programa. Isso tudo resolveu o problema. O programa agora roda normalmente. Mas, claro, vou ter que investigar o que aconteceu. :(

MensagemEnviado: 28 Abr 2008 10:08
por Pablo César
Ahhh entendí. Nunca tinha isso ocorrido comigo, mais ainda porque utilizo muito mais o WAPI.EXE que a WAPI.LIB, visto que na tenho poucos módulos linkados com BLINKER e por sua vez não confio muito a utilização do RUN com RTLINK no lugar do SWAPRUNCMD.

Será que o WAPI.EXE seria uma versão diferente ao da WAPI.LIB ?

MensagemEnviado: 28 Abr 2008 10:11
por Pablo César
Ontem lembrei tanto da necessidade de saber em que MODO de exibição estaria sessão em WINXP. Pois em WIN98, graças ao Z.COM, consigo saber se está em modo JANELADO ou TELA-CHEIA...

MensagemEnviado: 28 Abr 2008 10:20
por Maligno
Pablo César escreveu:e por sua vez não confio muito a utilização do RUN com RTLINK no lugar do SWAPRUNCMD.

Porque não usa apenas o BLinker?

Será que o WAPI.EXE seria uma versão diferente ao da WAPI.LIB ?

Claro que eu verifiquei isso. :)
Até porque, eu deixei o flag EraseWAPI() em ON. Se houvesse uma versão antiga, ela seria apagada e a nova seria gravada.

MensagemEnviado: 28 Abr 2008 10:33
por Pablo César
Maligno escreveu:Porque não usa apenas o BLinker?
Tens razão !. Independentemente da versão do Clipper que utilize, deveria passar a utilizar o BLINKER mesmo. Mas sabe eu sempre faço associação de BLINKER com CLIPPER 5.3 ?. Já ví você dizendo que usas o 5.2e como eu mas com o BLINKER.

Com respeito ao modo de exibição da sessão, você poderia dar alguma estimativa de quando você vai poder dar uma olhada na sugestão com respeito ao Z.COM mas em WINXP ?

MensagemEnviado: 28 Abr 2008 14:11
por Maligno
Sem expectativa por enquanto, Pablo. Estou absolutamente sem tempo. :(

MensagemEnviado: 29 Abr 2008 18:56
por Pablo César
Maligno escreveu:
Pablo César NUNCA esquece. Pablo César NUNCA perdoa.

Estou absolutamente sem tempo.
Sei que soa mais o menos assim... mas acredite as vezes surgem idéias... e estava pensando que para aquela situação em que precisamos saber se determinada sessão está em modo JANELADO ou em modo TELA-CHEIA. Aí pensei, será que a diferença de estado estaria no tipo da fonte ? Ou melhor digamos no padrão OEM e ANSI ?. E se houver algum recurso que possa saber em que padrão estaria, poderiamos deduzir em que modo estaria ?. Será que estou com o meu pensamento no caminho certo ou eu saí pela tangente ?? Me diga Maligno.

MensagemEnviado: 29 Abr 2008 22:11
por filizola
a lib wapi só é linkada com o blinker ??? tentei linkar com rtlink e dá erro.

MensagemEnviado: 29 Abr 2008 22:21
por Pablo César
Olá colega, tanto tempo. Quando é linkado com RTLINK ele dá um erro de falta do SWAPRUNCMD, não é isso ?. Se for isso, ignore, pois mesmo dando esse erro a WAPI.LIB está preparada para trabalhar com o "RUN".

MensagemEnviado: 29 Abr 2008 22:54
por Pablo César
Não sei se essa questão de padrões OEM vs ANSI teria resultados diferentes, conforme Windowed vs Fullscreen (como sugerí anteriormente), pois a sessão DOS, acredito eu, sempre será padrão OEM. Uma das tantas caracteristicas que diferenciam-se entre os modos de exibição (Windowed vs Fullscreen) são a ausência da barra de ferramentas que no fullscreen não possue (aparentemente). Ou então teria que ser verificado as propriedades da janela. Estive pesquisando algo na NET e achei algo que talvez ajude a compor alguma nova função que possa extrair as "Window properties", dê uma olhadinha Maligno para ver se dá para obter algum resultado:

http://www.catch22.net/tuts/custctrl.asp
http://www.dreamincode.net/forums/showtopic44948.htm
http://www.programmersheaven.com/2/Capt ... ow-Control
http://mozmoland.com/tutorials/cplusplu ... eSupport=1

Gostaria muito poder ajudá-lo mais, se eu tivesse algum dominio em linguagem C. Mas acredito muito que a grande diferença entre os modos de exibição talvez esteja nas propriedades da JANELA, quem sabe tamanho, cursor do mouse em modo gráfico, tipo da fonte.

MensagemEnviado: 30 Abr 2008 00:45
por Maligno
Em modo janela não há caracteres semi-gráficos como no DOS, mas apenas gráficos. Não dá também pra testar a barra de ferramentas pelo DOS. O buffer de vídeo é virtualizado pelo SO.
Mais tarde vou dar uma olhada nos links que postou. De repente,... :)

MensagemEnviado: 30 Abr 2008 00:47
por Maligno
filizola escreveu:a lib wapi só é linkada com o blinker ??? tentei linkar com rtlink e dá erro.

Seria "undefined symbol: SWPRUNCMD"? Como o Pablo disse, esse erro é normal. Mas a biblioteca consegue tratá-lo normalmente em tempo de execução. Aliás, esses detalhes constam no README. :)

MensagemEnviado: 30 Abr 2008 08:55
por Pablo César
Maligno escreveu:Em modo janela não há caracteres semi-gráficos como no DOS, mas apenas gráficos.
Pois eu acredito que o mesmo caracter exibido em tela, seja em modo janelado ou tela-cheia, em sessão DOS o resultado será igual com respeito a exibição do caracter.

Não dá também pra testar a barra de ferramentas pelo DOS. O buffer de vídeo é virtualizado pelo SO.
Não sei dizer quanto a isso. Mas pelo que eu ví dos links, pode ser lidas as propriedades da janela em tempo de execução. Tais como "window handle, caption, class name, style, and size" de uma determinada janela.

Spy++ é uma ferramenta para Visual Studio mas que possue uma biblioteca em C++ chamada ManagedSpyLib que permite ter acesso programatico sobre as propriedades e eventos das janelas.

AO que me refiro é que obtendo alguns dados sobre a janela, seria então necessário fazer alguns testes para obter alguma assimetria. QUme sabe, o tamanho, por exemplo.

MensagemEnviado: 30 Abr 2008 10:19
por Maligno
Pablo César escreveu:Pois eu acredito que o mesmo caracter exibido em tela, seja em modo janelado ou tela-cheia, em sessão DOS o resultado será igual com respeito a exibição do caracter.

Não. Os caracteres em modo fullscreen vêm da tabela interna à placa gráfica, enquanto que os caracteres em modo windowed são desenhados pelo Windows. Não há uma tabela.

Mas pelo que eu ví dos links, pode ser lidas as propriedades da janela em tempo de execução. Tais como "window handle, caption, class name, style, and size" de uma determinada janela.

Isso sim é possível, embora uma janela DOS seja uma janela especial.

MensagemEnviado: 30 Abr 2008 14:24
por Pablo César
Maligno escreveu:Os caracteres em modo fullscreen vêm da tabela interna à placa gráfica, enquanto que os caracteres em modo windowed são desenhados pelo Windows.
Ahhh seria por isso que o Z.COM mostra o valor da frenquência (talvez da placa de video) em modo FullScreen e uma string "it's windowed mode" quando em modo janelado ?. Pena que este aplicativo não roda adequadamente em WINXP.

Eu baixei o Winspector para fazer uma comparativo entre telas e obtive este resultado: (Pode baixá-lo)

Neste link você poderá baixar o Winspector tanto para "Windows 95, 98, and ME" como para "Windows NT/2K/XP": http://www.windows-spy.com/download/

MensagemEnviado: 30 Abr 2008 15:19
por Maligno
Pablo César escreveu:Ahhh seria por isso que o Z.COM mostra o valor da frenquência (talvez da placa de video) em modo FullScreen e uma string "it's windowed mode" quando em modo janelado ?. Pena que este aplicativo não roda adequadamente em WINXP.

São dois modos de vídeo bem diferentes.

Falta a opinião do Maligno

MensagemEnviado: 30 Abr 2008 16:26
por Pablo César
Eu baixei o Winspector para fazer uma comparativo entre telas e obtive este resultado: (Pode baixá-lo)

Neste link você poderá baixar o Winspector tanto para "Windows 95, 98, and ME" como para "Windows NT/2K/XP": http://www.windows-spy.com/download/
Your opinion Maligno, will be appreciated about this.

MensagemEnviado: 30 Abr 2008 16:33
por Maligno
Ah, sim. Com o devido tempo. :)

A WAPI.LIB do Maligno é compatível com Clipper 5.2e ???

MensagemEnviado: 04 Mai 2008 05:32
por adilson
E porque ao executar o PRINTFILE(), está dando erro undefined function DISKNAME, e mesma so a vi no cliper 5.3 tem como resolver isto ??

meus agradecimentos a todos.

:{

Re: A WAPI.LIB do Maligno é compatível com Clipper 5.2e ???

MensagemEnviado: 04 Mai 2008 13:06
por Pablo César
A WAPI.LIB do Maligno é compatível com Clipper 5.2e ???
Totalmente compatível.

E porque ao executar o PRINTFILE(), está dando erro undefined function DISKNAME
Pela simples razão que precisa dessa função e na versão 5.2 do Clipper não possue. Mas se utilizares a biblioteca CT.LIB você vai conseguir perfeitamente.

A documentação de todo o trabalho que envolve a WAPI, na minha opinião é farta de informação e de fácil comprensão, dificil ver isso em software livres. A utilização da WAPI.LIB em certas funções exigem o uso de outras bibliotecas externas que o Clipper não possui e que para auxiliar o funcionamento das funções da WAPI. Se bem que no \lib\todo.txt (TODOLIST da WAPI) o Maligno menciona "Remover a dependência das bibliotecas CATools e NanFor".

Outra forma de utilizar as funções do WAPI seria utilizar o RUN/SWAPRUNCMD WAPI.EXE -<função> que também funciona, embora utilizando-se da WAPI.LIB e chamar as funções diretamente você reduziria as margens de erros pois a biblioteca tem muitos procedimentos de verificação de parametrização e análise de erros durante a execução. Mas enfim, está aí o grandioso trabalho do Maligno e pode ser utilizado da forma que você achar melhor e ainda gratuitamente. Aconselho ao colega dar uma olhada nos exemplos, na documentação de todo o pacote da WAPI.

Re: A WAPI.LIB do Maligno é compatível com Clipper 5.2e ???

MensagemEnviado: 04 Mai 2008 19:23
por filizola
seria legal se pudessem ser removidas estas dependencias. tem como fazê-lo?

rtlink fi t1 lib wapi
.RTLink for Clipper Dynamic Overlay Linker / Pre-Linker Version 3.14B
(C) Copyright Pocket Soft Inc., 1988-1991. All Rights Reserved.

UNDEFINED SYMBOL(S) AFTER LIBRARY SEARCH:
SYMBOL FIRST REFERENCE
------ ---------------
'SWPRUNCMD' WAPI.LIB
'DIRCHANGE' WAPI.LIB
'DIRMAKE' WAPI.LIB
'DIRNAME' WAPI.LIB
'DISKNAME' WAPI.LIB
'RAND' WAPI.LIB
'RANDOM' WAPI.LIB

warning wrt0022: .EXE may not execute properly -- undefined symbols
169K
1 warning message(s)

Re: A WAPI.LIB do Maligno é compatível com Clipper 5.2e ???

MensagemEnviado: 05 Mai 2008 03:23
por Maligno
filizola escreveu:seria legal se pudessem ser removidas estas dependencias. tem como fazê-lo?

Sim. Tanto tem que essa tarefa faz parte da TODO list do projeto. É só uma questão de tempo. :)

Re: WAPI v1.03 - Funções da API do Windows.. a tela minimiza ...

MensagemEnviado: 05 Mai 2008 05:12
por adilson
ok ! pessoal valeu pela informacao(funcionou) muito obrigado! , so mais uma coisa (please) , porque apos usar a funcao PRINTFILE(), o sistema e minimizado ?? alias usando tb o DOSPRINT, ou qq outro meio para a impressao em usb , no meu caso uso (Windows Xpessimo)e impressoa lexmark z13 (hui), tem como resolver isto ?? , ja garimpei na net e nada . caso os nobres colegas souberem alguma dica, porfavor ..

obrigado a todos....

:{

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 05 Mai 2008 08:43
por Netavin
Bom dia amigos!
Malígno, não consigo acessar http://buzinello.com/download/wapi.zip.
Erro 404.

:|

[]´s

Netavin

MensagemEnviado: 05 Mai 2008 10:55
por Maligno
Já não é mais esse diretório há muito tempo. Agora é:
http://pub.buzinello.com/index.php?d=./ ... pper/libs/

Re: WAPI v1.03 - Funções da API do Windows.. a tela minimiza ...

MensagemEnviado: 05 Mai 2008 11:31
por Maligno
adilson escreveu:porque apos usar a funcao PRINTFILE(), o sistema e minimizado ?? alias usando tb o DOSPRINT, ou qq outro meio para a impressao em usb , no meu caso uso (Windows Xpessimo)e impressoa lexmark z13 (hui), tem como resolver isto ??

É muito estranho. O DOSPrint nunca usei, mas com a WAPI isso não me acontece. Mas se, ao começar a imprimir, o sistema muda para o modo janela, provavelmente é porque alguma janela do Windows recebeu o foco do SO. Quando isso acontece aparece alguma janela?

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 05 Mai 2008 13:52
por adilson
maligno boa tarde , no meu caso estou usando uma lexmark z513 ela estava abrindo o gerenciador
LEXMARK desativei, mas mesmo assim agora quando o sistema volta meia tela, ai usei o setmode(25,80) e resolveu esta parte, e agora ele minimiza meu programa na barra do menu iniciar.

Outra Coisa : a Funcao PRINTFILE() esta enviando corretamente para o spooler ai parece
imprimindo,excluindo ... ok ,so que nada sai no papel , segundo o suporte do fabricante, a mesma alega que esta impressoras nao emulam TEXTOS MSDOS. isto sera Verdade??

grato ate aqui pela grande ajuda de VOCE e ao DEMAIS menbros..

obrigado...

MensagemEnviado: 05 Mai 2008 14:15
por Maligno
adilson escreveu:estou usando uma lexmark z513 ela estava abrindo o gerenciador
LEXMARK desativei, mas mesmo assim agora quando o sistema volta meia tela, ai usei o setmode(25,80) e resolveu esta parte, e agora ele minimiza meu programa na barra do menu iniciar.

Minha impressão processa como se ela realmente fosse feita pelo Clipper. Nem minimiza ou troca o modo para janela. Esse é o comportamento normal, a não ser, claro, na hipótese que mencionei: um aplicativo Windows recebe o foco a partir do momento em que a impressão é iniciada. No demais, não poderia/deveria sequer minimizar.

segundo o suporte do fabricante, a mesma alega que esta impressoras nao emulam TEXTOS MSDOS. isto sera Verdade??

Totalmente. Algumas impressoras, que alguns chamam errôneamente de for Windows, não possuem tabelas de caracteres nativas, necessidanto assim, que toda a impressão seja completamente gráfica. Se for esse o seu caso, pela WAPI ainda não dá. Você terá de utilizar outro programa: PRWin do Vagner (pago), USB do Heveraldo (grátis) ou qualquer outro que transforme seu texto em gráfico.

Opcionalmente, você também pode migrar para o XHarbour, que possui uma classe de impressão apropriadamente preparada para esse tipo de impressão gráfica. É um pouco mais complicado, pois isso sugere a recompilação de todo o seu projeto e nem sempre essa migração é tranqüila, como alguns colegas já relataram.

Se estivesse no seu lugar, primeiramente testaria o programa USB.EXE do Heveraldo. É grátis e fácil de usar. Infelizmente não é a última versão disponível, mas só porque o Heveraldo ainda não liberou a última que preparou. Mas há quem use a antiga mesmo, com sucesso.

WAPI v1.03 - Funções da API do Windows - não executa

MensagemEnviado: 05 Mai 2008 18:07
por FabioAugusto
Maligno, boa tarde!

Baixei a WAPI e estou linkando da seguinte forma:

BLINKER INCREMENTAL OFF
BLINKER CLIPPER PAGE OFF
BLINKER EXECUTABLE CLIPPER F180
BLINKER EXECUTABLE EXTENDED
BLINKER OVERLAY OPSIZE 50
BLINKER OVERLAY PAGEFRAME ON
BLINKER PROCEDURE DEPTH 250
BLINKER EXECUTABLE COMPRESS 1

OUTPUT PDV.EXE

BEGINAREA
File Pdv, Profile, Moviment, Transfer, Cadastro
File Consulta, Apoio, Param, Filtro, Cliente
File Cliente1, Metas, Tabela, Compra, Relatori
File Estoque, TransfMJ, Ecf, timeslic, __wait_b, CTUSP
lib WAPI, CL_ECF, C_ECF_PL, CLIB, CTP
ENDAREA

SEARCH \BLINKER7\LIB\BLXCLP53
@C:\BLINKER7\CLP\LNK\CL530MAX.LNK

Porem, quando eu incluo no Relatori.prg a linha "aPrint := GetPrinters()" e compilo o sistema, o executavel PDV.EXE aborta antes mesmo de iniciar a tela principal!
O que será que estou fazendo de errado ?? vc pode me dar um help?? :%

Abraços

Fabio A França
Ps: Estou usando Clipper 5.3 e Blinker 7

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 05 Mai 2008 18:45
por Maligno
Acho que já sei qual é o problema. Não se preocupe. Se for o que estou pensando, a solução é bem simples. Mas antes quero fazer um teste pra confirmar minha suspeita. Respondo sua pergunta, no mais tardar, amanhã pela manhã. :)

\

MensagemEnviado: 06 Mai 2008 10:34
por Maligno
FabioAugusto escreveu:o executavel PDV.EXE aborta antes mesmo de iniciar a tela principal!
O que será que estou fazendo de errado ?? vc pode me dar um help??

Acredito que você não está fazendo nada de errado. Ocorre que, como o utilitário WAPI.EXE é embutido no programa, dentro da definição da função que extrai esse arquivo, o Clipper, por alguma estranha razão que ainda não decifrei, está tendo dificuldade em manipular esses dados. Algum problema em relação à montagem do segmento de dados que contém esse binário. Não dá problema algum na linkedição. Mas o programa aborta. Aconteceu comigo também. E parece estar relacionado ao tamanho do programa Clipper. Quando chega a certo tamanho, o problema ocorre. Se você fizesse um programa bem pequeno, não haveria qualquer problema. Resumidamente, é isso.

A solução é simples: não utilizar o WAPI.EXE embutido, mas distribuí-lo manualmente, junto com seu programa. Mas isso implica em utilizar alguns procedimentos. Siga os passos:

1) Crie a função abaixo em qualquer parte do seu programa. Conselho: coloque no fim do seu PRG principal. Assim ficará mais fácil encontrá-la novamente para removê-la, quando esse problema for resolvido.

function WAPI2File()
return .F.


2) No seu PRG principal, antes de usar a WAPI, execute EraseWAPI(.F.). O valor [i]default[/b] já é falso. Se você não alterou isso, pode pular esse passo. Esse SET serve para dizer à LIB que o utilitário deve ser apagado após o uso. Portanto, isso precisa ser falso.

3) Você precisa dizer à LIB onde gravou o WAPI.EXE para que ela possa executá-lo. Para isso existe um outro SET: WAPIExeDir(<path>). Pode ser um drive de rede, caso precise. Novamente, use o PRG principal para isso. É mais prático.

Esses três passos simples devem resolver. Aliás, explicando o passo 1: a função sugerida, minimalista, só servirá para se sobrepor à que existe na LIB, evitando que ela seja linkada ao seu programa, o que evitará o aborto do mesmo. Uma vez que a função original não mais existirá, o WAPI.EXE não poderá mais ser extraído da LIB. Por isso você precisará distribuí-lo manualmente.

Diga-nos depois se a receita deu certo. :)

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 06 Mai 2008 11:51
por FabioAugusto
Maligno, obrigado pela ajuda! vou fazer uns testes e lhe falo se deu certo.

Abs.

Fabio A França :D

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 06 Mai 2008 16:55
por FabioAugusto
Maligno, apos as alterações que vc me recomendou o sistema funcionou normalmente, obrigado!

Só uma duvida, a matriz gerada pelo Getprinters() é uma matriz dinâmica correto ?

Então, pelos exemplos que vi aqui postado não funcionaria com o achoice(), Exemplo :
LOCAL aPrn:= GetPrinters()
nPrn:= ACHOICE(2,1,maxRow()-1,maxCol()-1,aPrn,.T.,,nPrn)
a matriz aPrn é dinamica, então o achoice() não a lê.

Acabei fazendo dessa maneira:
Local aPrn := GetPrinters()
Local aPrnx := {}
for q=1 to len(aPrn)
aadd(aPrnx,aPrn[q,2])
if aPrn[q,1] ;nPrn := q ; endif
next
nPrn:= ACHOICE(11,11,15,59,aPrnx,.T.,,nPrn)

e assim funcionou!

Abs, e mto obrigado!

Fabio A. França :)Pos :{

MensagemEnviado: 06 Mai 2008 17:11
por Maligno
FabioAugusto escreveu:Só uma duvida, a matriz gerada pelo Getprinters() é uma matriz dinâmica correto ?

Eu não diria que é uma matriz "dinâmica", propriamente. Nem sei a que se refere esse termo. É apenas uma matriz multidimensional, cuja estrutura o AChoice() não aceita diretamente. Nunca usei este AChoice(). Mas o que você fez pra resolver o problema é natural: adaptar a estrutura de GetPrinters() para a estrutura necessária, criando uma matriz intermediária. Aliás, eu próprio fiz isso mesmo nos meus programas. É por aí mesmo. :)

Re: WAPI v1.03 - Funções da API do Windows Laserjet 1020

MensagemEnviado: 08 Mai 2008 09:58
por FabioAugusto
Maligno, bom dia!

Inclui junto a meu sistema em clipper o WAPI, e com ele evolui mto o sistema pois ele ainda esta em clipper puro, parabéns e obrigado pela contribuição.

Ontem fiz alguns testes aqui na Empresa onde tenho Laserjet 1200/1022/1020 e OfficeJet 3030, e só não imprimiu na 1020, li ontem nesse topico atentamente uma discussão que ocorreu em out 2007 sobre o mesmo problema que um programador teve ao tentar imprimir na 1020. será que essa discussão gerou um veredicto para esse problema ?
Ou já devo descartar a 1020 da minha roda de impressão ?

Abs.

Fabio A França

Re: WAPI v1.03 - Funções da API do Windows Laserjet 1020

MensagemEnviado: 08 Mai 2008 10:34
por Maligno
FabioAugusto escreveu:será que essa discussão gerou um veredicto para esse problema ?
Ou já devo descartar a 1020 da minha roda de impressão ?

Nunca imprimi numa 1020. Eu tenho a 1022, assim como você, e nela você viu que imprime normalmente. Até imaginava que imprimiria, já que são impressoras muito semelhantes. Mas se a 1020 não tem tabela de caracteres nativa e imprime apenas em modo gráfico, infelizmente não vai dar certo mesmo. A biblioteca WAPI está preparada para imprimir apenas em modo texto. Pelo menos até que eu faça essa parte, que está nos planos.

Reli a discussão que você comentou. Houve um colega com o mesmo problema. Acho que nesta semana devo encontrar um amigo que, se não me falha a memória, tem uma 1020. Vou testar nela. Mas arrisco a dizer que é quase certo que funcione, já que são impressoras praticamente iguais. Assim que puder dou um retorno.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 08 Mai 2008 10:44
por FabioAugusto
Por isso que a USB.EXE imprime por enviar para spooler em modo grafico, facil de resolver, aos usuários que forem imprimir na 1020 vou utilizar a USB.EXE

Abs.

Fabio A França

MensagemEnviado: 08 Mai 2008 10:49
por Maligno
Sim, resolve. Esse programa usa uma classe do XHarbour que converte todo o texto em gráficos, que é possível imprimir em qualquer impressora. Claro que isso envolve um certo custo de tempo de processamento. Se o volume de impressão for muito grande, talvez você acabe notando alguma lentidão.

Impressão em modo gráfico

MensagemEnviado: 08 Mai 2008 12:28
por Pablo César
FabioAugusto escreveu:aos usuários que forem imprimir na 1020 vou utilizar a USB.EXE
Enquanto não se tem um veredicto sobre esse modelo e o WAPI não imprimir em modo gráfico, atualize a versão do USB que aliás agora a sua interface é gráfica e chama-se HWUSB e você encontra no site do Maligno em: http://pub.buzinello.com/xbase/clipper/tools/hwusb.zip

Obs.: Favor não postar aqui dúvidas sobre o USB ou HWUSB. Esse assunto poderá ser postado lá na seção fontes.

Bug Report

MensagemEnviado: 09 Mai 2008 19:15
por Maligno
Para aqueles que utilizam o novo esquema de impressão inteligente da biblioteca WAPI, uma informação: há um bug na função que trata a relação de páginas a imprimir. A seqüência "4-", por exemplo, ao invés de configurar a impressão da página 4 até a última página, gera um erro. Faltou um mísero asterísco num ponteiro. Já corrigi e agora está funcionando perfeitamente. A correção será liberada na próxima versão. Mas se alguém precisar antes, é só dizer, que recompilo a versão atual.

maligno nao consigo imprimir com a wapi.lib (printfile())...

MensagemEnviado: 12 Mai 2008 04:02
por adilson
Maligno bom dia, ja reportei isto em um topico anterior... mas e o seguinte tua
lib WAPI e tb o PRWIN do wagner, manda a impressao para o spooler , a impressora
(no meu caso lexmark), diz que imprime,excluindo,etc,etc) mas nao sai nada no papel,
e utilizando o DOSPRINT ou mesmo a NODOSIMP a impressao sai ok.. , digo isto
porque seria muito mais pratico e racional utilizar tua LIB , que um programa externo nao e mesmo ???

caso vc puder me ajudar , meu! muito obrigado

:{

MensagemEnviado: 12 Mai 2008 06:56
por Maligno
A biblioteca WAPI foi feita para a impressão de dados de texto comuns, no formato RAW. Se essa Lexmark for do tipo que comentaram outro dia, que imprime apenas gráficos, por não possui tabelas de caracteres internos (você confirma isso???), realmente a WAPI não poderá ser utilizada. Pelo menos enquanto eu não fizer a conversão de texto para gráficos, o que está nos planos futuros.

Entretanto, eu estranho o fato de não ter funcionado no PRWin do Vagner, já que, pelo que me consta, esse programa imprime no modo gráfico também. Nunca usei, mas é um programa similar ao DOSPrint e o NoDOSImp, onde você diz que funciona.

Não sei se ajuda, mas se quiser, faça um teste também com o novo utilitário do HWUSB do Heveraldo. Esse programa usa uma classe do XHarbour que eu sei que imprime texto comum depois de convertê-lo totalmente para o modo gráfico, o que, a princípio, deve funcionar em qualquer impressora. Tenho o programa no meu site. Clique aqui para baixá-lo. Mas eu nunca sequer o testei. Nem sei que parâmetros utiliza. Portanto, se tiver dúvidas sobre como usá-lo, crie um novo tópico na seção Clipper mesmo e exponha suas dúvidas lá.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Mai 2008 05:06
por adilson
Maligno Bom Dia !, Com Relacao a LEXMARK Tem um (Tal) de Processador de Impressao e Tentei Varios Tipos (RAW - RAW[FF append], TEXT,LEMF,ETC) , e mesmo
assim nao imprime ok !,... Vamos esperar anciosos pelas proximas atualizacoes.

Um Forte Abraço..

:{

MensagemEnviado: 14 Mai 2008 09:09
por Maligno
adilson escreveu:Com Relacao a LEXMARK Tem um (Tal) de Processador de Impressao e Tentei Varios Tipos (RAW - RAW[FF append], TEXT,LEMF,ETC)

Processador de impressão? Não tenho idéia do que seja isso.

Opção PRINT para impressão seletiva de páginas

MensagemEnviado: 27 Mai 2008 09:34
por Pablo César
Sabemos que para imprimir páginas de forma seletiva, através da função PRINT do WAPI precisa como inicio de cada página (no arquivo de impressão) que esteja marcado com um identificador (ou tag) com um grupo de códigos ASCII: 02, 11 e 03 (decimal), ou STX+VT+ETX para que seja interpretado como inicio de página.

Gostaria de indicar ao Maligno, ora se o colega me permite fazer uma sugestão, para que o WAPI pudesse aceitar esse identificador de forma variável em conformidade e a gosto de cada um. Isso poderia ser implementado, Maligno ?

MensagemEnviado: 27 Mai 2008 11:05
por Maligno
Pablo César escreveu:para que o WAPI pudesse aceitar esse identificador de forma variável em conformidade e a gosto de cada um. Isso poderia ser implementado, Maligno ?

Eu só fixei isso para tornar a lista de argumentos menor. Mas não vejo no quê isso poderia melhorar alguma coisa. Se você usa X, Y ou Z como marcador de início de página, não faz a menor diferença. Então, por que não usar o X que eu já indico? Algum problema nisso? Porque mudar o marcador?

Paginação

MensagemEnviado: 27 Mai 2008 11:49
por Pablo César
Maligno escreveu:Eu só fixei isso para tornar a lista de argumentos menor.
Sim isso eu até entendo.

Maligno escreveu:Então, por que não usar o X que eu já indico? Algum problema nisso? Porque mudar o marcador?
Pois ao deixar esses identificadores de forma fixos, o usuário irá ser obrigado a gerar SEMPRE com tais caracteres dentro do arquivo de impressão e por consequente tais caracteres não irão ser ignorados por outros aplicativos como USB.EXE quando precisar fazer impresão gráfica, por exemplo. Vamos dizer que é para manter compatibilidade de uso com outros aplicativos de impressão.

Acho que o processo de seleção de página para ser impresso, deveria ser levado em conta o final de cada página e não o começo. A forma universal para o salto de página é o CHR(12), então deveria ser este o caracter de referência. Me desculpe a minha discordância, talvez seja porque ainda procuro por um procedimento mais certeiro. Não que o seu não funcionasse, mas visto que o WAPI não imprime em modo gráfico daí somos forçados ao uso de outros aplicativos e aí então ficamos sem o recurso de desdobramento para impressão.

Diante desta questão, acharia mais produtivo fazer um aplicativo de desmembramento seletivo do arquivo de impressão do que deixar atrelado a mesma função de impressão com o WAPI. Se for pensar a fundo, o aplicativo de desmembramento para impressão, é relaticvamente fácil. Seria questão de contar quantos CHR(12) tem o arquivo de impressão, apresentar um menú para seleção de página ao estilo WINWORD (imprimir páginas: 1;3;5-8;12) e localizar cada CHR(12) compondo tais páginas em apenas um arquivo úncio para impressão.

MensagemEnviado: 27 Mai 2008 13:17
por Maligno
Por partes. Porque escolhi essa seqüência como marcadora de início de página? A resposta se divide em duas. Primeiro que Chr(12) pode fazer parte de um comando de configuração como argumento, seja ESC/P ou PCL. Segundo que, já que não usaria Chr(12) mesmo, não faria qualquer diferença onde a seqüência apareceria; no início ou fim da página. Para efeito de codificação ficou mais fácil usá-la no início. Mas o fato é que eu precisaria desta tag para indexar as páginas. Mas veja que não descarto a possibilidade dessa tag ser configurada. Mas isso só posso responder em definitivo quando essa parte de impressão estiver finalizada.

Na questão de usar dois programas para impressão e tentar compatibilizá-los, é meio relativo. Hoje a WAPI não imprime gráfico, mas isso já está sendo resolvido, haja vista que, conforme comentei, dei azar de um cliente importante ter comprado uma impressora que não tem tabela de caracteres. Optei por modificar a WAPI pra trabalhar também no modo gráfico. Desta forma, estando a WAPI capacitada a imprimir tanto em texto quanto em gráfico, não haveria motivo para usar dois programas. Então voltamos à característica inicial: sendo apenas um programa, não fará diferença qual tag será utilizada e muito menos onde essa tag estará.

Aliás, aproveitando a discussão: há situações (me apareceu uma) em que pode-se querer imprimir um arquivo qualquer que não contém tag nenhuma. Aí entrará a nova opção de delimitação de página pela contagem de linhas. Isso evita que se tenha que carregar todo o arquivo para inserir as tags.

De qualquer forma, hoje eu não vou alterar coisa alguma na tag. Vou terminar o modo gráfico e depois implementar algumas melhorias, se for o caso. Isso não quer dizer que sou intransigente. Nada disso. Ainda não parei pra analisar. Mas SE eu perceber que trocar a tag de lugar vai me custar mais caro do que estou disposto a pagar, ela ficará onde está. Até porque, como eu já havia comentado há algum tempo, um sistema de relatório bem montado, dinâmico, flexível, faz o uso de qualquer tag uma coisa bem simples, esteja ela onde estiver.

Impressão de páginas de forma seletiva

MensagemEnviado: 27 Mai 2008 13:35
por Pablo César
Maligno escreveu:Chr(12) pode fazer parte de um comando de configuração como argumento, seja ESC/P ou PCL.
Maligno, não pensou que esse grupo de códigos decimais ASCII: 02, 11 e 03 ou STX+VT+ETX possa também a ser algum comando de impressão ????

Não sei se essa questão de considerar <n> de linhas por páginas irá dar certo, visto que as vezes uma sequência de comandos de impressão poderiam estar excedendo o tamnho limite de caracter por linha.

Eu tenho entendido que o CHR(12) é U N I V E R S A L, isto é, sua equivalência comporta-se como salto de página (EJECT como quiser chamar) em TODAS as impressoras. Ao menos que eu estje e n g a n a d o.

MensagemEnviado: 27 Mai 2008 13:50
por Maligno
Pablo César escreveu:Maligno, não pensou que esse grupo de códigos decimais ASCII: 02, 11 e 03 ou STX+VT+ETX possa também a ser algum comando de impressão ????

Claro que já pensei. Por isso mesmo escolhi essa seqüência: não a encontrei em manual nenhum. Aliás, Chr(12) também não. Mas ele pode fazer parte de um comando, como disse. Agora, essa seqüência de três bytes não.

Não sei se essa questão de considerar <n> de linhas por páginas irá dar certo, visto que as vezes uma sequência de comandos de impressão poderiam estar excedendo o tamnho limite de caracter por linha.

Me refiro a arquivos texto crús, sem qualquer caractere de controle.

Eu tenho entendido que o CHR(12) é U N I V E R S A L, isto é, sua equivalência comporta-se como salto de página (EJECT como quiser chamar) em TODAS as impressoras. Ao menos que eu estje e n g a n a d o.

Não digo que esteja enganado, mas exagerando na importância da coisa. Como eu disse, Chr(12) poderia fazer parte de um comando. Aliás, qualquer tag de um único byte. Daí a minha escolha por três bytes.

Note que você está vendo dificuldade onde ela não existe. Se você vai ejetar uma página, como faz? Você faz algo do tipo: @ ... say Chr(12), não é? Eu já não faço isso. Eu uso minha função prtEject(), que executa esse mesmo @. Mas porque isso? Porque abstraindo o eject eu posso fazer qualquer coisa adicional que precisar, alterando apenas um único lugar do meu sistema inteiro. Analogamente, eu começo uma página com prtIniPag(). Ela nem precisa conter coisa alguma além de um return. Mas se no futuro eu precisar elaborar algum controle especial, eu tenho esse "escape" prontinho no programa todo. Meu esforço seria mínimo. Aí entra a inserção da tag de marcação de início de página. É nessa função que eu coloco o código que a insere. Matei o problema com poucos toques de teclado, apenas porque fui prevenido. Por isso que eu disse que, com um sistema de relatório bem elaborado você não tem trabalho nenhum, não importando qual tag e nem onde ela estará. Entendeu agora?

Veja que o Clipper, da forma como foi feito, é muito mal feito. Mas você, como programador, tem a oportunidade de melhorá-lo drasticamente fazendo uso desse tipo de técnica de abstração para a construção de sub-sistemas que tornam a tarefa de programação muito mais fácil, da mesma forma como poderia fazer em qualquer outra ferramenta mal feita.

Sub-sistema e unicidade de funções

MensagemEnviado: 27 Mai 2008 13:58
por Pablo César
A sua proposta de implementar impressão gráfica no WAPI é boa e não justificaria a utilização de um segundo aplicativo para desdobramento. Se bem que eu ainda sou a favor desse recurso por separado. Oras você sempre chamou atenção para desdobramento de funções ou "idéia básica da unicidade das funções" como você menciona na sua mensagem viewtopic.php?f=1&t=7640&p=42436#p42436. Você sempre disse que fica mais entendível e adequado separar as funções, (cada macaco no seu galho) mas neste caso você o está vinculando com as suas funções de impressão. (dá pra entender ?)

Gostei da estruturação de funções para relatórios. Poderias citar exemplos ? E listar as sub-sistemas mais relevantes que auxiliam seus relatórios ?

MensagemEnviado: 28 Mai 2008 12:05
por Maligno
Pablo César escreveu:Se bem que eu ainda sou a favor desse recurso por separado.

Porque separado se tudo é impressão? Você mudará para texto/gráfico/texto com base no conteúdo de um simples flag.

Oras você sempre chamou atenção para desdobramento de funções ou "idéia básica da unicidade das funções"

Você fez confusão nos termos. A característica da unicidade numa função é muito benéfica, mas quando é possível. Uma vez que existem vários níveis de funções (alto, médio, baixo nível), quando mais baixo o nível, mais preferível (e possível) é manter essa unicidade.

mas neste caso você o está vinculando com as suas funções de impressão. (dá pra entender ?)

Dá pra entender se você conseguir separar o que é nível de função do próprio termo função. Todo programa já começa com uma função. Mas por vezes a função é de alto nível, cujo conteúdo tem ação pontual. Só serve naquele ponto. Funções de biblioteca, por outro lado, tem um escopo mais abrangente. Nesse nível de função sim, é muito saudável manter a função executando uma única tarefa. No caso que discutimos, a impressão da WAPI, se você analisar os fontes, verá que eu sempre cuidei para manter essa característica. Mas eu sei que ainda não está do jeito ideal. Vou separar os fontes para melhorar mais ainda (não imaginava que ia crescer tanto). :)

Gostei da estruturação de funções para relatórios. Poderias citar exemplos ? E listar as sub-sistemas mais relevantes que auxiliam seus relatórios ?

Não são sub-sistemas no plural, mas no singular. Um sub-sistema tem por função auxiliar e facilitar o desenvolvimento de tarefas corriqueiras. É uma forma de abstrair funções que normalmente requerem ações repetitivas e tediosas. É como o sub-sistema GET. Ele é dispensável. Você até poderia fazer tudo sem ele, mas seria bem mais trabalhoso.

Para relatórios é a mesma coisa. Muito embora a maior carga de trabalho será sempre a impressão das linhas individualmente. De qualquer forma, muita coisa pode melhorar. Dois exemplos simples abaixo. Não são programas completos. São apenas exemplos.

O primeiro, sem o uso de um sub-sistema:

set device to print
set printer on

lCab := .T.
while !EoF()
   if lCab
      lCab  := .F.
      nLins := 0
      CabecRel()
   end
   //
   @ PRow(),0 say "Registro: " + Str(RecNo())
   //
   if (++nLins) > 63
      RodapRel() // já com o Chr(12) para ejetar
      lCab := .T.
   end
   dbSkip()
end
if !lCab
   RodapRel()
end
//
set printer off
set device to screen


Agora usando um sub-sistema preparado para tornar o mesmo relatório mais dinâmico, fácil de ser alterado, apenas com a configuração do usuário:

prtConfig() // o usuário escolhe a impressora, papel, etc
prtInit()   // o mecânismo de saída é preparado

while !EoF()
   if lCab
      lCab  := .F.
      nLins := 0
      prtInitPag()
      CabecRel()
   end
   //
   // O destino da impressão vai depender da configuração
   // A falta de coordenadas indica "coluna zero da próxima linha"
   prtOut("Registro: " + Str(RecNo()))
   //
   if (++nLins) > prtNroLins()
      RodapRel()
      prtEject()
      lCab := .T.
   end
end
if !lCab
   RodapRel()
   prtEject()
end
prtEnd()
//
// Se a saída for o vídeo, mostra o relatório
if prtOutVid()
   prtDispRel()
end


O exemplo 1 é mais ou menos como se costuma fazer sem um sub-sistema. O exemplo 2, com um sub-sistema preparado para trabalhar em vários modos, torna tudo mais fácil. Note que cada página tem uma chamada à prtInitPag(). É nessa função que eu poderia inserir um marcador de página ou preparar um texto adicional para o caso da saída ser o vídeo. É o mesmo caso de prtEject() que, normalmente, é o fim da página. Nele ou eu apenas insiro o Chr(12) tradicional ou, sendo vídeo, insiro um texto marcador de vídeo.
A impressão de linhas, também por função própria, me dá chance de produzir um filtro. Conforme a impressora configurada, posso utilizar este ou aquele conjunto de caracteres de controle. Na formatação do relatório tenho uma função que me informa a quantidade de linhas disponíveis na página. Posso configurar papel A4, Carta, formulário, meio-formulário, etc. O que for. Mas nada precisará ser alterado no relatório. Ao contrário do que aconteceria no exemplo 1, que fica bem mais limitado.

Basicamente é isso. Mas tem uma série de coisas a mais. Acho que cada um pode muito bem imaginar que várias facilidades podem ser criadas para tirar aquele monte de trabalho que normalmente se tem com relatórios.

A WAPI me ajudou bastante porque me deu flexibilidade para imprimir seletivamente sem me preocupar em modificar o relatório em si. Inclusive minha função prtConfig() conta com uma janela de configuração muito parecida com o diálogo de impressão que se vê nos programas Windows, como o Word, por exemplo.

Desmembramento de função para impressão seletiva

MensagemEnviado: 28 Mai 2008 12:48
por Pablo César
Maligno escreveu:Porque separado se tudo é impressão?
Discordo totalmente. Sabemos que essa questão de desdobrar o arquivo de impressão é uma função totalmente a parte da impressão. E se fosse possível desdobrar essa função do WAPI, poderia até ser utilizado para outros fins (como a utilização de relatorio de tabela para ser carregado no Excell, por exemplo). Ao final de contas, a execução de multiplas funções no WAPI não é feita com um único chamado ?. Entã... não iria atrapalhar em nada colocando essa função como mais uma opção independente sem estar intrínsica a função de impressão através do SPOOL.

Mas enfim... deixarei mais uma vez meus comentários de lado, visto que não chegaremos a lugar algum com isso. Foi apenas uma crítica que ainda pudera ter dado melhor funcionabilidade a essa nova função do WAPI.

MensagemEnviado: 28 Mai 2008 13:12
por Maligno
Pablo César escreveu:Sabemos que essa questão de desdobrar o arquivo de impressão é uma função totalmente a parte da impressão.

Não entendi nada do que diz esta frase. Se o arquivo é de impressão como pode ser à parte da impressão?

E se fosse possível desdobrar essa função do WAPI, poderia até ser utilizado para outros fins (como a utilização de relatorio de tabela para ser carregado no Excell, por exemplo).

Também não entendi o que isso quer dizer.

Ao final de contas, a execução de multiplas funções no WAPI não é feita com um único chamado ?

Não exatamente. Você está confundindo o meio de execução (WAPI.EXE) com a lista de switches que existe. Cada switch é uma função à parte. Não importa como é feito esse "chamado". Isso é um assunto à parte, irrelevante.

Entã... não iria atrapalhar em nada colocando essa função como mais uma opção independente sem estar intrínsica a função de impressão através do SPOOL.

A indicação para impressão em modo gráfico seria apenas um simples flag na linha de comando do switch -PRINT:. Até nem atrapalharia tanto criar outro switch, tipo -GRAPHPRINT:, por exemplo. Mas o destino dele seria o mesmo: o spool do Windows. Então, fica a pergunta: pra quê separar se posso usar um simples flag?

Impressão seletiva

MensagemEnviado: 28 Mai 2008 14:07
por Pablo César
Eu estava me referindo ao procedimento interno do switch -PRINT que faz a impressão seletiva do WAPI. Confirmei o que eu estava supondo ser ao ler seu código fonte, no qual esse procedimento de "seleção de conteúdo a ser impresso" está dentro da mesma função que faz a impressão pelo spooler (função PRT_SendToSpooler). Deixemos de lado aquele faladeira toda sobre "unicidade das funções" emboar venha ao caso. O que eu estou tentado lhe dizer, é que seria até mais aproveitável ser separado o procedimento de "seleção de conteúdo a ser impresso" (que está dentro da função PRT_SendToSpooler) em função SEPARADA e até mesmo criando um novo SWITH para que esse procedimento venha acontecer em um arquivo temporário para impressão. Isso porque, você estaria acrescentando diversificando e conciliando recursos do WAPI, podendo até ser executado em conjunto ou simultaneamente com a função PRINT.

Pelo que eu ví e entendí do seu código fonte (na função PRT_SendToSpooler), você manda linha a linha o conteúdo do arquivo de impressão e (linha a linha) são enviado ao spool de impressão. Agora eu pergunto: Não seria mais rápido ou melhor enviar todo o arquivo pro spool ?. Qual seria a vantagem de manter isso assim ?

Outra coisa que eu te questiono é sobre os 5 parâmetros que foram adicionados ao swicth -PRINT. Sei que são necessário para compor a lógica para o procedimento de impressão seletiva. No obstante, se você tivesse aplicado outra técnica (como por exemplo aquela que eu exponho no tópico viewtopic.php?f=1&t=8105#p45550 que fala na criação de um segundo arquivo para impressão) você não iria necessitar de tantos parâmetros para fazer a impressão. Em vista da possibilidade de inserir mais um recurso de impressão gráfica, você mesmo está vendo que cada vez está mais complicado toda essa questão de impressão. Não seria mais um motivo para desdobrar procedimentos ?

MensagemEnviado: 28 Mai 2008 17:56
por Maligno
Pablo César escreveu:esse procedimento de "seleção de conteúdo a ser impresso" está dentro da mesma função que faz a impressão pelo spooler (função PRT_SendToSpooler).

E onde você acha que isso deveria estar? A função de impressão precisa saber o quê vai imprimir. Se olhar com calma, verá que existem duas funções de apoio. Uma destrincha (ou explode) a lista de páginas, obtendo e validando as seqüências de números. A segunda cria um índice em memória, que me permite encontrar facilmente cada página. Aí entra em ação a função de impressão que lê a lista de páginas e vai imprimindo uma a uma.

O que eu estou tentado lhe dizer, é que seria até mais aproveitável ser separado o procedimento de "seleção de conteúdo a ser impresso" (que está dentro da função PRT_SendToSpooler) em função SEPARADA

Gostaria que você me explicasse por quê seria mais aproveitável separar isso? E aproveitável pra quem?

Veja: a seleção do quê será impresso vem pelo argumento que representa a lista de números de páginas. De acordo com a filosofia do projeto, eu preciso dessa lista desmembrada. Isso é feito por uma função à parte, como já expliquei acima. Depois disso essa lista está pronta para ser lida na função principal. A cada número lido a página é encontrada no arquivo com a ajuda do índice montado por aquela outra função. Encontrada a página, ela é enviada para o spool. Ou seja, não dá pra separar coisa alguma.

e até mesmo criando um novo SWITH para que esse procedimento venha acontecer em um arquivo temporário para impressão.

Um novo switch pra quê exatamente? Não entendi isso. Qual seria a função dele? E pra quê um arquivo extra?

Realmente isso não me parece ter a menor lógica. Pra quê dar voltas e voltas se vou parar no mesmo lugar? Do jeito que foi feito é direto.

Isso porque, você estaria acrescentando diversificando e conciliando recursos do WAPI, podendo até ser executado em conjunto ou simultaneamente com a função PRINT.

Sua concepção me parece terrivelmente equivocada. A forma de trabalho que você está sugerindo, além de totalmente estranha (nem entendi muito bem), só faria acrescentar complexidade e dificuldade naquilo que não só é simples, como já está pronto e funcionando. Se eu percebesse na sua proposta algum ganho, até poderia acatar uma sugestão. Mas não é o que eu vejo.

Pelo que eu ví e entendí do seu código fonte (na função PRT_SendToSpooler), você manda linha a linha o conteúdo do arquivo de impressão e (linha a linha) são enviado ao spool de impressão.

Você não entendeu o código. Eu mando página a página.
Não confunda com aquela nova proposta de imprimir um arquivo texto crú, onde aí sim, cada linha seria lida individualmente e impressa sem qualquer tratamento. Mas isso ainda é apenas uma idéia.

Agora eu pergunto: Não seria mais rápido ou melhor enviar todo o arquivo pro spool ?. Qual seria a vantagem de manter isso assim ?

Poderia mandar o relatório inteiro, mas isso não produziria qualquer efeito benéfico em termos de velocidade. Não há uma grande vantagem em mandar página por página, mas em termos de facilidade de codificação, nem se compara, haja vista que nem sempre se quer imprimir tudo. E se o sujeito quiser imprimir apenas a páginas pares? Eu teria que ter dois blocos de código: um para imprimir tudo numa pancada só e outro pra imprimir de forma seletiva, página a página. Como não há ganho nisso, é melhor deixar assim.

Outra coisa que eu te questiono é sobre os 5 parâmetros que foram adicionados ao swicth -PRINT. Sei que são necessário para compor a lógica para o procedimento de impressão seletiva. No obstante, se você tivesse aplicado outra técnica (como por exemplo aquela que eu exponho no tópico viewtopic.php?f=1&t=8105#p45550 que fala na criação de um segundo arquivo para impressão) você não iria necessitar de tantos parâmetros para fazer a impressão. Em vista da possibilidade de inserir mais um recurso de impressão gráfica, você mesmo está vendo que cada vez está mais complicado toda essa questão de impressão. Não seria mais um motivo para desdobrar procedimentos ?

A quantidade de parâmetros é uma questão irrelevante. Eu poderia ter 50 parâmetros e isso não me atrapalharia em nada. Aí entra a biblioteca de abstração, cuja função principal é facilitar a sua vida, como usuário da WAPI. A camada extra de dificuldade a que você se refere, acredite, não está no tamanho da lista de argumentos. Isso é o de menos. Se meu problema fosse só esse, estaria contente. :)

Inserir o modo gráfico seria (teoricamente) apenas incluir mais um simples argumento. Na função principal de impressão eu talvez faça um desvio para a conversão, para depois enviar para o spool por ali mesmo. Mas há outras formas de fazer isso. Ainda não decidi nada. Mas pra você, usuário, isso é totalmente irrelevante.

Aliás, sendo irrelevante pra você, não entendo essa sua preocupação em "desdobrar procedimentos" dentro do WAPI.C. Pra você isso não importa. O que realmente importa é que funcione e bem, de forma transparente pra você. Isso, até onde foi feito, funciona sim. E continuará funcionando, mesmo com o acréscimo dos recursos que já mencionei. E os que não mencionei ainda, mas que são apenas idéias.

Impressão seletiva

MensagemEnviado: 28 Mai 2008 20:36
por Pablo César
Esqueça tudo o que eu te falei ! No final de contas eu apenas sou um mero usuário, por quê cargas daguas teria que estar dando alguma opinião, não é ?

MensagemEnviado: 28 Mai 2008 21:43
por Maligno
Pablo César escreveu:Esqueça tudo o que eu te falei ! No final de contas eu apenas sou um mero usuário, por quê cargas daguas teria que estar dando alguma opinião, não é ?

Ao que parece, pelo destempero da sua mensagem, você está querendo impor e não sugerir uma alteração. Vendo que não conseguiu, me parece que se sentiu frustrado, irritado, contrariado e/ou desprestigiado.

Então, calma! Preste atenção e leia devagar o que tenho a dizer.

Eu disse que não entendo o porque de tanta preocupação em alterar algo que não lhe fará a menor diferença. Pelo menos eu acho que não fará. Ainda se eu tivesse entendido o que o motivou a fazer sua reivindicação, vá lá. Mas, honestamente, nem entendi muito bem. Agora, se você me apresentar um argumento válido (eu disse VÁLIDO) e forte o suficiente (eu disse FORTE), que me faça ver um caminho melhor (melhor MESMO), maravilha. Mudo minha opinião e atenderei sua reivindicação assim que possível, e mesmo à custa de uma carga maior de trabalho. Mas por enquanto isso não aconteceu. Você não me convenceu.

Mesmo sendo um mero usuário, se você tem uma sugestão e se dispõe a me fazer o favor de compartilhá-la, de antemão agradeço. Toda crítica, opinião ou sugestão é importante. Mas em primeira instância trata-se apenas de uma sugestão. Para que ela se materialize numa alteração, antes de tudo, vai ter que me convencer. Se não conseguir, de duas uma: ou você não está sendo claro o suficiente, ou eu realmente não vi nada de vantajoso na sua sugestão.

Note que se eu tivesse a mínima intenção de desmerecer sua sugestão, desprestigiá-lo ou fazer pouco caso, sequer me daria ao trabalho de escrever o tanto que escrevi. Em sinal de respeito ao seu pensamento e ao de todos do fórum, estou sempre pronto a ouvir qualquer um e a respondê-los com a maior paciência, educação e cordialidade, que são traços característicos da minha personalidade.

Mas não force a barra, que comigo não adianta. :)

Meu TODO LIST para o WAPI

MensagemEnviado: 24 Jul 2008 10:04
por Pablo César
Maligno escreveu:não entendo o porque de tanta preocupação em alterar algo que não lhe fará a menor diferença.
Tudo bem, Maligno como eu disse e você disse, não estou mais aclamando qualquer mudança sobre a opção PRINT, ok ?.

Estou apresentando o que denominei "meu" TODO LIST, porque ainda considerei que há assuntos a serem resolvidos ou desconsiderados, dependendo a solução de tais pendências, é claro. Pois mesmo você não ter incluído certos itens, ainda não deixa de ser um TODO LIST e como cabe a você (que é pai da criança) estou disponibilizando para sua posterior avaliação de acordo com o seu ultimo TODO LIST:

  • Controle de volume do som
  • Inclusão da informação do diretório "iniciar" na informação do sistema
  • Execução do WAPI no modo residente (codinome RES)
  • Bloqueio do teclado e mouse em nível global (requer RES)
  • Cancelamento de execução de WAVs (requer RES)
  • Execução de sons em lote (funcionalmente melhor com RES)
  • Apagamento seguro de arquivos (wipe file)
  • Execução de atalhos de teclado, próprios do windows (ex: Alt+Enter)
  • Criação de links para execução de programas
  • Funções de FTP: list, delete, upload, download, etc...
  • Criação de um help no estilo NG (Norton Guides)
  • Criação de um programa demo completo, com todas as opções disponíveis
  • Remover a dependência das bibliotecas CATools e NanFor
  • Possibilidade (REMOTA) de função de verificação e retorno em arquivo do modo em que é exibida a sessão
  • Possibilidade de função tipo "scheduler" para execução no TRAY quanto a verificação de existência de arquivo

Só para constar, porque ficou ainda sem resposta a minha msg viewtopic.php?f=1&t=4328&p=44536#p44536 não que esteja cobrando agora uma resposta. Prefiro que seja feito no tempo conveniente a sua disponibilização.

MensagemEnviado: 25 Jul 2008 01:35
por Maligno
Possibilidade (REMOTA) de função de verificação e retorno em arquivo do modo em que é exibida a sessão
Possibilidade de função tipo "scheduler" para execução no TRAY quanto a verificação de existência de arquivo

À todo list que redigi você acrescentou essas duas tarefas. A última é provável. Embora ela seja apenas um "gancho" para outras tarefas subseqüentes que, se não existirem, farão o schedulling inútil. Vou analisar melhor depois. Ela ficará(ia) em penúltimo lugar na lista.

Agora, a primeira dessas tarefas é algo mais complicado. Já pesquisei bastante a respeito. Ela não é prioridade, realmente, por quê a lista ainda está bem volumosa e, pelo que vejo, essa tarefa não representa uma necessidade real para muitas pessoas. Sinto muito, mas diante da dificuldade técnica, ela vai ter que ficar por último. Aliás, respondendo à sua pergunta: não tive tempo para analisar o Z.COM.

Mas a saber: estou terminando (aos poucos, conforme o tempo permite) o modo residente do WAPI.EXE, que já vai contar com mais algumas coisas, como o MUTEX para o Clipper, que fará o controle de execuções múltiplas da aplicação sem aquela "gambiarra" de antes. Aliás, o próprio fonte, pelo volume que já tem, está se tornando um empecilho. Vou segmentá-lo assim que terminar o modo residente.

Redirecionamento de saída de impressão pelo SO

MensagemEnviado: 13 Ago 2008 12:59
por Pablo César
Caro Maligno, apenas uma pergunta e possível sugestão. Será que há alguma função em C que permita alterar o direcionamento de saída de determinada impressora ? Para ser mais preciso mudar para impressão em arquivo, como mostra figura abaixo:

Imagem

A idéia surgiu que se temos o nome das impressoras instaladas no Windows e ainda imprimir através da WAPI, talvez exista uma forma que pudesse alterar o flag do campo acima destacado (Propriedades da impressora/Portas), teria cómo ?

MensagemEnviado: 14 Ago 2008 00:16
por Maligno
Vou ter que pesquisar a respeito, pois aí, creio eu, já não tem mais a ver com o spooler do Windows. Fiquei curioso. Acho que no final de semana já devo ter uma resposta. Volto ao assunto.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 15 Set 2008 13:01
por Tim9
Quero imprimir usando o Wapi v1.03, já baixei e descompactei, como pretendo utilizar em cliente não vou usar o wapi.exe e sim o wapi.lib. Desculpem as minhas dúvidas mas sou leigo em impressão que fuja do trivial simples em lpt1 com clipper 5.2e e blinker 7, vejam as minhas dúvidas:

01. Neste programa uso os PCL para inicializar as impressoras Matricial ou Jato de tinta, a wapi dispensa este uso?

02. A Wapi reconhece qualquer impressora local em lpt1 (não preciso mais inicializar cada uma) ?

03. Para compilar com blinker só preciso copiar para o clipper5\lib a wapi.lib ou também os .h e .ch para clipper5\include, etc. enfim quais os arquivos que devo compilar junto com meu programa ?

04. Entendi que sempre devo gerar meu relatório em arquivo texto para depois imprimir. É isso mesmo?

05. Qual a sintaxe para imprimir com a wapi?

Aguardo e antecipo meus agradecimentos pela atenção, mais uma vez pedindo desculpas pela ignorância no assunto.

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 15 Set 2008 15:57
por Pablo César
time9 escreveu:01. Neste programa uso os PCL para inicializar as impressoras Matricial ou Jato de tinta, a wapi dispensa este uso?
Os comando de impressão, são necessários para formatação do modo de impressão e são inerentes à impressora. A função PRINTFILE() da WAPI como o switch -PRINT do WAPI.EXE colocam o conteúdo do arquivo de impressão na fila de impressão (ou spooler) e consequente impressão.

time9 escreveu:02. A Wapi reconhece qualquer impressora local em lpt1 (não preciso mais inicializar cada uma) ?
A função PRINTFILE() mandará para qualquer impressora instalada naquele PC. Você pode mandar para o default (padrão) ou selecionar pelo nome da impressora (conforme está instalada no seu Windows). A Wapi possue outra função que devolve os nomes da impressoras que estão instaladas através do GETPRINTERS() e atribui a um array.

time9 escreveu:03. Para compilar com blinker só preciso copiar para o clipper5\lib a wapi.lib ou também os .h e .ch para clipper5\include, etc. enfim quais os arquivos que devo compilar junto com meu programa ?
Dependendo o que você exige da WAPI.LIB você apenas irá precisar linkar com o BLINKER (por exemplo) a WAPI.LIB e a CT.LIB (da CA-Tools), exemplo: BLINKER FI <seu_programa> LIB WAPI,CT e deixar o WAPI.EXE na pasta onde irá executar seu programa, pois a WAPI.LIB necessita do WPAI.EXE no diretório corrente ou no lugar predefinido pelo path.

time9 escreveu:04. Entendi que sempre devo gerar meu relatório em arquivo texto para depois imprimir. É isso mesmo?
Sim, normal como você faria com COPY FILE("arquivo_texto") TO ("LPT1")

time9 escreveu:05. Qual a sintaxe para imprimir com a wapi?
Sugiro você ler o README.TXT que está no pacote da WAPI. A sintaxe é:

PrintFile(cPrtName,cRptFile[,cRptTitle[,lPaged[,cPages[,lPrintAll[,lEven[,lOdd[,lReverse[,nCount[,lGroup]]]]]]]]]) -> logic
Infileira no spooler do Windows o conteúdio do arquivo <cRptFile>, que o apresenta sob o
título <cRptTitle>. Este será impresso na impressora de nome <cPrtName> (espaços são
permitidos). O resultado será TRUE, se o empilhamento for bem sucedido. Caso contrário,
FALSE, sendo o código do erro recuperável pela função WAPIError().
Se o título do relatório for omitido, será utilizado "clipper.report@DD/MM/AAAA,hh:mm:ss",
onde DD=dia, MM=mês, AAAA=ano, hh=horas, mm=minutos e ss=segundos.
A impressão será no modo RAW (crú), sem que haja qualquer modificação. O flag opcional
<lPaged>, se TRUE (default=FALSE), indica que cada página será identificada pela seqüência
de valores decimais 02, 11 e 03 (STX, VT e ETX, conforme a tabela ASCII). Obviamente, essa
tag será eliminada da impressão. Se <lPaged> for FALSE, não será feita qualquer referência
a números de páginas e todos os demais parâmetros perderão o sentido e serão ignorados, a
exceção de <nCount>.
Uma lista de números de páginas (mesmo que repetidos) poderá ser informada em <cPages>,
separados por vírgulas e em qualquer ordem (serão ordenados). Exemplo: "1,2,3". Seqüências
poderão ser informadas de forma reduzida, apenas com seus números inicial e final no
formato "i-f". Exemplo: "3-8" fará imprimir todas as páginas do número 3 a 8 (inclusive).
Um (e apenas um) desses valores poderá ser omitido. Se "i" for omitido, será substituído
por 1. Sendo omitido "f", será usado o número da última página encontrada. As duas formas
poderão ser usadas em conjunto.
O flag opcional <lPrintAll>, se TRUE (default), selecionará para impressão todas as
páginas. Os flags <lEven> e <lOdd>, também opcionais, se TRUE (ambos com o defaul FALSE),
selecionarão apenas as páginas pares ou ímpares, respectivamente.
O flag <lReverse> é opcional e, se informado TRUE (default=FALSE), fará a impressão das
páginas selecionadas em ordem inversa.
O parâmetro <nCount> permite definir uma quantidade de cópias (default=1) a imprimir.
O flag <lGroup>, se TRUE (default) e sendo <nCount> maior que 1, fará as páginas serem
impressas em sua seqüência natural. Exemplo: "1,2,3,1,2,3". Se for FALSE, as páginas de
números iguais serão impressas contíguas. Exemplo: "1,1,2,2,3,3".


Espero ter lhe ajudado.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 15 Set 2008 16:42
por Tim9
Muito obrigado Pablo, ajudou e muito, mas só fiquei triste pela limitação de ter que instalar o .exe no cliente e nem todos permitem.

Mas a contribuilçao do Buzinello é sensacional. Parabéns a ele pela iniciativa e trabalho e a vc pela presteza dos esclarecimentos necessários e suficientes.

Quero agradecer a todos que colaboram, aos moderadores e ao Toledo.
Não quero ser injusto e nem ingrato

Obrigado a este maravilhoso forum.

Valeu,

Luz e Paz!

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 20 Set 2008 15:56
por Tim9
Tenho 2 erros na compilação, onde estou errando?
Estou fazendo assim:
------------------------------------------------------------------------------------
IMPLEMENTANDO A WAPI:
1. COPIEI A WAPI.LIB PARA C:\CLIPPER5\LIB
2, COPIEI O WAPI.EXE PARA O DIRETORIO DO MEU EXECUTÁVEL.
----------------------------------------------------------------------------------
INICIO DO PRG:
SET PRINTER TO REL.TXT
SET DEVI TO PRINTER
-------------------------------
FIM DO PRG:
SET PRINTER TO
SET DEVI TO SCREEN
PRINTFILE(LPT1;REL.TXT;"VENDAS";RESULTA.TXT)
-------------------------------
LNK:
LIB CTP, VL2, WAPI
--------------------------------
COMPILANDO:
clipper REL_VEN.PRG /m /n
282K available
Compiling REL_VEN.PRG
REL_VEN.PRG(260) Error C2002 Incomplete statement or unbalanced delimiters
REL_VEN.PRG(260) Error C2001 Syntax error: '.'
2 errors

No code generated
-------------------------------------
Aguardo e antecipo meus agradecimentos pela ajuda que por certo virá.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 20 Set 2008 17:31
por Maligno
PRINTFILE(LPT1;REL.TXT;"VENDAS";RESULTA.TXT)

Os argumentos de uma função são separados por vírgulas. Aproveite e dê uma no README do ZIP e note que esta função tem 11 argumentos em uma ordem específica. Aliás, o primeiro argumento é o nome da porta. Ou seja, é caractere.

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 22 Set 2008 09:46
por Pablo César
REL_VEN.PRG(260) Error C2002 Incomplete statement or unbalanced delimiters
REL_VEN.PRG(260) Error C2001 Syntax error: '.'
Tim9 (desconheço seu nome), pelo que me parece você está tendo algum erro de falta ou de sobra de aspas na linha 260 do seu código. Se não achar o erro poste para nós um trecho (pouco antes e pouco depois da linha 260) do seu código do REL_VEN.PRG

Aproveitando uma pergunta relacionado ao mesmo tema, Maligno. Caso queiramos utilizar o -PRINT: diretamente da linha de comando, isto é: através do WAPI.EXE. Digamos por razão de estarmos utilizando um arquivo BATCH (ja sabemos que sua indicação é utilizar em forma de LIB através do PRINTFILE(), por neste tem todo um tratamento sobre sua parametrização) mas digamos que é assim que queremos utilizar. A sintaxe segundo o WAPI.C do switch -PRINT é: -PRINT:<printer>;<report>;<title>;<paged>;<pages>;<reverse>;<count>;<group>;<resultFile>

É obrigatório informar TODOS os parâmetros deste switch ? Nesse caso quais são os parâmetros obrigatórios para enfileirar no spooler ?

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 22 Set 2008 10:12
por Maligno
Se não achar o erro poste para nós um trecho

Já indiquei o erro pro colega. Observe como ele montou a lista de argumentos da chamada da função.

É obrigatório informar TODOS os parâmetros deste switch ?

Sim, conforme disposto no help contido no WAPI.C: "OBS1: Todos os parâmetros são obrigatórios."

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 22 Set 2008 10:27
por Pablo César
Já indiquei o erro pro colega.
Sim isso ja observei Maligno. O que eu me referia ao erro em si, pois mesmo que a sintaxe da chamada de função esteja incorreta (no seu aplicativo), mesmo assim não seria motivo para estar dando esse tipo de erro. Apenas quis complementar a detecção do erro na compilação.

Pablo César escreveu:É obrigatório informar TODOS os parâmetros deste switch ?
Maligno escreveu:Sim, conforme disposto no help contido no WAPI.C: OBS1: Todos os parâmetros são obrigatórios.
É uma pena para mim, que por causa da novas implementações (sobre impressão seletiva) venha a dificultar o uso do switch -PRINT. Digo isto, porque antes não era assim e foi também por esta razão que eu tinha te pedido para desvincular as funções de impressão seletiva. No entanto, eu entendí bem o seu motivo de estar tudo no mesmo switch (apesar de eu ainda discordar da vinculação). Mas repito, não tem problema ! Se o comandante diz que tem que ser assim... faremos assim então. Eu apenas ressaltei para que fique de forma mais esclarecedora quando a esta função (soa como crítica, mas sem distinção alguma). Ruim seria não ter opção alguma, certo ?

MensagemEnviado: 22 Set 2008 10:39
por Maligno
pois mesmo que a sintaxe da chamada de função esteja incorreta (no seu aplicativo), mesmo assim não seria motivo para estar dando esse tipo de erro.

Separar os argumentos de uma função com ponto-e-vírgula dá esse mesmo tipo de erro. Se puder, faça um teste e verá.

por causa da novas implementações (sobre impressão seletiva) venha a dificultar o uso do switch -PRINT.

Também por esse motivo sempre incentivei o uso da função. Tomei o cuidado de manter a lista de argumentos compatível entre as versões. Quem usou a função desde o início não teve esse problema de compatibilidade. Aliás, em todos os casos usar a biblioteca é muito melhor que usar o WAPI.EXE diretamente. Só o conforto já justifica o uso.

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 22 Set 2008 12:18
por Pablo César
Separar os argumentos de uma função com ponto-e-vírgula dá esse mesmo tipo de erro.
Tem toda razão colega, me desculpe !. Agora percebo que o que você denotava era os ponto e vírgulasem lugar de vírgula para separar os parâmetros. Perdão, errei na interpretação.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 02 Out 2008 11:39
por Tim9
Maligno e Pablo, muito obrigado pela atenção. Troquei os "ponto-e-vírgula" por "vírgula" e o erro persistiu, então diante da minha "leiguice" ficou muito difícil a utilização da Wapi, então busquei outra solução mais fácil e rápida.

E para os leigos como eu, foi assim como resolví o meu problema de impressão com o clipper e o Windows XP e com a vantagem que imprime em matricial, jato de tinta, laser e usb .

Primeiro verifiquei que os softwares disponíveis para impressão com o clipper, tipo, USB, WINPRIN, DOSPRIN, WAPI e outros exigem que seja gerado previamente um rel.txt ou rel.pr ou rel.prn.

Já que isso é necessário, então gero um rel.txt e abro o worpad.exe que me dá chance de escolher qualquer impressora através do seu gerenciador de impressão.

O comando que usei é aquele simples:

SWPRUNCMD("RUN /C START WORDPAD.EXE REL.TXT")

Pra mim satisfaz plenamente as minhas necessidades.

Volto a agradecer a todos e em particular ao grande mestre Malígno e ao atencioso Pablo Cesar.

A propósito o meu apelido na vida real é Tim e meu nome é Olynthes.

Um grande abraço a todos.

Tim.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 02 Out 2008 11:55
por Maligno
ficou muito difícil a utilização da Wapi

Se você quiser nos mostrar seu código de impressão e nos descrever exatamente como acontece o erro, podemos tentar ajudá-lo a resolver essa questão.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 06 Out 2008 11:43
por Tim9
Maligno mais uma vez obrigado, não me canso de agradecer a você e a todos deste maravilhoso forum, pois é aqui que algumas vezes dei a minha modesta contribuição e muitas vezes obtive ajuda imensurável.

Vou deixar pra tentar a Wapi em outra ocasião, pois já não tenho mais o código de impressão com a utilização da Wapi, uma vez que encontrei outra solução.

Valeu e obrigado.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 06 Out 2008 14:09
por Maligno
Se uma outra forma resolvou o seu problema, já fico contente. Quando quiser tentar a WAPI novamente e tiver alguma dúvida, é só dizer. :)

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 06 Out 2008 19:07
por Tim9
Valeu Maligno.

Permita-me fazer uma correção no comando que utilizei, o correto é:

SWPRUNCMD("CMD C\START WORDPAD.EXE REL.TXT", 0, "", "")

Mais uma vez obrigado.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 04 Nov 2008 19:36
por edegar_metodo
amigo Tim9,
eu uso do jeito simples
wordpad /p recibo.rtf (ja esta formatado para rtf),
mas imprime apenas na impressora padrão, da forma como vc utiliza, temos outros parametros, sera que eles permitem a impressao em outra impressora que nao seja a padrao?

agora ao amigo maligno:
como disse anteriormente ja tenho o arquivo formatado para .rtf (lembra-se...rs) a função WAPI permite a impressao deste arquivo de uma forma direta (acredito que funciona perfeito com arquivos de texto..certo?) ou a funcao win32prn pode resolver o problema?
ou deveria esquecer a formatacao do .rtf e voltar a usar os comandos de impressao da epson?
outra pergunta:
tenho notado nos varios topicos que andei lendo nos ultimos dias, que existem algumas solucoes para a impressao usb, onde dizem que praticamente nao mudam quase nada no programa e imprime beleza.. ai vem a pergunta: eu uso em meus relatorios, expandido, condensado, italico, negrito, (isto no dos) agora no windows a letra tam 12 cabem 79 caracteres e nao 80, a tam 10 cabem 94 e nao 96, a tam 7 135 e nao 136 ....como disse em meus relatorios uso o tamanho total das colunas e embora perdi umas colunas ganhei algumas linhas...(ex. um pedido de venda feito em formulario razao que cabem no dos 12 itens no windows cabem 18..rs) a lista de precos (que imprimo em condensando....) caiu pela 60%,, como eles conseguiram ajustar seus programas com pouco trabalho....( nao vale dizer que usaram letras menores e deixaram os espacos sobrando a direita..rs)

Caso algum outro amigo tenha uma ideia estou no aguardo.

A todos mais uma vez obrigado

Edegar

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 04 Nov 2008 19:49
por Maligno
agora ao amigo maligno:
como disse anteriormente ja tenho o arquivo formatado para .rtf (lembra-se...rs) a função WAPI permite a impressao deste arquivo de uma forma direta (acredito que funciona perfeito com arquivos de texto..certo?) ou a funcao win32prn pode resolver o problema?

Não. A WAPI imprime apenas e tão somente no modo RAW (crú), ou seja, você é quem deve traduzir, formatar, etc. Se a win32prn imprime RTF eu não sei. Acredito que não. Assim como acho que nenhuma das soluções "USB", já amplamente discutidas no fórum, imprima RTF. Mas se não me engano, há muito tempo atrás, alguém postou uma solução que convertia arquivos desse tipo. Não lembro exatamente. Mas meu conselho é que você crie um novo tópico para discutir exclusivamente esse assunto.

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 04 Nov 2008 20:42
por Pablo César
Maligno escreveu:amplamente discutidas no fórum, imprima RTF. Mas se não me engano, há muito tempo atrás, alguém postou uma solução que convertia arquivos desse tipo. Não lembro exatamente.
Sei que não tem a ver com a Wapi, mas como ficou dúvida aqui vai...

As soluções com respeito a RTF foram apresentadas pelo colega Rochinha em:

viewtopic.php?f=43&t=3221&p=12057#p12057

viewtopic.php?f=43&t=7138&p=47050#p47050

Maiores informações postar nos links mencionados.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 06 Nov 2008 08:38
por Tim9
Prezado Edegar,

O comando por mim postado abre o gerenciador de impressão do Windows e mostra todas as impressoras disponíveis na rede e permite que vc escolha qualquer uma delas.

Faça um teste.

Abraços.

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 09 Mar 2009 14:19
por Pablo César
Oi Maligno !

Eu de aqui de novo, para ver se ainda existe algum estímulo para prosseguir com um dos itens mais polêmicos (na minha opinião) nas futuras implementações do WAPI. Que a criação de uma função que pudesse retornar o modo de exibição da sessão: JANELADO ou TELA CHEIA.

De tanto que foi questionado tanto na exibição como no armazenamento em arquivo sobre o padrão OEM e ANSI achei que talvez poderia ser pesquisado sobre API em forma de função que pudesse retornar qual é o padrão de exibição o que poderia estar aliado (ao menos em XP) com o modo janelado ou fullscreen. O que você acha, talvez poderia ser esta uma opção para viabilizar a detectção do modo de exibição de seção do aplicativo em modo console ?.

No site de suporte VB da Microsoft menciona algo sobre isso:
http://support.microsoft.com/kb/75857/pt-br

Quem sabe é possível encontrar algo em C++ para poder implementa-lo no WAPI ??

MensagemEnviado: 13 Mar 2009 13:24
por anacatacombs
Boa tarde.

Estou "tentando" utilizar alguns recursos da WAPI, porem estou com um problema :D
Consigo utilizar o SetButtonX sem problemas(e inclusive esta sendo bastante util)
No entanto, quanto tento utilizar : IsInternet ou SetAppTitle me retorna o seguinte erro ...
SX_DEFTRIG: Unrecoverable error 667: Eval Stack Default.
O estranho é que "eles" funcionam, mas o erro acontece na hora de abrir o banco de dados.. alguns até abrem...
Se eu retiro a chamada, o sistema abre normalmente.
Certamente é alguma "comida de bronha" da minha parte, mas já li esse longo e cansativo tópico e não consegui encontrar nada que pudesse solucionar essa questão.

Só para constar: Quando executo direto pelo EXECUTÁVEL não acontece o erro... só acontece quando executo pela LIB.

Aguardo Resposta (Nem seja um "NÃO SEI", ou "Guria, mude de profissão")

[]'s

Ana

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Mar 2009 19:31
por Maligno
Pablo César escreveu:talvez poderia ser pesquisado sobre API em forma de função que pudesse retornar qual é o padrão de exibição o que poderia estar aliado (ao menos em XP) com o modo janelado ou fullscreen.

O padrão de exibição deste ou daquele modo é o próprio modo. E a única forma, a meu ver, de descobrir qual é o modo ativo, seria por algum (obscuro) recurso da API, que eu não encontrei. E pra ser sincero, e olhando o tempo que demorei pra responder sua mensagem, está difícil arranjar tempo pra mexer na WAPI. Tenho um sistema de produção industrial inteiro pra refazer em Windows. E por mais cômoda que seja uma IDE, muito código ainda precisa ser escrito. Fora outros dois programas que estão na "fila". E na eventualidade de sobrar algum tempo pra dedicar à WAPI, há outras coisas (desculpe dizer) mais importantes para o projeto. Consegui terminar o modo residente. Falta apenas criar (e gerenciar) as threads das tarefas. Isso é mais prioritário. Desabafando,... Preciso parar para me organizar melhor nas minhas tarefas. É que os últimos tempos têm sido bem difíceis.

Mas nada foi esquecido, nem abandonado. Aos poucos vamos conseguir. :)

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Mar 2009 19:37
por Maligno
anacatacombs escreveu:quanto tento utilizar : IsInternet ou SetAppTitle me retorna o seguinte erro ...
SX_DEFTRIG: Unrecoverable error 667: Eval Stack Default.

Como havíamos conversado anteriormente,... Duas dicas para tentar resolver o problema, que é estranho, haja vista que problema de pilha é coisa rara de acontecer.

Ou você aumenta o "stacks do BLinker, que é algo que você já tentou e não deu lá muito certo, porque o problema apenas foi "transferido" de lugar.

Ou você tenta remover o utilitário wapi.exe de dentro do seu programa, criando em algum lugar do seu programa, uma função chamada WAPI2File() que apenas retorne TRUE. Esse artifício fará com que o linker ignore qualquer busca desse símbolo na biblioteca. Logo, o utilitário não mais estará dentro do EXE principal. Isso, claro, implica em ter o utilitário no mesmo diretório onde ele seria descarregado, ou seja, no diretório da própria aplicação, que é o local "default".

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 14 Mar 2009 08:28
por Pablo César
a única forma, a meu ver, de descobrir qual é o modo ativo, seria por algum (obscuro) recurso da API...

na eventualidade de sobrar algum tempo pra dedicar à WAPI, há outras coisas (desculpe dizer) mais importantes para o projeto...

Consegui terminar o modo residente. Falta apenas criar (e gerenciar) as threads das tarefas. Isso é mais prioritário. Desabafando,... Preciso parar para me organizar melhor nas minhas tarefas.
Take easy man ! Não se preocupe, o meu intuito foi mais para tentar ajudar, dar uma opinião, se bem que depois ví que a minha sugestão não era por esse lado. O Leonardo postou um exemplo em xHarbour, mas aquilo só serviu para detecção do modo de uma string e nada com respeito ao ambiente (viewtopic.php?f=1&t=9174#p51870).

Na minha opinião, como ja disse antes, esta função é a mais importante de todas. Quem ja não precisou orientar ao usuário de dentro da aplicação, para que alternasse com "Alt Enter" para mudar o modo ?. Quantos colegas ja perguntaram se dá para reproduzir/acionar as teclas "Alt Enter" ?. Nesse ultimo caso um colega verificou que em tela cheia as acentuações aparecem normalmente mas em modo janelado: não. Vão surgindo casos que na minha opinião bem poderiam ser resolvidas mediante uma função que retorne se a sessão está em modo janelado ou fullscreen.

Agora, com respeito a minha insistência... desculpe eu sou assim mesmo. Não posso cobrar de você nada, sim agradecer tudo o que tem feito por nós. é que ja faz mais de dois anos que venho esperando uma solução. Não é sua culpa é nossa, talvez por ainda insistirmos numa ferramenta que é difícil se adequar ao ambiente Windows.

Demais tome seu tempo da forma que achar melhor, não se sinta em comprisso. De ser assim mais vai demorar. As coisas devem ser gerenciadas conforme as nossas necessidades, é prorietário satisfazer um cliente, pois é ele que ajuda pagar nossas contas. A nossa satisfação em realizar metas, quebrar paradigmas, podem se adequar no momento oportuno ou até mesmo quando sentimos que há uma necessidade de fazé-lo. Só me permita de vez enquando dar uma pitadinha no gande molho da sua receita.... hihihi

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 14 Mar 2009 08:43
por Pablo César
SX_DEFTRIG:
Ana, é essa parte do erro que aparece ? Ou está mal escrita ?

O erro Unrecoverable error 667: Eval stack fault sem dúvidas é problema de memória. Tem alguns casos, como este relatado pelo nosso colega Rochinha: viewtopic.php?t=2646&highlight=unrecoverable+error+667&sid=ccd4abdaef7125ab9395727fc3de2bbb#p9545

Esse erro acontece só naquela máquina ? Foi alterado o STACK do config.nt ou config.sys ? Tem sido compilado de quê forma ?

Ana, como você mencionou que esse erro dá na hora de abrir os BDs, então verifique essa questão levantada pelo Rochinha, no link anterior.

IsInternet ou SetAppTitle eu utilizaria num aplicativo separado de fora da sua aplicação. E mandaria executar através de arquivo batch antes de chamar seu programa. Eu faço assim e não dá erro algum.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 14 Mar 2009 09:07
por anacatacombs
Ô Pablo :)

Claro que eu escrevi direito, é essa parte do erro mesmo, não está mal escrita ...

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 14 Mar 2009 09:12
por Pablo César
Ok, ok, tudo bem. As vezes cometemos erro de digitação. Digo isto porque por incrível que pareça não existe NENHUMA menção na internet sobre a string "SX_DEFTRIG". Você ja percebeu ?

De qualquer forma verifique as outras possibilidades que eu indiquei e nos retorne, certo ?

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 14 Mar 2009 09:20
por Maligno
Pablo César escreveu:Digo isto porque por incrível que pareça não existe NENHUMA menção na internet sobre a string "SX_DEFTRIG".

A função sx_DefTrigger() é parte da SIX. Está no NG. Aliás, ela pode até nem ter utilizado essa função, mas se o símbolo fizer parte de um módulo que contém uma função utilizada, o módulo todo será encadeado ao EXE principal. E a função desalmada irá junto.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 14 Mar 2009 09:24
por anacatacombs
Sim, eu notei que realmente não tem nada a ver, uma vez que o erro "muda" de lugar a cada tentativa de solução, mas achei interessante mencionar... se eu não tivesse dito, aposto que alguém perguntaria...

Quanto ao link que vc me passou.. Não, o problema não é esse. Ja tinha visto aquele tópico umas 90849052 mil vezes antes de postar, inclusive, retirei a função de abertura de arquivos e o erro persiste .

Memória... creio que não seja isso não.

Tentei aumentar o "STACK", mas não resolveu.. o erro apenas mudou de lugar ....

Como eu compilo? vc quer saber se eu uso o blinker? Sim, eu uso..

É, por batch realmente dá certo, mas eu não gostaria de fazer a verificação APENAS antes de entrar no sistema.. como disse anteriormente, usarei mais recursos da WAPI, e não gostaria de resolver o problema dessa forma.

Tentei o que o Maligno pediu pra tentar, mas "teoricamente" não deu certo, vou fazer mais alguns testes a respeito, e vejamos como se comporta.

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 14 Mar 2009 09:27
por Pablo César
Também achei que fosse da RDD SIX e que o problema não seja causado pela utilização das funções da WAPI e mais estranho a experi~encia relatada pelo Rochinha que também tem a ver com manipulação dos arquivos de dados. Pedí para Ana para desvincular as funções IsInternet ou SetAppTitle a fim de denotar a presença de outra falha no sistema e que ora também pudesse resolver sem precisar adequar mais memória.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Abr 2009 09:46
por anacatacombs
Como niguém me respondeu no outro tópico, resolvi postar a duvida aqui (da proxima vez, vou tentar tirar a roupa pra ver se alguem responde )

Na impressão por páginas, como deve ser feito a marcador no inicio de cada página? Tentei de várias formas, porem não obtive sucesso.. o erro que retorna é -8 (erro na criação do índice das páginas).

Gostaria que alguma alma caridosa postasse um exemplo.

[]'s

Ana

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Abr 2009 09:55
por Maligno
Como niguém me respondeu no outro tópico, resolvi postar a duvida aqui.

Que outro tópico? Não lembro de ter visto. Mas,...

O marcador de página é composto por três caracteres: chr(2)+chr(11)+chr(3). Está no README. :)

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Abr 2009 14:05
por Pablo César
Ana escreveu:Como niguém me respondeu no outro tópico, resolvi postar a duvida aqui
Agora que você disse, fui buscar suas mensagens e notei que neste tópico você fez uma pergunta. Desculpe, passou despercebido.

Ana escreveu:(da proxima vez, vou tentar tirar a roupa pra ver se alguem responde)
Bem... é opção sua... quem sabe ? Eu por exemplo trabalho maior de cuecas... comodamente na minha csa, é claro... hihihi (ô desvio de assunto outra vez...)

Ana escreveu:Na impressão por páginas, como deve ser feito a marcador no inicio de cada página? Tentei de várias formas, porem não obtive sucesso.. o erro que retorna é -8 (erro na criação do índice das páginas).
Sinceramente ? Nunca usei, e acho que talvez nunca use, acho muito complicado. Coitado o colega... ele deve ter gastado um certo tempo para obter essas opção a mais. Mas vejamos o que a documentação disse a respeito:

No arquivo WAPI.C o Maligno escreveu:OBS4: Se o sistema tiver de manipular páginas pelos seus números, será preciso que cada início de página esteja Marcado com um identificador (ou tag). Isso possibilitará Encontrar qualquer página por seu número. Tal identificador é representado por um grupo de códigos ASCII: 02, 11 e 03 (decimal), ou STX+VT+ETX. Evidentemente, tais símbolos serão ignorados na impressão.


Ana escreveu:Gostaria que alguma alma caridosa postasse um exemplo.
Assim como nós voê não viu o exemplo que o Maligno deu neste tópico ? viewtopic.php?f=1&t=9269&p=52486#p52483

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Abr 2009 14:13
por Pablo César
Maligno, neste tópcio viewtopic.php?f=1&t=9269&p=52486#p52483 você deu o exemplo e esintaxe, especificando o número das páginas:

PrintFile("#", // impressora "default"
"saida.txt", // nome do arquivo que contém o texto
"Meu Titulo", // título do relatório
.T., // TRUE indica que as páginas contém os marcadores de início de página
"1,2-15,50-", // imprimir as páginas 1, 2 até 15 e de 50 até a última
.F., // FALSE indica que não quero imprimir tudo
.T., // TRUE indica que quero que sejam impressas apenas as páginas PARES
.F., // FALSE indica que não quero imprimir as páginas ÍMPARES
.T., // TRUE indica que quero imprimir em ordem invertida
2, // duas cópias de tudo
.F. // imprimir não agrupadas, ou seja, 2 cópias de cada página juntas: 1,1,2,2,3,3,4,4,...
)

Nesse exemplo, o que eu destaquei, mencionam p´paginas ímpares, no entanto no sétimo parâmetro você diz para a função imprimir "apenas" as páginas PARES. Pergunto: Se essa informação for contrária com a numeração passada (2, 4, 6, 8, 10, 12, 14, 16..48, 50...etc) qual é a ação que irá prevalecer ? A numeração dada ou esse 7º parâmetro ?

Muito complicado, Maligno... talvez eu que não esteja gostado, pela complexidade da função e ainda ache que seja de uso exclusivo.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Abr 2009 14:21
por Maligno
Não tem nada de complicado. Se você menciona um intervalo de páginas que contenha páginas ímpares (ex: 1-50), pode ainda assim mandar imprimir apenas as pares. Basta configurar o argumento correspondente. Internamente a função vai preparar a lista de páginas e obedecer o critério de impressão: pares, ímpares ou todas. Mais simples que isso impossível.

Faça um bom teste. Vai perceber que é mesmo muito fácil. Mas é claro que a interface para o usuário deve ser feita de forma a facilitar. Eu inclusive, sugiro copiar a mesma que o Windows oferece. Se já é fácil pra você, como programador, para o usuário poderá ser feito algo que fique ou fácil ou complicado. Você é quem deve cuidar disso.

Se você acha isso tudo complicado de usar, quero ver o dia em que for usar uma chamada de função com múltiplas estruturas da API do Windows, com função de "callback". Aí você vai ver o real sentido da palavra "complicado". :)))))

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Abr 2009 15:16
por Pablo César
Nem me fale... esse mecanismo de POO, não é fácil, aliás a programação puramente orientada a objetos está dificl de assimilar, eu estou apanhando pacas...

Mas não fique triste, ainda vou ver alguém elogiando essa sua função. Você sabe: eu desde o início sempre fui em contra dela. Mas isso porque achei que daria um trabalhão fazer mais essa opção de impressão e mais ainda pelo padrão que ela exige (na minha opinião, algo que personalizado). Só não sei se funciona, esse erro -8 que para Ana está dando, o quê seria ?

Na verdade para explicar todas essa opções (apenas a de impressão seletiva me refiro) do printfile, seria necessário um organograma para entender a verdadeira intenção de impressão do usuário. Claro que você ainda ampliou em opções (as de número pares e ímpares mesmo especificando) comparado ao aplicativos da MS.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Abr 2009 15:32
por Maligno
Nem me fale... esse mecanismo de POO, não é fácil, aliás a programação puramente orientada a objetos está dificl de assimilar, eu estou apanhando pacas...

A API do Windows não é OOP. É totalmente procedural. :)

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Abr 2009 16:11
por Pablo César
A API do Windows
Ahhh sim API era o focus da conversa...

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Abr 2009 17:13
por anacatacombs
Caro Plabo.

O Maligno me fez desistir da ideia de tirar a roupa, agradeçam a ele.

Pablo César escreveu:(...)Só não sei se funciona, esse erro -8 que para Ana está dando, o quê seria ?


Pelo que eu entendi (Maligno, me corrija se estiver errada) e li no WAPI.H é quando vc faz a marcação no inicio da pagina de maneira incorreta, e a WAPI não consegue criar um tal de indice de marcador de páginas. Visto que a mensagem original do erro é : erro na criação do índice das páginas.

Fiz um teste aqui e funcionou xuxu beleza, só tive que adicionar o codigo no cabeçalho.

Pablo César escreveu: Assim como nós voê não viu o exemplo que o Maligno deu neste tópico ? viewtopic.php?f=1&t=9269&p=52486#p52483


Me referia ao modo de fazer a marcação de páginas.

Enfim... o importante é que funcionou nos testes, e agora é só implementar.

Mais uma vez obrigada :)

[]'s
Ana

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 08 Abr 2009 08:47
por Pablo César
Pablo César escreveu:ainda vou ver alguém elogiando essa sua função
Bom finalmente aconteceu e pelo visto sem tanto trauma...
Ana escreveu:Fiz um teste aqui e funcionou xuxu beleza..//..
o importante é que funcionou nos testes, e agora é só implementar.

Mais uma vez obrigada
Beleza, quando perguntarem sobre detalhes de como usar essa função, podemos chamar você Ana e fico feliz mesmo em saber que em mais esta função o WAPI está auxiliando muitas pessoas (eu sou um que utilizo, bastante).

Me referia ao modo de fazer a marcação de páginas.
Ana, poderias anexar um exemplo desse arquivo gerado, ja com as marcações devidas, para vermos em exemplo ?

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 14 Abr 2009 19:27
por anacatacombs
Boa Noite..

Como sempre.. atrasada, mas antes tarde do que nunca. (Ouvi dizer)

Opa, claro que tem. É bem simples (chega a ser ridiculo, sem exageros, fiz agora pouco "na mão") mas serve pra teste.

Utilizei o WAPI.EXE para imprimir apenas a pagina 2, duas vezes, da seguinte forma:

 WAPI -PRINT :#; TESTE.TXT;"TESTE";T;2;T;2;F;RESULT.TXT 


Bom.. é isso...
[]'s

Ana

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 25 Nov 2009 09:10
por wfr123
Ola, para todos.

Diariamente entro num site digito o login e senha escolho opção de relatorio digito o tipo de relatorio os valores tipo data e tudo mais e o site gera um arquivo .xls que gravo e depois meu sistema em clipper le este arquivo e realiza varios tratamentos.

Gostaria de saber se tem como automatizar esta parte de entrar no site é digitar as informações até ele gerar o arquivo em xls, isto atraves do clipper ou de algum outro modo, como na wapi por exemplo.

Agradeço a atenção.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 25 Nov 2009 09:52
por Maligno
Se você puder fazer isso tudo por meio de um script PHP, poderá executá-lo através da função DLoadFile(), da WAPI. A título de exemplo, fiz um script PHP para capturar as informações de data/hora do servidor, usando essa função.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 25 Nov 2009 19:18
por sygecom
Se compilar com Harbour seu aplicativo, você pode usar OLE e gerar o Excel nativamente pelo seu aplicativo, de uma procurada no forum que já postei exemplos e nas pastas SAMPLES do Harbour tem mais exemplos.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 25 Nov 2009 19:56
por Maligno
Pra qualquer problema que apareça em Clipper, sempre será possível resolver melhor com [x]Harbour.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 26 Nov 2009 17:06
por wfr123
ok, ok, ok,
Ok, maligno.
Ok, sygecom

vou baixar o xDev e o harbour e começar a sofrer para aprender, agora vão sofrer junto comigo, pois vou postar todas as dúvidas que não encontrar.

ai, ai. boa sorte para mim.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 01 Jan 2010 22:46
por Hermeto
Caro Maligon, utilizado a funcao dloadfile adaptada para envio de sms pelo clipper, verificamos que as mensagens enviadas sempre vao em letras minusculas. Acho que deve ser em virtude de quando foi criada esta funcao, o acesso por http era limitado a letras minusculas, e Vc deve ter incluso a rotina/funcao (lower) de passar o texto/parametro em minusculo.

Pergunta: Existe alguma possibilidade de deixar o texto (linha de chamada http) original? :(

Utilizamos da seguinte forma:
//
ctxtsms:=[Teste de Envio de SMS com letras MAISCULAS e /ou Minusculas]
csmsret:[]
clink:=[http://www.fastsms.com.br/sms.cfm?id=SENHA&senha=999999&para=8599850360]+[&texto=]+ctxtsms
if dloadfile(clink,@csmsret)
end
//
A mensagem (SMS) é enviada com sucesso, mas chega no destinatario da seguinte forma:
[teste de envio de sms com letras maisculas e /ou minusculas]

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 02 Jan 2010 12:08
por Maligno
Sim. Para facilitar a análise da linha de endereço, havia uma chamada à função strlwr(), que forçava toda a linha para caixa baixa. Mas em virtude do seu problema, mudei o código para preservar a caixa de tudo o que vem depois de "HTTP://". É só baixar novamente o mesmo pacote: wapi_v1.03.zip.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 03 Jan 2010 08:51
por Hermeto
Maligno, realmente não tinha nome melhor pra Vc. :-Y

Você é o CARA! :{

MUITO OBRIGADO! :)Pos

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 02 Fev 2010 09:01
por Hermeto
Maligno,
Estamos utilizando a rotina SETWINCLIP da seguinte forma:
CCPF:=C17CPF
SETWINCLIP(CCPF)
Utilizamos o Windows XP e Windows Vista.
Para alguns computadores com o Windows XP funciona e para outros não.
Você poderia nos auxiliar para resolver o problema, pois alguns computadores funcionam e outros não.
Para Você ter uma idéia, este Micro que não funciona, a configuracao básica dele é Corel 2 Duo, 4gb de memória

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 03 Fev 2010 07:39
por Pablo César
Hermeto quando você menciona que fez:

CCPF:=C17CPF
SETWINCLIP(CCPF)

Você quis dizer CCPF:="C17CPF" (entre aspas) pois esta variável deveria ser do tipo caracter. Nesses PC que não funciona o SETWINCLIP, você fez algum teste de colocar na área de transferênciade forma manual (Ctrl-C e Ctrl-V) ? Mas atenção, apenas texto. Se não meengano tem no Windows uma opção para desabilitar a utilização da área de transferência (Desativar Clipboard), eu lí algosobre isso em (mas não tenho certeza se procede):

http://supportwiki.steampowered.com/pt/ ... Paged_Area

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 03 Fev 2010 09:54
por Hermeto
Pablo, a referência CCPF:=C17CPF é que C17CPF é um campo do BD tipo caractere, onde utilizamos para colocar o CPF do Cliente na área de transferência.
Fomos verificar o q Vc sugeriu, e fizemos um teste de CTR+V e CTR+C, e verificamos que está funcionando, inclusive quando utilizamos o mesmo comando da forma abaixo, FUNCIONA:

setwinclip( "%F:C:\TESTE.TXT")
sendo arquivo TESTE.TXT gerado pelo sistema com dados específicos.

Por via da dúvida, utilizamos no prompt do DOS o comando edit teste.prg e utilizamos o CTR+V e CTR+C e deu certo...

Temos o Sistema rodando em 15 micros, sendo 2 deles não dando certo... Se alguém tiver alguma DICA ou SUGESTÃO, Agradecemos.

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 03 Mar 2010 08:42
por Pablo César
Mensagem respondida atendendo ao tópico: viewtopic.php?f=1&t=10320&p=58784#p58784

ssflavio em outro tópico escreveu:Pablo fez uma referencia a biblioteca WAPI, inclusive me mandou a lib e o executavel.
Sim indiquei esta biblioteca, pois tem ajudado muito aos programadores em Clipper. Apesar que as tentativas que fiz no exemplo postado, a recuperação do foco não foi possível em todas as vezes.

ssflavio em outro tópico escreveu:Eu já tinha visto referencias a esta biblioteca, para saber se a janela está maximizada ou nao e para setar o foco em determinada janela.
Eu acho que o WAPI, não faz distinção se está maximizada ou não. Acho que o status da janela ou sessão, ainda está para ser resolvido. O Maligno ainda não encontrou uma forma de saber inclusive se a sessão está em modo janelado ou tela cheia. Essa detecção seria muito útil, mas ainda não existe.

ssflavio em outro tópico escreveu:Não entendi direito, primeiro rodo o WAPI.EXE e depois rodo a aplicacao que contem a biblioteca WAPI?
O WAPI.EXE é um utilitário feito em C++ com o propósito de incrementar recursos de APIs (por isso o nome WAPI, Windows API) aos programas em Clipper. Para isso o Maligno utilizou um recursos que ele mesmo inventou para que certas funções possam ser incrementadas à WAPI.LIB. E por isso o WAPI.EXE precisa estar junto com a aplicação porque dentro da LIB executa o WAPI.EXE (acho que é isso mesmo que faz, não é Maligno ?).

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 18 Mar 2010 19:35
por Maligno
Bom, eis minha primeira mensagem depois de longo período afastado. :)

Na verdade, o WAPI.EXE foi feito em C e não C++ (OOP). E sim, esse utilitário precisa realmente acompanhar o executável do usuário. Ele é o "cérebro" de tudo. A biblioteca WAPI.LIB traz apenas a interface através da qual o acesso e a configuração do utilitário é muito facilitado. Daí minha recomendação de não utilizá-lo diretamente.

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 09 Abr 2010 16:47
por Pablo César
Oi Maligno, eis eu aqui novamente. Tenho 1 dúvida, 1 sugestão, 1 lembrete/referência e 1 possível solução para uma questão antiga. Para ser mais esclarecedor, irei por partes (como dizia o Jack Stripper)...

1. Minha dúvida: É possivel adicionar os itens de programas que estão carregados no tray system como resultado da função -GETAPPSINFO ?
2. Uma sugestão: Sendo possível, claro... colocar um segundo parâmetro na função -SETBUTTONX ? Este parâmetro, seria opcional, para atender o número do handle. Assim poderíamos desabilitar o botão do "x" que encerraria determinada sessão.
3. O meu lembrete que mais servirá de referência, é para rever sua possível implementação de função que disponibilize aplicativos no tray system. E de passo apresento um freeware que funciona mas tem suas limitações. O Trayconizer, disponível em duas versões (95/ME/98 e NT/2000/XP), tem como defeito não verificar antes de colocar no tray se tal aplicação ja existe na memória. E aproveito a ocasião para deixar registrado com o fim de prevenção desse erro na sua futura implementação.
4. A possível solução sobre a detecção do modo da sessão: tela-cheia ou janelada. Encontrei um aplicativo que lista quais são as janelas ou sessões que estão em execução (parecido com o GETAPPSINFO), trazendo 17 informações de cada sessão/aplicação em forma de colunas. Uma das colunas que me chamou atenção foi a "Location" no qual constam as seguintes variações:

1- Dois parametros separados por virgula entre parentese, assim: (0,738)
2- A palavra: "Maximized"
3- E a palavra: "Minimized"

Esta ultima descrição, acontece quando a janela está minimizada. Mas o que me chamou mesmo a atenção, foi quando alternei a minha sessão DOS que estava em modo janelado para a tela cheia. Daí mudava em forma imediata da opção 1 (numero entre parentese) e 3 "Minimized" e nunca para "Maximized". O link para baixar o aplicativo é: http://www.nirsoft.net/utils/winlister.zip e seria bom analisar o que seria estes atributos. Possivelmente atarvés disso, podemos detectar o modo de exibição da sessão que ainda é um paradigma...

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 10 Abr 2010 18:17
por Maligno
irei por partes (como dizia o Jack Stripper)

Pensei que era "The Ripper". Ou ele fazia bico como GoGoBoy? :)))

1) Detectar programas no tray:
Vou ter que alterar a função (óbvio), mas ainda tenho que pesquisar a respeito. Mas a possibilidade é clara.

2) Um argumento adicional para o handle de uma determinada janela:
Sim, é bem fácil.

3) Função para mandar aplicações para o tray:
Demanda pesquisa, mas é possível.

4) Aquele velho problema de detectar o DOS está "fullScreen" ou não:
Mantenho o mesmo pensamento de antes: compensa? Nos dias de hoje, mais do que antes, acredito que não. Mas enfim, baixei o programa e verifiquei que tanto minimizado quanto em modo fullScreen, o programa devolve sempre o status de "minimized". Ou seja, ele também não detecta o modo, mas apenas supõe errôneamente que em modo fullScreen o programa está minimizado. Não vai ajudar. E mesmo que ele fizesse certo, para descobrir o que ele fez, daria um trabalhão descobrir como ele fez. Apesar de ser um programa pequeno, engenharia reversa sempre dá um bom trabalho. E tempo,...

E tempo é o que está me faltando atualmente. Estou penando para terminar alguns projetos pessoais e me preparando para "sumir" por mais algum tempo (uns 60 dias, se tudo correr como previsto). Aí já viu. A coisa fica complicada. Mas, se serve de consolo, ao menos posso dizer que nada foi e nem será esquecido. :)

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 10 Abr 2010 19:28
por Pablo César
Pensei que era "The Ripper". Ou ele fazia bico como GoGoBoy?
KAKAKA eu errei mas ficou engraçado !

Não sei se vale a pena, é que ainda possuímos sistemas em Clipper e temos carinho pelo que fazemos até o momento de não pudermos rodar mais em novos SO...

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 10 Abr 2010 19:41
por Maligno
KAKAKA eu errei mas ficou engraçado !

Mas de repente nem está de todo errado. Afinal, os strippers também tiram suas peças por partes (me esforcei pra não dar por perdido seu erro, hein?). :)))

Não sei se vale a pena, é que ainda possuímos sistemas em Clipper

Pessoalmente posso dizer que realmente não vale a pena coisa alguma dessa biblioteca, já que parei com Clipper de vez. Agora é só C++. No entanto, ratifico: não deixarei cair no esquecimento, até porque é C, o que me dá realmente muito prazer. É só mesmo a questão do tempo, como eu disse.

Vou aproveitar que a manhã de domingo sempre me dá uma preguiça desgraçada e vou tentar mexer em alguns dos ítens que você listou. ;-)

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Abr 2010 19:11
por Maligno
Curiosidade: qual a intenção em obter a lista dos ícones no tray?

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Abr 2010 20:51
por Pablo César
Existe um aplicativo que coloca o LAN MESSENGER no tray system só que o aplicativo é meio burrinho porque tenta carregar duas vezes e dá erro, mas ficam dois icones iguais, parecendo ocupar a memória a toa. Daí antes de colocá-lo no tray iria verificar antes se ja não estava carregado. E também acontece que o usuário poderá encerrar a aplicação pelo "x" da janela e não ficar mais no tray. Por isso da necessidade de passar a enxergar os programas no tray. E por consequente obtendo o nHandle servirá para a outra função de inibir o "x" com -SETBUTTONX.

Aproveitando a ocasião, você viu o KEYSTUFF ? Talvez sirva de referência para a implementação do WAPI. Procurando na internet acabei achando outra matéria que interessaria ler sobre a questão do modo FULLSCREEN: http://richardsbraindump.blogspot.com/2 ... on-is.html o código acho que é em .NET mas ja dá alguma idéia também para seu caso.

WAPI v1.04 - Funções da API do Windows

MensagemEnviado: 18 Abr 2010 13:09
por Maligno
Um novo pacote da biblioteca WAPI, agora em sua versão 1.04, está disponível, com algumas pequenas inclusões.
Como sempre, ele poderá ser baixado do diretório público do meu site.

Além de uma pequena alteração na documentação, foi adicionada a capacidade de direcionar o foco da função "SETBUTTONX" para determinada janela, informado o handle desta. Também foram criadas duas novas funções: "GETSYSTEMTRAYINFO", para obter dados dos ícones estacionados no tray do sistema e, GETVERSION", para obter a versão dos fontes do utilitário "wapi.exe". Eis a lista completa, já atualizada:

  • DELETEREGISTRY
    Apagamento de chaves do registro do Windows
  • FLASH
    Faz piscar o botão da janela na barra de tarefas
  • GETAPPSINFO
    Lista as aplicações atualmente sendo executadas
  • GETCLIPBOARD
    Lê o conteúdo do ClipBoard do Windows
  • GETDEFPRINTER
    Informa qual a impressora configurada como default
  • GETHDINFO
    Recupera algumas informações do HD da máquina
  • GETMYHANDLE
    Informa qual o número do "handle" da aplicação em foco
  • GETPRINTERS
    Lista todas as impressoras instaladas
  • GETWAPIVERSION
    Informa a versão dos fontes do utilitário WAPI.EXE
  • GETSYSTEMINFO
    Lista várias informações sobre o sistema
  • GETSYSTEMTRAYINFO
    Lista os ícones estacionados no "system tray"
  • GETWINDOWSINFO
    Lista várias informações sobre o Windows (versões)
  • HIBERNATE
    Coloca o Windows para hibernar
  • KILLAPPLICATION
    Provoca o encerramento incondicional de uma aplicação
  • PLAYWAVE
    Reproduz um som WAVE de arquivo ou de sistema
  • POWEROFF
    Desliga a máquina (shutDown)
  • PRINT
    Copia o conteúdo de um arquivo para o spooler
  • READREGISTRY
    Lê os conteúdos de chaves do registro do Windows
  • REBOOT
    Reinicia a máquina (restart)
  • SCREENSAVER
    Permite ler o estado atual do ScreenSaver ou mesmo reconfigurá-lo
  • SETAPPTITLE
    Modifica o título da aplicação na barra de título
  • SETBUTTONX (Alteração)
    Modifica o comportamento do botão "x" da barra de título da janela em foco
    Incluída a opção de direcionar o alvo da ação para qualquer janela
  • SETCLIPBOARD
    Grava um determinado valor para o ClipBoard do Windows
  • SETSTARTBUTTON
    Habilita/desabilita ou esconde/mostra o botão iniciar
  • SETTASKBUTTON
    Esconde/mostra o botão da aplicação na barra de tarefas
  • SUSPEND
    Coloca o Windows em estado de suspensão
  • URL2FILE
    Acessa a internet por HTTP para download de arquivos
  • WINDOW2TOP
    Força uma aplicação a obter o foco do Windows
  • WRITEREGISTRY
    Cria/grava chaves no registro do Windows.
A lista acima descreve sucintamente os parâmetros disponíveis no utilitário WAPI.EXE. Sempre lembrando que a biblioteca WAPI tem um conjunto completo de funções de abstração não só pra facilitar o uso do utilitário, mas também para tornar seu uso mais seguro contra bugs. Para usá-la, aconselho uma leitura inicial do README.TXT que está no diretório LIB. Ele contém as descrições detalhadas de todas as funções.

Essa é a situação atual da TODO list:
  • Controle de volume do som
  • Inclusão da informação do diretório "iniciar" na informação do sistema
  • Execução do WAPI no modo residente (codinome RES)
  • Bloqueio do teclado e mouse em nível global (requer RES)
  • Cancelamento de execução de WAVs (requer RES)
  • Execução de sons em lote (funcionalmente melhor com RES)
  • Apagamento seguro de arquivos (wipe file)
  • Execução de atalhos de teclado, próprios do windows (ex: Alt+Enter)
  • Criação de links para execução de programas
  • Funções de FTP: list, delete, upload, download, etc...
  • Criação de um help no estilo NG (Norton Guides)
  • Criação de um programa demo completo, com todas as opções disponíveis
  • Remover a dependência das bibliotecas CATools e NanFor

Sugestões, críticas, reclamações, etc... serão sempre bem-vindos. :)

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 19 Abr 2010 11:40
por Pablo César
Valeu Maligno ! Testei as funções e na linha de comando e tudo beleza ! Vou adaptar meu sistema para esses casos.

Gostei das implementações que você fez e creio que serão úteis para auxilio no modo console. Obrigado pela sua contribuição, meus parabéns !

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 20 Abr 2010 10:54
por asimoes
Olá Maligno,

Estou começando com a wapi fazendo testes com as funções da pasta printer,

Consegui gerar o executável: defprint usando o blinker 7, quando eu executo o programa me vem a seguinte mensagem:

Não foi possível localizar o pronto de entrada do procedimento GetProcessImageFileNameA na biblioteca de vinculo dinâmico PSAPI.DLL.

Alguma luz?

[]´s

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 20 Abr 2010 14:09
por Maligno
Realmente. Eu me esqueci de comentar no README que o PSAPI é nativo no XP ou versões posteriores. Mas mesmo com XP, pode acontecer (por algum estranho motivo) da DLL ser alocada em outro diretório que não o default (c:\windows\system32). Tente procurar pela DLL no seu HD. Se não encontrar, uma opção é baixar de algum lugar, como o DLL-files.com, onde se acha quase tudo, e de graça. Ou no próprio site da Microsoft (requer registro).

Mas um detalhe: não encontrei nada que que diga que é garantido o funcionamento dessa DLL em versões anteriores ao XP. Acho provável que no NT funcione, mas nos Windows 95/98/Me não é garantido. Teria que testar.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 21 Abr 2010 10:21
por asimoes
Eu testei no trabalho que é windows 2000 professional.
Vou testar na minha máquina que é xp, qq novidade retorno aqui.

[]´s

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 21 Abr 2010 21:58
por Pablo César
Eu também estou tendo problemas ao executar a WAPI.LIB, desta vez estou chamando GETSYSINFO(), deu erro em WIN98 dizendo: "Um arquivo .DLL requerido, PSAPI.DLL, não foi encontrado."

O pior que antes não dava esse tipo de erro, só agora está dando. Claro que o executável foi atualizado, mas terei que recompilar o meu aplicativo, pode ser que cesse esse erro. Mas por incrível que pareça, não estou conseguindo compilar. Mas este deve ser outro caso, que podemos tratar neste tópico: http://www.pctoledo.com.br/forum/viewtopic.php?f=1&t=10564&start=0 (este problema ja foi solucionado, foi problema atípico com o BLINKER).

Obs.: Só para registrar, o problema no WIN98 de PSAPI.DLL também acontece com qualquer switch do WAPI.EXE. Em outras palavras não está podendo ser usado em WIN98.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 07 Jun 2010 22:23
por ANDRIL
Pessoal que usa o executavel WAPI.EXE, estou chamando-o de dentro do meu sistema atraves do SWPRUNCMD e nao ta me retornando nada no arquivo de conteudo.

Estou usando a opção abaixo:

comando=rtrim(caminhod)+"\WAPI URL2FILE:"+'"'+cSite+'"'+';
"'+cArq+'";'+'"'+alltrim(str(cTime))+'"'+";"+'"'+cRet+'"'


Claro que a string de cSite é bem grande e juntando com os conteudos de cArq e
cRet, ultrapassam os 256 caracteres permitidos na linha de comando em ambiente DOS.

Então, acho que devido ao tamanho da string final que o WAPI nao esta executando a função, por que esta mesma função esta sendo usada em outro sistema, porem, atraves da WAPI.LIB funciona perfeitamente.

Tem alguma forma de passar o primeiro parametro do switch "-url2file: <meuarquivo>" em formato de arquivo???

Não posso usar a WAPI.LIB pois usava neste sistema e do nada começou a não rodar mais o sistema, por fim, como so uso este switch, fiz 2 funções equivalentes a isinternet e dloadfile chamando o aplicativo wapi.exe, so que agora como a linha de comando aumentou to tendo este problema.

Baixei o pacote da versao 1.04, mais continua acusando a falta da DLL PSAPI.DLL, como programo em um WIN98, não pude usar.

Grato.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 25 Jun 2010 15:32
por Mário Isa
Estou tentando baixar a WAPI.LIB lá do site do maligno mas tá dando link quebrado.
É que eu estou tentando copiar e colar utilizando 2 funções q tem la.
Alguem tem o link correto ?
Mário

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 25 Jun 2010 16:12
por Maligno
O link para a pasta onde estão os pacotes: http://pub.buzinello.com/index.php?d=./ ... pper/libs/

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 25 Jun 2010 16:16
por Maligno
Claro que a string de cSite é bem grande e juntando com os conteudos de cArq e
cRet, ultrapassam os 256 caracteres permitidos na linha de comando em ambiente DOS.

No fonte WAPI.C tem um help adicional, onde consta o switch "-PARMSFILE<fileName>", que serve justamente para resolver esse tipo de problema. Coloque todos a sua linha de comando num arquivo e o informe seu nome através desse switch especial. O WAPI.EXE lerá o arquivo como se fosse uma linha de comando.

PS: Me desculpe por não ter respondido antes. Não vi sua questão. É que às vezes entro no fórum e, por conta do tempo muito curto, mando marcar todas as seções como "já lidas". A pressa sempre traz algum transtorno. :(

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Jul 2010 07:37
por rochinha
Amiguinho Maligno,

Parabéns pelo belo trabalho.

Estou com uma duvida:

Gostaria de saber se seria possivel utilizar este comando:
WAPI -URL2FILE:"http://www.correios.com.br/encomendas/precos/calculo.cfm?&cepOrigem=05171340&cepDestino=01020000&peso=1&resposta=xml";"sedexw.xml";20;result.txt


Tentei usa-lo e não obtive resultado. O que posso fazer?, estou errando algo?

WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Jul 2010 08:17
por Pablo César
Executei na linha de comando esse exemplo do Rochinha e para mim funcionou. Isto é, baixou o arquivo sedexw.xml sem demoras e sem problema algum. Talvez algum impecilho proveniente do FireWall ??

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Jul 2010 12:49
por Maligno
Uma alternativa, para o caso de uma linha de comando longa demais: coloque essa linha de comando num arquivo texto comum e execute o programa com o switch "-PARMSFILE:<cmd_file>". Ou, caso prefira (e se puder), use a biblioteca de funções, que faz tudo isso de forma invisível.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Jul 2010 15:06
por rochinha
Amiguinhos,

Foi resolvido quando baixei a versão 1.0.4.

O meu interesse foi fazer acesso via webservice e consequentemente obter um resultado em arquivo manipulável.

O intento na verdade é testar o envio de comandos ou arquivos ao SEFAZ por este método.

Valeu a todos.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 13 Jul 2010 18:59
por Maligno
E deu certo? O WAPI utiliza a API WinInet, que utiliza o protocolo HTTP.

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 14 Jul 2010 08:08
por Mário Isa
Rochinha,

Você teria o mesmo tipo de comando só que para fazer o rastreio ?

Seja este link para rastreio

http://websro.correios.com.br/sro_bin/t ... 05443501BR

eu tentei assim e não deu certo

WAPI -URL2FILE:"http://websro.correios.com.br/sro_bin/txect01$.QueryList?P_LINGUA=001&P_TIPO=001&P_COD_UNI=SK805443501BR&resposta=xml";"rastro.xml";20;result.txt


Mário

Re: WAPI v1.03 - Funções da API do Windows

MensagemEnviado: 15 Jul 2010 15:52
por rochinha
Amiguinho,

A intenção seria fazer isto mesmo, apesar de não ser novidade para a WAPI pois ela já esta aqui a muito tempo, só não pude acompanhar pois o volume de postagens ficou grande e não tenho tempo o bastante para ler cada uma.

O teste que fiz funcionou legal, mas usei a WAPI em modo linha de comando, não cheguei a integrá-la a compilação nenhuma.

O retorno veio bunitinho no arquivo que especifiquei.

Numa integração com Clipper pegar o retorno dela será de grande valia, pois interativamente e transparentemente poderemos apresentar ao usuário respostas de comandos que por enquanto só podemos fazer nativamente via 32bits e OLE.

Uso a WAPI como motor de impressão, quando o PRINT.EXE falha ou COMMAND.COM falha. Mas agora me veio a idéia de usá-la mais intensamente.

O retorno do rastreamento poderá vir em forma de HTML portanto voce tera de apresentar o conteudo retornado em uma pequena janela IE.

Para tanto voce poderá salvar o arquivo como RASTREIO.HTML e chamá-lo com o código abaixo:
<html>
   <head>
      <title>Correios - Rastreio</title>
      <HTA:APPLICATION ID="oHTA" ICON="http://www.5volution.com/favicon.ico" BORDER="dialog" CAPTION="yes" MAXIMIZEBUTTON="no" MINIMIZEBUTTON="no" NAVIGABLE="no" CONTEXTMENU="no" INNERBORDER="no" SCROLL="no"/>
      <script language="javascript">window.resizeTo(700, 500); window.moveTo((window.screen.availWidth-700)/2, (window.screen.availHeight-500)/2);</script>
   </head>
   <frameset rows="*">
      <frame scrolling="no" src="rastreio.htm">
   </frameset>
</html>


Chamada:
WAPI -URL2FILE:"http://websro.correios.com.br/sro_bin/txect01$.QueryList?P_LINGUA=001&P_TIPO=001&P_COD_UNI=SK805443501BR";"rastreio.htm";20;result.txt

Re: WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 25 Set 2010 15:17
por Maligno
Após a denúncia de bug no sistema de impressão, fiz uma checagem, encontrei os erros e fiz as correções devidas. Testei de várias formas, mas como esse sistema é muito dinâmico, posso ter deixado escapar algum teste. Na eventualidade de aparecer outro bug, agradeço de antemão pela denúncia.

O erro principal dizia respeito à impressão de mais de uma cópia. Eu havia me esquecido de rebobinar o arquivo fonte do relatório, a fim de imprimir novamente. Aliás, corrigi também uma pequena imperfeição na função da biblioteca. Na impressão de páginas pares/ímpares, a lista de páginas, que é dinâmica, era desconsiderada. Exemplo que não funcionava: impressão das páginas pares no intervalo de páginas 45-98. Da forma que estava, imprimia todas as páginas pares. Agora a lista é considerada, em ordem de impressão ascendente ou descendente, com páginas agrupadas (1,2,3,1,2,3) ou não (1,1,2,2,3,3).

Aproveitei a oportunidade para remover a função de embutimento do utilitário WAPI.EXE. Agora ele terá de ser distribuído à parte.

O link para a página do download é: http://pub.buzinello.com/index.php?d=./xbase/clipper/libs/

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 19 Abr 2013 19:41
por marbio
Boa noite galerinha,

Eu nao consigo baixar WAPI o link esta quebrado

onde posso baixar.

Grato

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 19 Abr 2013 20:15
por Maligno
Na mensagem imediatamente anterior à sua, há um link para um diretório onde armazenei diversas bibliotecas. Todos os links da WAPI estão íntegros. Acabei de testar.

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 02 Dez 2013 20:48
por filizola
Hermeto, vc conseguiu enviar sms com a wapi ?

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 04 Jan 2014 07:57
por ANDRIL
filizola escreveu:Hermeto, vc conseguiu enviar sms com a wapi ?

Nome meu caso, meu sistema esta enviando SMS com a Wapi 1.05, qual sua versão e o que ocorre?

Utilizo o serviço da easySMS (www.easysms.net.br) usando o método HTTP e funciona normalmente. Opcionalmente neste site indicado, no link 'integração' tem alguns exemplos que servem para Clipper e xHarbour.

Até+

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 14 Jan 2014 22:39
por Abel
Andrill,

como esta o envio / integracao com a easysms ?

algum problema no envio ?
algum tipo de inatividade ?

quantos sms vc tem utilizado mensalmente por eles ?

faz muito tempo que to pensando em fazer isso, mas nao me decidi.

Abraços,
Abel

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 15 Jan 2014 07:36
por ANDRIL
Olá Abel,

Abel escreveu:como esta o envio / integracao com a easysms ?

Funcionando normalmente. Antes de fazer esta integração, pesquisei muito na NET até encontrar a easysms e em um dia, adaptei 5 sistemas. É muito simples integrar.
Abel escreveu:algum problema no envio ?
algum tipo de inatividade ?

Dentro da normalidade. Como disse, testei vários sites antes de optar por este e todos apresentaram alguns problemas no envio e recebimento das mensagens (nenhum é 100%).

Abel escreveu:faz muito tempo que to pensando em fazer isso, mas nao me decidi.

Não perca tempo, como disse o processo é muito rápido e simples. Meus clientes adoraram a novidade e utilizam para tudo. Vai da sua criatividade em colocar envios de SMS nas suas rotinas. No meu, por exemplo, coloquei a cada venda o cliente recebe o SMS com o numero da venda, valor e um muito obrigado, alem do cliente poder divulgar o site ou telefone da loja.
Agora com SAT minha intenção será enviar a chave do cupom por SMS a cada venda.

É mais um diferencial do seu sistema.

Se tiver dificuldade abra um tópico sobre o assunto que lhe ajudo.

Ate+

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 19 Jan 2014 11:02
por lucimauro
Andril;

E qual pacete voce usa?
Quem paga é voce ou o cliente?

Desde ja obrigado.

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 19 Jan 2014 16:48
por ANDRIL
lucimauro escreveu:E qual pacete voce usa?

Olá lucimauro, eu preferi na época criar as contas de cada cliente e eu gerencio elas. Claro que cobro um valor um pouco a mais pelo pacote (manunteção) dessas contas.

Eles estão criando agora uma conta única (master) onde pode-se criar subcontas. Assim posso comprar créditos e transferir para as subcontas, assim cobrarei dos clientes os créditos, vou criar meus próprios pacotes, o cliente me paga e eu reponho o crédito necessário.

lucimauro escreveu:Quem paga é voce ou o cliente?

Eu cobro do cliente e depois compro o pacote da easysms.

Ate+

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 20 Jan 2014 00:16
por lucimauro
Obrigado por sua atenção.

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 22 Jan 2014 23:57
por Abel
Andrill,

agradeço as explicacoes, valeu !!!

Abraços,
ABEL

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 23 Jan 2014 00:02
por Abel
Andril,

tenho uma duvida, quando o cliente recebe o sms com os dados da venda etc..., aparece um "code" ou um "numero de telefone" no remetente ?

Abraços,
ABEL

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 23 Jan 2014 09:57
por ANDRIL
Abel escreveu:aparece um "code" ou um "numero de telefone" no remetente ?

Abel, aparece um número do sistema de envio da easySMS. Não aparece shotcode nem o número do celular do cliente que usa o SMS.

Nas mensagens que configuro sempre coloco o nome da EMPRESA e se necessário retorno, especifico o número na mensagem para tal.

Exemplo de mensagem:Obrigado por comprar conosco. Pedido efetivado No.xxxxxx Vlr xx.xx. PIZZARIA PIZZABOA tel xxxx-xxxx site www.xxx.com.br

Até preferi que não sai o celular do cliente, até porque, todos que consultei não queriam receber respostas destas mensagens no seu celular e sim no telefone da central de atendimento.

Ate+

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 01 Jan 2015 20:42
por by Ivo
Boa noite
Estou precisando de um procedimento(funcao) para enviar SMS pelo clipper.
Fico no aguardo.
Obrigado.

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 01 Jan 2015 20:52
por Pablo César
by Ivo escreveu:Estou precisando de um procedimento(funcao) para enviar SMS pelo clipper.
Fico no aguardo.
Oi Ivo, seja bem vindo a comunidade !

Mas respondendo a sua petição, existem vários aplicativos de terceiros (executáveis) que possibilitam o envio de emails pelo Clipper. Faça uma busca avançada que você vai encontrar várias. E a propósito, este assunto não tem nada haver com o aplicativo/biblioteca WAPI do Maligno.

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 04 Jan 2015 09:30
por ANDRIL
Pablo César escreveu:que possibilitam o envio de emails pelo Clipper

Caro Pablo, o colega quer enviar SMS e a Wapi tem função para executar chamada HTTP que geralmente é utilizada para integração com sites de envio.

by Ivo escreveu:Estou precisando de um procedimento(funcao) para enviar SMS pelo clipper.

Ivo, a função é fornecida pela própria empresa de integração, veja os exemplos que eles fornecem. Quando integrei com a easySMS, usava clipper puro e obtive os exemplos (já com a função embutida no prg). No seu caso, não sei a empresa com qual quer integrar mais o procedimento é muito simples. Todos meus sistemas hoje enviam SMS, tanto em Clipper, xHarbour e Harbour.

Ate+

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 21 Fev 2015 13:21
por Abel
Andril, vc continua enviando pela easySMS ? tem tido algum problema com os envios ?

Abraços,
ABEL

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 25 Fev 2015 12:56
por Clipper
Prezado Abel

Dê uma olha aí.

http://www.easysms.net.br/integracao.php

Também tem essa outra empresa.

http://www.iagente.com.br/desenvolvedor ... icao-http/
Parece ser bem simples.

Até logo.

Marcelo

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 09 Mar 2015 07:29
por ANDRIL
Desculpe Abel não tinha visto sua mensagem.
Abel escreveu:Andril, vc continua enviando pela easySMS ? tem tido algum problema com os envios ?

Continuo sim, sem problemas. Se optar integrar com a easysms e tiver dificuldades, conte comigo. Segui os exemplos fornecidos no site e foi relativamente fácil.

Ate+

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 19 Jan 2016 12:29
por Clash
Olá a todos.

Estou com problemas na hora de linkeditar com o Blinker 7.0 a Lib WAPI.

Apresenta as seguintes mensagens:

BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'DIRMAKE' : unresolved external
BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'DIRNAME' : unresolved external
BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'RAND' : unresolved external
BLINKER : 1115 : WAPI.LIB(COMPATIB) : 'RANDOM' : unresolved external

BLINKER : 0 Warning error(s), 4 Fatal error(s)

Alguma ajuda, dica de como resolver isso?

Agradeço desde já.

Clash

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 19 Jan 2016 18:53
por Pablo César
Linke com outra biblioteca CT

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 19 Jan 2016 20:09
por Clash
Olá Pablo, qto tempo...!

Não entendi bem, vc diz parar de usar o Blinker? Mas eu perderia outras funcionalidades dela.

Obrigado pela dica.

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 20 Jan 2016 10:25
por Pablo César
Desculpe, eu quis dizer adicionar também a CT

BLinker Fi x Lib WAPI,CT

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 20 Jan 2016 11:27
por Clash
O amigo Pablo, obrigado mesmo! Mais uma vez me auxiliando.

E me desculpe, eu que não interpretei direito o seu texto. Adicionar mais a biblioteca CT.Lib

Grato mesmo.

Abraço.

Clash

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 07 Jul 2018 09:11
por deividdjs
wapi.lib é compativel com xharbour 1.2.1 source ??

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 29 Out 2022 12:48
por Abel
muito bom dia pessoal,

como faço para saber os recursos da wapi e os comandos / sintaxe dos mesmos do WAPI.EXE ?

me parece que é um EXE com muitos recursos mas como saber detalhadamente ?

Obrigado
ABEL

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 31 Out 2022 20:47
por alxsts
Olá!

Qual linguagem você utiliza? Clipper ou [x]Harbour?

Pergunto porque este executável foi criado pelo Maligno nos tempos o Clipper, para suprir funcionalidades não disponíveis naquela linguagem. É um aplicativo 16 bits. Se você utiliza [x]Harbour, não conseguirá utilizar em máquinas 64 bits, a menos que consiga os fontes e os compile com [x]Harbour. Não sei dizer como encontrar uma lista de funções que ele contém. Mas, se você usa [x]Harbour, poderá encontrar a maioria das funcionalidades em bibliotecas contidas na pasta Contrib.

WAPI v1.05 - Funções da API do Windows

MensagemEnviado: 21 Nov 2022 20:33
por Abel
ola,
utilizo harbour, modo console

Obrigado
ABEL