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

[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, -:]

[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

[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

[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

[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

[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

[Stanis Luksys]

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!

[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

[Maligno]

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

[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

[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

[Pablo César]

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).

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).

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.

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.

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:

Código: Selecionar todos

 * 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();
}

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.

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 !

[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

[Stanis Luksys]

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!

[Maligno]

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