Micheus

Ou melhor: Bem vindos aos novos tempos! Finalmente minhas preces foram atendidas. :D Vida nova ao forum!!! (ou será, vida longa?!)

Lucy, se você não está manipulando o teclado, não consigo pensar e outra possibilide - é algo realmente estranho. Você já experimentou criar um form novo, com novos componentes (nada de copiar/colar), apenas com uns poucos componentes e o tal DBMemo, apenas para verificar se não é algum problema com aquele form em específico (uma tentativa extrema, para um problema um tanto estranho) Desculpe não poder ajudar. Boa sorte.

Daniel Henrique M. Doro, supondo que você use um dataset tipo query para mostrar os dados no seu DBGrid, o que você precisará é exatamente aquele tipo de consulta que lá está.É uma consulta onde os dados são filtrados por data - não importa que seja para uso em um relatório ou em um form - será sempre daquela forma. Eu apenas diria que a linha referente a cláusula GROUP BY não se aplica ao seu caso. Lá no exemplo, os parâmetros são preenchidos com a propriedade Text de TMaskEdit's - praticamente nenhuma diferença para seus os seus TEdit's. Já se você usar um dataset tipo table, então as coisas mudam um pouquinho. Mas, daí, ficaremos no "achismo" porque faltam mais informações. Abraços

josimar3x, fazer engenharia reversa, pode não ser algo lícito - mas, cada um sabe de suas necessidades e riscos. A resposta é não. Você poderá no máximo extrair os .dfm (forms), mas em termos de código, você terá ele em assembler. Procurei um artigo que explicasse bem sobre isso e encontrei uma que me pareceu bom: Verdades e Mentiras Sobre o Descompilador para o Delphi Abraços p.s. Por gentileza, não escreva em caixa ALTA. Se precisar destacar alguma coisa no texto, use negrito, sublinhado ou cores. ;)

Voce pode usar a ideia do colega Progr'amador, neste post.

Guilherme, você pode dar uma olhada nestes posts, podem lhe ajudar: Checar por atualizações? Web Update, Modelo de atualizador pela web!!! Atualizar, Como atualizar.... Abraços

diegolambaum, acho que agora está mais claro e quem sabe o que eu vou citar possa lhe ajudar. Como você deverá regular o andamento do relatório, ou seja, a banda rbDetail poderá ser reimpressa mais vezes e não apenas uma única vez, no caso do quickreport, o mais apropriado é que você use o evento OnNeedData do QuickRep. De modo similar, como a banda qrSubDetail deverá ser manipulada no sentido de não imprimir mais que 10 vezes por página, você deverá usar também o evento OnNeedData dela para fazer este controle. Sabemos que após impressa a banda detail, a banda sub-detail é processada e impressa. A pós cada impressão desta banda, devemos avançar o dataset ligado a ela (AfterPrint). Ao chegar ao 10º registro impresso no sub-detail e houverem mais a serem impressos (não for fim do dataset ligado a esta banda), precisamos avançar de página mas não devemos avançar o dataset principal. Só faremos isto, quando o dataset "ligado" a sub-detail atingir seu fim. Mas só avançar a página não resolve nosso problema porque precisamos que os dados na banda detail sejam reimpressos na nova página. Vamos fazer isto usando de dois artifícios: - a propriedade ForceNewPage (na banda detalhe) resultará em uma detail por página; - marcar MoreData = False no evento OnNeedData da banda sub-detail quando houver mais itens a serem impressos, fará com que a banda detalhe seja impressa, porém não avançaremos o dataset principal (com isso, ela é impressa igualzinho a anterior) Para a implementação: - 01 QRBand do tipo rbDetail, com a propriedade ForceNewPage=True, onde vão os dados da tabela mestre; - 01 QRSubDetail, onde vão os dados da tabela detalhe; - 01 QRBand do tipo rbGroupFooter, que deverá ser definida como a GroupFooter da banda QRSubDetail; - declarar uma variável do tipo Integer na sessão private para controle da qtd de linhas impressas (ex. QtdPrinted); - As propriedades DataSet do QuickRep1 e QRSubDetail1 não deverão ser "setadas" (lembre, estamos usando o evento OnNeedData); - Assumi que o dataset detail está vinculado ao master via propriedade DataSource (Isto é importante. Caso você não use deste modo, avise). A título de exemplificação, vou chamar o dataset master de QryMaster e o detalhe de QryDetail // BeforePrint do QuickRep procedure TForm1.QuickRep1BeforePrint(Sender: TObject; var MoreData: Boolean); begin QryMaster.First; // antes de iniciarmos a impressão, posicionamos o dataset master no início end; // OnNeedData do QuickRep procedure TForm1.QuickRep1NeedData(Sender: TObject; var MoreData: Boolean); begin MoreData := not QryMaster.EOF; // continua enquanto não chegar ao fim do dataset principal end; // AfterPrint da banda rbDetail procedure TForm1.QRBand1AfterPrint(Sender: TQRCustomBand; BandPrinted: Boolean); begin QtdPrinted := 0; // inicializa contador de sub-detalhes impressas, após cada impressão da master end; // AfterPrint da banda sub-detail procedure TForm1.QRSubDetail1AfterPrint(Sender: TQRCustomBand; BandPrinted: Boolean); begin Inc(QtdPrinted); // incrementamos após impresso cada registro de QryDetail QryDetail.Next; // avançamos o dataset da banda sub-detail end; // AfterPrint da banda rbGroupFooter. Ele é gerado após conclusão da impressão de todas // as "linhas" sub-detail. Isso ocorre, quando MoreData = False no OnNeedData da banda SubDetail procedure TForm1.QRBand2AfterPrint(Sender: TQRCustomBand; BandPrinted: Boolean); begin // só vamos avançar o dataset principal, quando realmente não houver mais detalhes a serem // impressos. Caso não avançarmos, a banda detalhe ainda imprimirá os dados em que o dataset // está posicionado, ou seja, serão impressos repetidos if QryDetail.EOF then QryMaster.Next; end; // OnNeedData da banda SubDetail procedure TForm1.QRSubDetail1NeedData(Sender: TObject; var MoreData: Boolean); begin // verificamos se a quantidade de itens impressos chegou a 10 e, caso o dataset QryDetail ainda não tenha // chegado ao seu fim, simulamos a conclusão da impressão da banda sub-detail. Isto resultará no processamento // da banda rbGroupFooter, dando início a nova sequência: detail/sub-detail/groupfooter if (QtdPrinted = 10) and (not QryDetail.EOF) then begin QtdPrinted := 0; MoreData := False; end else // do cotrário, seguimos com o procedimento usual MoreData := not QryDetail.EOF end; Teste e veja o resultado. Abraços p.s. Editei para inclusão do evento BeforePrint do quickrep

