nao da pra voce colocar um timer e fazer o usuario esperar um pouco para passar os produtos?
2008/10/30 sergio cavalcante <[EMAIL PROTECTED]> > Pessoal, > Desculpe o texto grande, mas é pra que tudo seja explicado de forma muito > sucinta de modo que possamos chegar à resolução rapidamente. O texto, > dependendo da perspectiva pode ser off-topic ou não, mas acho que interessa > até certo grau às 3 listas que estou enviando, delphi-br, NDDV e Automação > Total. Perdoem-me se estiver equivocado. > > Estou com um probleminha aqui que tá me deixando maluco. Instalei um > componente de comunicação com impressoras fiscais chamado ACBr. Muito bom, > oferece opções para muitas marcas de impressoras, o que é importante pra > quem é do ramo de Automação Comercial, como eu. > > Utilizo Delphi 6 no Windows XP e SGBD Firebird 2.0. > > Com esse componente, posso mandar os comandos mais comuns utilzados por uma > aplicação frente de loja, como Abrir Cupom, VenderItem, etc. Instalei, > configurei, testei e funciona mesmo, com diversas marcas, como prometido. > > Tudo ia bem até que começaram os problemas quando, por exemplo, o caixa > passa os itens muito rápido. Quando o caixa passa o primeiro item, o Cupom > Fiscal ainda não está aberto. Então o que a aplicação te que fazer é, ao > verificar isso, primeiro ela abre o cupom, e depois começa a mandar os > comandos para vender os itens. > > Mas às vezes, a velocidade que o caixa passa os itens é tão grande, que, > enquanto a impressora está abrindo o cupom, ao término do processo de > abertura do cupom pela impressora, já foram passados 8 a 9 itens! E o que > acontece? enquanto a impressora está processando, se você mandar o comando > de venda, o componente afirma que a impressora está ocupada, e fica > mandando > caixinhas afirmando isso pro caixa. Bom, o caixa não tem nada a ver com > isso, ele quer somente passar os itens e pronto, a aplicação que se vire. > > Então, pra resolver essa questão, implementei duas threads na minha > aplicação, utilizando jvThread, da JEDI vcl. Uma que abre o cupom, e outra > que faz loop pra vender os itens. tbm implementei uma lista que vai > acumulando os itens do cupom, à medida que são passados pelo caixa, e a > thread de venda vai consumindo esses itens e deletando à medida que eles > são > vendidos. > > Em suma é assim: > > 1 - A Aplicação tem um forma chamado frmCupom, que tem um edit que é > preenchido pelo leitor de código de barras(LCB), ligado no teclado. > 2 - A Aplicação encontra-se no estado inicial, Cupom ainda não aberto. > 3 - O Caixa passa o produto. O Edit é preenchido pelo LCB que no final > simula um Enter. > 4 - O Edit enfileira o item na lista de itens. Já que o cupom não está > aberto, antes de enfileirar o item, ele ativa a thread que abre o cupom. > Quando essa Thread morre, ela inicia a Thread de venda. > 5 - A Thread de venda fica fazendo loop, verificando o Count da Lista de > Itens(que é um TObjectList). Se o count for maior que um, ele vai vendendo > toda vez que a lista é preenchida e deletando o Item depois que vende. > 6 - Existem flags dizendo que a impressora está trabalhando, se o cupom > está > aberto ou se está abrindo o cupom. > > Com isso resolveu perfeitamente os problemas de "Impressora não está > respondendo". Aí encontrei outro. > > Ainda nesse form, o que acontece é o seguinte. Quando o caixa entra naquela > velocidade "frenética", ela começa a passar os produtos no LCB. digamos o > produto com o código de barras 123000000033. Como já afirmei, quando a > caixa > passa um produto no Leitor, o Edit começa ser preenchido, da esquerda pra > direita, e no final, o Leitor simula um "enter". o que muitas vezes > acontece > é o seguinte, após 5 passadas: > > 1 - primeiro produto é passado. Enfileira e começa a abrir o cupom. > 12300000003 > 2 - ele é passado mais vezes > 12300000003 > 12300000003 > 3 - no exato momento que o cupom de abertura começa a ser impresso, de > alguma forma o enter do leitor é chamado no meio do preenchimento do edit, > e > o que é lido é o seguinte > 123000 > 4 - repare que o CodBarra do produto foi cortado. como esse produto não > existe, o sistema dá um erro de produto não encontrado. Mas como os > codbarras são enfileirados, quando dá esse erro, o caixa já está no sexto, > sétimo produto. Essa parada faz com que o mesmo tenha que ver onde parou, o > que ele já passou, e o que tem que passar de novo, o que é uma coisa > realmente chata pro cliente. > > Imaginei que isso estivesse acontecendo pelo processamento simultâneo entre > o aplicativo Delphi - Tela de Cupom e a Impressora, dividindo > processamento. > Então resolvi criar uma DLL que encapsulasse o ACBr(já até disponibilizei > pro Daniel). Fiz isso, coloquei as threads de venda e abertura de cupom com > prioridade Lowest, justamente pra desafogar ao máximo o processamento da > tela de cupom e não ocorresse esse "freeze" momentâneo. Melhorou, mas não > resolveu ainda assim. > > E o problema realmente é o procedimento de preenchimento do edit mesmo, pq > quando eu não dou um clear no edit, e dou vários enters sem repreenchê-lo, > funciona normalmente. E a impressora tem sua parcela de culpa tbm, pq > quando > uso o aplicativo em versão demo, sem impressora e com o leitor, funciona > normalmente tbm. E quando utilizo a Dll da Bematech ou Sweda, tbm funciona. > > Então, companheiros de lista, preciso de uma luz, pra resolver esse > problema. Muita luz mesmo ehhehe. Obrigado desde já a quem ajudar. > > Atenciosamente, > ------------------------------ > Sérgio Cavalcante > > [As partes desta mensagem que não continham texto foram removidas] > > > -- Felipe Govoni --------------------- Programador Fone 8472-8718 [As partes desta mensagem que não continham texto foram removidas]
