PC Toledo

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

Enviado: **02 Mar 2007 20:10**

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

Enviado: **02 Mar 2007 22:17**

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

Enviado: **07 Mar 2007 10:56**

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

Enviado: **07 Mar 2007 11:45**

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

Enviado: **09 Mar 2007 22:26**

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:

Código: Selecionar todos

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:

Código: Selecionar todos

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

Enviado: **10 Mar 2007 11:18**

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

Enviado: **10 Mar 2007 12:08**

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

Enviado: **10 Mar 2007 12:21**

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

Enviado: **10 Mar 2007 14:33**

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

Enviado: **10 Mar 2007 17:44**

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

Enviado: **10 Mar 2007 19:16**

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

Enviado: **10 Mar 2007 19:31**

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

Enviado: **10 Mar 2007 22:32**

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

Enviado: **11 Mar 2007 16:37**

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

PC Toledo

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

Mais implementações p/WAPI

Re: Mais implementações p/WAPI

Implementações p/Wapi

Re: Implementações p/Wapi

WAPI

Re: WAPI

WAPI