amauri, já tentou contactar a WEG? - possivelmente eles poderiam ter algum para lhe indicar. Controladores Programáveis de Pequeno Porte (WEG) Boa sorte.

diegolambaum, ainda não entendi direito a sua intenção, mas vamos ver no que dá para ajudar...Esta parte sobre quando há mais que 10 itens no detalhe, não está muito clara. Voce verificar se haverão mais de 10 itens do detalhe e se houver, não poderá avançar... Mas, imprimirá até os 10 primeiros? Quando chegar ao 10º, fará o que? Estas coisas não ficam claras, quando você diz que "não pode da um next na master". Estes controles, bNext e bPrior, estão sendo manipulados onde e como? Não dá para dizer que a lógica está certa ou errada, sem saber como você manipula eles. Não há sentido em usar o Prior. Voce tem que ajustar sua lógica de modo a apenas avançar, assim, você não incorrerá em erro, pois pode ocorre de você nunca avaliar o EOF. O avanço no dataset, normalmente se dá logo após sua utilização, o que pode ser entendido como sendo no evento AfterPrint da banda detalhe.Dê uma olhada neste post, na parte do OnNeedData e veja se lhe dá uma idéia de como você deve controlar as informações neste evento. e isto será feito neste mesmo relatório? Que parte dele você quer repetir, já que você tem banda detail e sub-detail? É todo o relatório ou apenas a parte que está na sub-detail? Pergunto, porque há dois eventos OnNeedData e gerenciar esta repetição no QuickRep, resulta em repetição de todo o relatório, porém, se for na sub-detail, apenas ela será repetida. Abraços

diegolambaum, acho que no destaque, você quiz se referir a banda SubDetailBand, certo?!este: "e se eu antes de imprimir", pressupõe que você normalmente não estaria fazendo isto. Entretanto, você sempre deverá posicionar o dataset no seu início (via evento BeforePrint) quando você utilizar o evento OnNeedData, porque nestas condições você não liga um dataset à respectiva propriedade do QuickRep ou SubDetail. Há algum problema com seu relatório, sem dúvidas, mas fica difícil avaliar sem saber o que você está fazendo na inicialização deles e nos eventos. Abraços

