PC Toledo

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:

https://pctoledo.org/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.

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.

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

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.

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:
https://pctoledo.org/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

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.

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?

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

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.

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.

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.

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.

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 ?

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.

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.