DiabloX3, se você adicionou os campos (fields) ao seu dataset em design-time, você simplesmente acessa ele e do mesmo modo como você configura, p.e., a propriedade DisplayFormat, você usa a propriedade Alignment para definir o alinhamento a ser usado no desenho do field através do método DefaultDrawDataCell (obsoleto).Caso você não tenha adicionado os campos em design-time, então no código do programa, após aberto o dataset, você acessa o campo através da propriedade Fields do dataset, ou mesmo via FieldByName - que lhe rotornará um TField - e acessa sua propriedade Alignment: qryCliente.Fields[1].Alignment := taLeftJustify; ou qryCliente.FieldByName('DatNascimento').Alignment := taRightJustify; Abraços

esta mensagem parece sugerir que o Edit1.Text possa estar nulo neste momento do teste. Não estaria? Neste esquema que você diz querer fazer, os recados não são filtrados pelo código da pessoa que deve lê-los? Não "captei" por que você usa uma tabela onde estão todos os registros? Em teoria eu pensaria que ao informar o código da pessoa a ler os recados, você usaria uma consulta SQL filtrando apenas os dados dela. Neste ponto você tem a query aberta e usa o botão Prox e Ant para navegar no resultado através dos métodos Next e Prior, respectivamente. A questão de mover os valores das colunas para os TEdits, já que você não está usando TDBEdits (o que facilitaria muito seu trabalho), poderia ser contornada utilizando o evento OnDataChange do DataSource ligado ao Dataset em questão - a query com o resultado obtido. Abraços

Mario Lopes, se você não disse qual é o erro que você está obtendo, ninguém vai poder lhe ajudar. :huh:

Lucy, você esqueceu o CAPSLOCK ligado. Evite postar em caixa alta, além de "agressivo" é proibido pelas regras do forum. ;) Se o que não está ocorrendo o que o colega Recife lhe citou, por acaso você não está tratando a tecla ENTER em algum evento KeyPressed ou similar? Algo que pudesse estar mudando seu comportamento... Abraços

Recife, acho que você se atrapalhou um pouquinho por aqui. :D O post do Zolhos é de 2004 e foi ressucitado pelo colega Mario Lopes que por algum motivo fez um post sem relação com ele. Ainda a resposta ao Zolhos, a observação não é válida porque realmente ele utiliza um StringGrid e não um DBGrid, observe que ele trata o grid deste modo: grdProdIngredientes.cells[0,linhas], e esta propriedade está disponível apenas no StringGrid. ;) Mario Lopes, que tal você postar qual é este "...seguinte erro". Abraços

xtuquim, você está precisando de um guia de referência rápida -> TECH on the Net - Oracle/PLSQL Topics ;) para este caso, você usa a função to_char: SELECT ABA.DATAABASTCARRO DATA, to_char(ABA.HORAITEMABAST, 'HH24:MI') HORA, ... FROM ABA_ITEMABASTCARRO ABA e você pode também usar ele para formatar a data: to_char(ABA.DATAABASTCARRO, 'dd/mm/yyyy'); Abraços

DiabloX3, duas recomendações: 1) passe ao método default os parâmetros que você recebe no cabeçalho do evento/procedure, ou seja, ao invés de: TDbGrid(Sender).DefaultDrawDataCell(Rect, TDbGrid(Sender).columns[datacol].field, State); use deste modo: TDbGrid(Sender).DefaultDrawDataCell(Rect, Column, State); que é como o colega Jhonas lhe sugeriu. Outra coisa a observar é se você definiu este alinhamento na definição da coluna adicionada ao DBGrid ou no field do dataset. De acordo com o help do Delphi 2006, este evento usa a informação do field e não da coluna. ..., DefaultDrawDataCell gets the alignment for the text from the field component rather than the column descriptor, and it never draws a focus rectangle on selected cells. E esta pode ser a causa da perda de alinhamento. 2) também segundo o help, o evento OnDrawDataCell é obsoleto e mantido para compatibilidade. Ele orienta que seja usado o evento OnDrawColumnCell e neste caso o método default a ser chamado será DefaultDrawColumnCell. Do not write an OnDrawDataCell event handler. OnDrawDataCell is obsolete and included for backward compatibility. Instead, write an OnDrawColumnCell event handler. Abraços

biakeffer, olhando a consulta SQL que você usa:MSql :='select * from tbrecados where CODPRAQUEM =' + QuotedStr (edit1.Text); sendo CODPRAQUEM o campo corresponente ao código da pessoa a ser filtrado, supostamente a consulta está correta. Este campo é VARCHAR ou INTEGER? Se for INTEGER, sugiro que retire o QuotedStr, já que basta uma concatenação simples visto que os números não precisam ser tratados com delimitador de texto. (não lembro em que banco de dados, mas tenho a impressão de que este foi um motivo de não obter o resultado esperado) Abraços

vagner isto ocorreu por desatenção nossa. Eu adaptei o exemlo do outro post e acabei não mudando a variável a ser mostrada no ShowMessage - deve ser Soma e não Valor. Como a última linha do StringGrid1 está vazia, a variável Valor contém 0 (zero) ao sair do loop e, conforme nosso if..then, por isto na mensagem ficou com o valor zerado. Abraços

"Menos batista..." :) Pergunte no forum. Não respondo por MP. <_< Abraços

Se foi mesmo, isto vem de encontro ao que postei há 2 anos aqui (neste post) e que foi a solução para outro colega, mas que quando postei em outro forum, fui questionado quanto a real aplicabilidade disto (usar duas transações). Que bom que resolveu. Abraços

FONSENIX, na situação apresentada, pareceu que a procedure estaria tentando alterar (ou acessar) um item que estaria em edição na sua tela, e isto com a opção wait é que poderia estar gerando o deadlock, porque a procedure estaria esperando que o item em edição fosse "liberado" para atualização.E sendo isto, não parece mesmo fazer sentido que você editando uma informação, chame um procedimento para fazer alterações nesta mesma informação simultanemente - neste caso, você faz os processamentos com esta informação no seu código mesmo. Algumas coisas podem ser feitas no momento em que os dados vão para o banco, que é quando você utiliza as triggers. Não sendo o que ocorreu, reveja as suas configurações de transações, porque que se eu entendi direito, o uso do MDODataSet não é o mesmo de um MDOTable. Isso porque os dados são retornados por uma consulta SQL, e as atualizações no banco são feitas através das outras propriedades (InsertSQL, DeleteSQL, UpdateSQL - acho que são esses os nomes da propriedade). Este componente é praticamente uma agregação de dois da paleta IB (IBSQL e IBUpdate). Observe que a alteração de um mesmo registro por duas pessoas é possível, mas o banco vai gerenciar isto conforme definida na transação. Leia aquele artigo que citei e faça uns testes trabalhando com algumas combinações. Trabalhando com DBGrid, visualizando os dados, se você usar Commit na transação que está associada ao componente ligado ao DBGrid, a transação será fechada e você terá sua consulta fechada (se não estou enganado), então, nestes casos use CommiteRetained (teste e confira, se é isto mesmo). Abraços

Parece que você achou a causa do DeadLock. Não use uma SP para fazer isto. Se estes valores calculados devem aparecer na tela neste momento da edição, é melhor que você faça a consulta na tabela produtos neste momento e realize os cáculos. O update na tabela de Produtos para realizar a baixa, você pode fazer através de trigger. Para ler mais sobre transações, dê uma olhada neste post (no final) e acesse o último link para o artigo "Entendendo os tipos e configurações das transações" Dúvidas específicas do MDO você pode tirar no grupo yahoo!: mdo-suport (para participar você tem que se registrar no yahoo!, mas pesquisar no que já há por lá não (e tem bastante coisa). Sobre Firebird (em português), recomendo: FireBase Abraços

xtuquim, você não citou qual o banco está usando. Há um tempo se você falasse em PL/SQL me viria na cabeça o Oracle, mas em tempos de Firebird 2.5, também tenho visto este termo. Mas, dando uma pesquisada sobre Oracle (se for o caso), para esta sua situação você poderia fazer uso da função COALESCE - ela faz uma espécie de case de modo bem simples. Se o primeiro parâmetro não é nulo, ele é usado. Se for nulo, avalia o próximo, e assim vai). Voce poderia testar assim, então: Abraços

Vamos ver se achamos você. :D O relevante com relação a soma das linhas de uma coluna, acretido que você tenha entendido lá do post citado. Vou então, reescrever o exemplo, usando o que citei no post anterior: var IdxRow :Integer; Valor, Soma :Double; begin Valor := 0; // o 1º elemento da linha é o header, então começamos de 1 (não de zero) // da mesma forma, a 4ª coluna corresponde ao item 3, já que a lista começa em 0 for IdxRow := 1 to StringGrid1.Cols[3].Count -1 do begin if Trim(StringGrid1.Cols[3].Strings[IdxRow]) = '' then // se string nulo Valor := 0.0 else Valor := StrToFloat(Trim(StringGrid1.Cols[3].Strings[IdxRow])); Soma := Soma + Valor; end; ShowMessage('Valor total da 4ªcoluna: ' +FloatToStr(Valor)); end;como você vê, usamos uma variável a mais para primeiramente obter o valor da string convetida em número. Neste exemplo, como citei anteriormente, parti do princípio de que uma string nula é assumida como um valor 0 (zero). Mas, não estamos testando se o texto digitado na célula é mesmo numérico (poderia ser digitado algo com caraceteres não numérico). Não sei se você já está trantando isto em algum outro momento. Será que agora ficou mais claro? Abraços