Thales Pontes Martins

ah, então é só colocar if (msg = WM_TIMER) then............... Mas mesmo assim, como é o Windows que vai chamar o procedimento, é melhor colocar stdcall só pra prevenir. Estranho né? Mas então o seu problema foi completamente resolvido? Funcionou?

É, o negócio é complexo mesmo. Pelo que eu entendí você quis dizer que o owner libera a memória alocada pelo gerenciador de memória da Borland para conter os campos das classes, e o Parent trata de liberar Handles e outros recursos requisitados ao Windows, né? Mas afinal de contas, é ou não preciso usar ListBox.Free;? Ou só é preciso se não for passado o Owner como parametro no Create?

você está querendo dizer que não quer criar uma janela para isso? Porque a função AllocateHWnd cria uma janela não visual para receber as mensagems de Timer e recebe como parametro a procedure que Lida com as mensagems recebidas. Agora, sem criar as janelas eu não sei se é possivel. Quando eu quero fazer um Timer com um form eu faço assim-> type TForm1 = class(TForm) procedure FormDestroy(Sender: TObject); procedure FormCreate(Sender: TObject); private { Private declarations } public { Public declarations } count : cardinal; end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.FormDestroy(Sender: TObject); begin KillTimer(Handle,1); //KillTimer(Handle da Janela, Identificador do Timer); end; //Aqui é o procedimento do Timer, coloque o que quiser nele procedure Timer(Hwnd, msg, id, tick : integer); stdcall; begin inc(form1.count); form1.caption:=inttostr(form1.count); end; procedure TForm1.FormCreate(Sender: TObject); begin SetTimer(handle,1,1000,@Timer); //SetTimer(Handle da janela, Identificador do timer, Intervalo, Procedimento); end; Funciona legal, mas se não passar nenhum handle pra SetTimer eu não sei se dá certo, teria que criar a janela não visual lá com AllocateHWnd. Interessante é que se eu não colocar stdcall ele chama 2 vezes o procedimento a cada TimeOut. Não sei porque.

Deixa eu ver se entendí, se o cara não sair pro intervalo ele deixará de passar o cartão 2 vezes né? Mas essa hora que ele passar a mais deverá ser paga ou desprezada? E no caso do adicional noturno, deverá ser descontado as horas a menos, mas as horas a mais que o cara passar na empresa deverão ser desprezadas? Nesse caso, quando você for fazer os descontos você tem que verificar se o cara passou o tempo nominal na empresa. Se ele estava quando começou o turno e ficou até terminar, então pague a ele o valor normal, sem contar o tempo que ele ficou a mais. Então se o turno é de 9 horas e ele ficou 12 mas preenchendo o turno todo então pague as 9 horas pra ele. Agora se ele ficou 9 horas mas entrou 1 hora mais cedo e saiu 1 hora mais cedo, então pague a ele somente 8 horas porque não foram preenchidas as 9 horas do turno. Então se o turno começa as 22:00 e termina 07:00, você tem que ver quanto tempo nesse intervalo apenas o funcionário esteve presente.

Opa, então eu devo ter interpretado errado essa parte da documentação do Delphi->

O componente Timer faz desse jeito, adaptado para o seu objeto-> SeuObjeto = Class(TObject) private FWHandle : HWND; Procedure WndProc(var msg : TMessage); . . Procedure SeuObjeto.CreateTimer; begin FWHandle := Classes.AllocateHWnd(WndProc); SetTimer(FWHandle, 1, Interval, nil); end; procedure SeuObjeto.WndProc(var Msg: TMessage); begin with Msg do if Msg = WM_TIMER then (Faça Alguma Coisa) end; Procedure SeuObjeto.DestroyTimer; begin KillTimer(FWHandle, 1); FWHandle := Classes.DeallocateHWnd(FWHandle); end;

É o seguinte, somente derivados de TWinControl, como Forms, Panels e GroupBoxes podem ser parent de outros controles. Um controle precisa de um parent para aparecer. Assim que é atribuido um parent a um controle ele pega o Device Context do parent para se desenhar na superfície dele. Device Context é um Handle que pode ser colocado num canvas para que se possa desenhar em uma janela ( Canvas.Handle:=GetDc(Form1.handle); ). Para isso os derivados de TWinControl tem uma propriedades Controls, que é um array de Handles dos seus filhos, e uma propriedade ControlCount que é um inteiro que informa quantos filhos o controle tem. É assim que o RadioButton desliga seus irmãos quando é clicado-> for i:=0 to parent.ControlCount-1 do if (parent.Controls[i] is TRadioButton) and (parent.Controls[i] <> self) then parent.Controls[i].checked:=false; E é por isso que os que estão dentro de um GroupBox são isolados do demais, porque o parent deles é o GroupBox e não o form. Sim, o parent é responsável por destruir todos os controles em sua lista Controls. No seu caso a propriedade name não faz diferença já que você vai fazer referencia apenas pelo identificador. Se o ListBox é invisível porque usar ele então? Não é melhor usar um TStrings?

Para criar qualquer componente em tempo de execução-> procedure TForm1.Image1Click(Sender : TObject); var LB : TListBox; begin LB:=TListBox.Create(Self); LB.Name:='ListBox1'; LB.Parent:=Self; . . . end;

Opa, de java eu não entendo nada, mas estou implementando um em Delphi, já fiz a interface gráfica toda, mas quanto ao mecanismo(Engine), apenas comecei a estruturar os dados. Este é o segundo que estou fazendo, porque o primeiro eu comecei a fazer pensando que era fácil, sem estudar nada antes. Por esse motivo ele ficou muito ruim. Portanto tive que dar uma estudada e começar tudo denovo do zero. A interface gráfica é fácil. Só é trabalhoso quanto mais recursos você quer colocar nela. Cheguei num estado que me satisfez. Agora, quanto ao algoritmo que calcula qual a melhor jogada, é muito difícil e requer muito estudo para implementar. As pessoas podem e passam vários anos refinando seus algoritmos para obter um resultado satisfatório, um algoritmo que jogue um xadrez razoável. Para isso é preciso estudar várias técnicas inventadas pelos pesquisadores ao longo da história dos computadores, como -> * Busca AlphaBeta (AlphaBeta Search / Cuttoff's) * Variação Principal (Principal Variation, PV) * Aprofundamento Iterativo (Iterative Deepening) * Tabela de Transposição (Transposition Table, Hash Table) * Jogadas de Corte (Killer Moves) * Tabela de História (History Table) * Busca Quieta (Quiescence Search) * Busca MTD(f) (MTD(f) Search) * Extensões singulares (Singular Extensions) * Jogadas Nulas (Null Moves) * Repertório de Abertura (Openning Book) * Tabuleiro de Bits (BitBoards) * Avaliações Estáticas (Static Evaluations) #Dentro de Avaliações estáticas existem mais umas 30 técnicas que devem ser consideradas Repito que é muito difícil implementar um algorítmo desses. Mas se você realmente quiser procure dar uma estudada boa nessas técnicas e quem sabe você mesmo pode inventar suas próprias técnicas e heuristicas de avaliação. Eu postei essa menssagem porque no que diz respeito ao mecanismo de busca não faz diferença se o código for em java ou Delphi que vão ser a mesma coisa. E ainda você deve lembrar que Java é uma linguagem mais lenta doque as outras e portanto um jogo feito em Java não poderá jogar um grande xadrez. Ainda mais se for pra celulares ou equipamentos parecidos aonde 90% dos recursos são consumidos pelo sistema operacional.

Ok Paulo, com certeza esse access violation deve-se a grande confusão de forms, objetos e recursos utilizados pelo seu programa. É preciso dar uma conferida geral e começar a organizar o programa seguindo a lógica convencionada. Paulo Nobre, 29 de agosto de 2006, 10:07 PM quando você disse Se destruir é colocar no evento OnDestroy....frmLembrete.Free, estou sim. não sei se entendí da maneira correta, mas eu entendí que você estava colocando frmLembrete.Free no OnDestroy do próprio form que se está destruindo, isso é errado. No seu caso, colocar frmLembrete.Free no OnDestroy do form principal também não é o certo. Seria o certo se ele estivesse na lista de forms auto criáveis, aí ele seria criado na abertura da aplicação e destruído no fechamento da aplicação(OnDestroy do form principal). Se você criá-lo no OnClick de um botão, terá que destruí-lo quando for fechado, para que quando for aberto novamente, tenha-se que criá-lo denovo. Ou criá-lo no OnClick de um botão e não adicionar Action:=cafree; no OnClose, aí quando ele for fechado, não é liberado da memória, e quando você clicar naquele botão denovo, não poderá criá-lo novamente, somente mostrá-lo com ShowModal. Porque se voce criar outro sem liberar o anterior da memória o mesmo perderá a referencia e ficará ocupando memória atoa. Nesse caso seria melhor criá-lo no início da aplicação e usar ShowModal; e Close; para abrí-lo e fechá-lo. Lembrando que usar o método Hide num form Modal não permite que a aplicação continue, tem que ser Close. No exemplo que sugerí, o form teria que ser criado apenas quando fosse necessário na aplicação(Ex: evento OnClick de um botão), e destruído assim que não fosse mais necessário(Aplicação continuaria rodando). Para isso o correto é colocar no evento OnClose do próprio form Action:=caFree;, e sempre usar Close; para fechá-lo. Isso garantiría que o form fosse liberado da memória. Agora, se você colocar frmLembrete.Free no OnDestroy do próprio form, se foi isso que você quis dizer, estaria errado porque o evento OnDestroy ocorre quando é chamado o método Destroy ou Free do form, que são os métodos que liberam o form da memória. Na verdade o método Free chama o método Destroy. Portanto se for colocado frmLembrete.Free no OnDestroy do próprio form ocorrerá uma recursividade infinita podendo ocorrer um Stack Overflow ou a'te um access violation. Não há nada de errado em colocar Reg.Free no OnDestroy de um form.

opa, destruir não é isso que você falou não, nunca se deve colocar free no OnDestroy. Destruir é colocar Action:=caFree; no evento OnClose e nunca fechar o form com hide, sempre usar close.

que isso mano? tem alguma coisa errada aí. você lembrou de tirar o form da lista de forms auto-criáveis?(project->View Source) você lembrou de destruir o form quando é fechado? Dá uma conferida geral aí, isso não pode acontecer. Tente então colocar um owner para o form-> FrmLembrete:=TFrmLembrete.create(Application); Desiste não.

dê uma olhada no tópico Form Sempre Visível, lá tem exemplos do comando SetWindowPos que pode ser útil. e lembrando que para um form poder ficar em cima de um form fsStayOnTop, ele também precisa estar fsStayOnTop.

Daquela maneira ele já está ficando em cima de todas as janelas. Nesse caso o SWP_NOACTIVATE não influeciou em nada. Em ambos os casos tem que usar ShowModal senão não funciona. Respondendo a pergunta do Paulo, é possível colocar um menu para controlar se o form fica em cima ou não, deve-se deixar a propriedade FormStyle sempre fsStayOnTop e usar os 2 comando citados pelo sc3. só que esse menu deverá estar no mesmo form já que tem que se usar ShowModal. Talvez um PopUpMenu.

Paulo acho que achei a solução para o seu problema no site Experts. você coloca o FormStyle do form desejado para fsStayOnTop. Tire esse form da lista de forms auto criáveis do projeto. Vamos cria-lo na mão. no evento OnShow do form desejado coloque-> procedure TForm4.FormShow(Sender: TObject); begin SetWindowPos(self.Handle, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOACTIVATE+SWP_NOMOVE+SWP_NOSIZE); end; E no OnClose -> procedure TForm4.FormClose(Sender : TObject; var Action : TCloseAction); begin Action:=caFree; end; e para chamar o form tem que se usar ShowModal -> procedure TForm3.Button1Click(Sender: TObject); begin form4:=TForm4.create(nil); // o form não pode ter pai, então o parametro tem que ser nil form4.showmodal; end; isso faz com que o form principal se comporte normalmente mas o form desejado fique em cima de qualquer janela de qualquer aplicação.

Grande Micheus, Gênio. Se eu conhecesse a mensagem direito não precisaria de fazer aquela gambiarra toda...

Com certeza. Eu estava achando que ele não estava ficando em cima de um form do mesmo programa, aí seria errado. Mas você ainda pode fazer uma gambiarra: Coloque um timer com intervalo 10 no form -> procedure Form1.Timer1Timer(sender : TObject); begin if (getforegroundwindow <> Form1.handle) then setforegroundwindow(form1.handle); end; -- O que eu observei aqui é que quando é o form principal da aplicação e está fsStayOnTop ele fica em cima de qualquer janela de qualquer aplicação, mas quando não é o form principal ele só fica em cima das janelas da mesma aplicação. Bom, eu não sei se funcionaria mas tente transformar esse form no principal -> Application.mainform:=Form2; Desculpe é ReadOnly property, esqueça. :D Então você deve tentar colocar a criação desse form primeiro doque os outros no Project->View Source, oque o tornará o form principal, então você vai ter que controlar a abertura do form que deveria ser principal e ocultar o primeiro.

Então é esse form sem caption que não quer ficar em cima? Nesse caso eu não sei oque pode estar acontecendo. Eu teria que ver o projeto para pesquisar. Talvez algum outro colega possa ajudar.

Então você tem que ver se o form que está na frente deste também não está FsStayOnTop. Aqui funcionou sem precisar do SetForegroundWindow.

Tente acrescentar-> Form1.FormStyle:=FsStayOnTop; SetForegroundWindow(Form1.handle);

e lembrando que se você quiser sumir com o bevel você pode colocar lá no form create rx.shape:=bsBottonLine; e ry.shape:=BsRightLine. e lembrando que é possível adaptar outro componente ou o código dos já existentes para fazer o redimensionamento na diagonal. e lembrando que é possível deixar o form tranparente com as propriedades TransparentColor e TransparentColorValue para que apareça só o memo, sem a borda. e lembrando que é possivel derivar um componente do memo e escrever o código que faça isso sem nessecidade do bevel. e lembrando, não, agora eu vou parar de encher o saco.

Para deixar com aspecto melhor pode-se aumentar em 1 ou 2 pixels a largura e altura do memo, assim esconde mais o bevel. ;)

É o seguinte Paulo, fiz aqui oque você desejava, vou postar a unit inteira, e se quiser me passar seu email posso mandoar o projeto inteiro. É so você colocar um form BsNone, coloca um memo e deixa alNone mas com todas as Anchors ligadas. A posição do memo deverá ser colada a esquerda e em cima do form, porem deixando 5 pixels de distância em baixo e a direita, para dar espaço ao bevel de redimensionamento. Com todas as ancoras ligadas o memo se redimensiona sozinho. Aí a unit que deverá ser escrita é essa ( Lembre-se de mudar o nome das variáveis, no meu caso é Form3. E lembre-se que depois de colar a unit você deverá ir até o abject inspector e atribuir aos eventos as devidas procedures[ FormCreate, FormClose, Memo1MouseDown, Memo1MouseUp...... ] ) -> unit Unit3; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ExtCtrls; type TResizex = class(TBevel) private drag : boolean; protected procedure MouseDown(Button:TMouseButton; Shift:TShiftState;X,Y: Integer); override; procedure MouseUp(Button:TMouseButton; Shift:TShiftState;X,Y: Integer); override; end; TResizey = class(TBevel) private drag : boolean; protected procedure MouseDown(Button:TMouseButton; Shift:TShiftState;X,Y: Integer); override; procedure MouseUp(Button:TMouseButton; Shift:TShiftState;X,Y: Integer); override; end; TForm3 = class(TForm) Memo1: TMemo; Bevel1: TBevel; procedure FormClose(Sender: TObject; var Action: TCloseAction); procedure FormCreate(Sender: TObject); procedure Memo1MouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); procedure Memo1MouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); private { Private declarations } rx : TResizex; ry : TResizey; drag : boolean; protected public { Public declarations } end; var Form3: TForm3; implementation {$R *.dfm} procedure TResizex.MouseDown(Button:TMouseButton; Shift:TShiftState;X,Y: Integer); var act : TPoint; begin //GetCursorPos(off); //dec(off.X,left); dec(off.Y,top); drag:=true; repeat GetCursorPos(act); form3.width:=act.x-form3.left; Application.ProcessMessages; until not(drag); end; procedure TResizex.MouseUp(Button: TMouseButton; Shift: TShiftState; X: Integer; Y: Integer); begin drag:=false; end; procedure TResizey.MouseDown(Button:TMouseButton; Shift:TShiftState;X,Y: Integer); var act : TPoint; begin //GetCursorPos(off); //dec(off.X,left); dec(off.Y,top); drag:=true; repeat GetCursorPos(act); form3.height:=act.y-form3.top; Application.ProcessMessages; until not(drag); end; procedure TResizey.MouseUp(Button: TMouseButton; Shift: TShiftState; X: Integer; Y: Integer); begin drag:=false; end; procedure TForm3.FormClose(Sender: TObject; var Action: TCloseAction); begin rx.Free; ry.Free; end; procedure TForm3.FormCreate(Sender: TObject); begin rx:=TResizex.Create(Form3); rx.Parent:=form3; rx.Align:=alright; rx.width:=5; rx.Cursor:=crsizewe; ry:=TResizey.Create(Form3); ry.Parent:=form3; ry.Align:=albottom; ry.height:=5; ry.Cursor:=crsizens; end; procedure TForm3.Memo1MouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); var off, act : TPoint; begin GetCursorPos(off); dec(off.X,left); dec(off.Y,top); drag:=true; repeat GetCursorPos(act); left:=act.X-off.X; top:=act.Y-off.Y; Application.ProcessMessages; until not(drag); end; procedure TForm3.Memo1MouseUp(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Integer); begin drag:=false; end; end.

É Paulo, suponho que você tenha declarado essa procedure dessa maneira-> type TForm1 = class(TForm) . . Protected procedure WMNCHitTest(var Msg: TWMNCHitTest); message WM_NCHitTest; . . se é isso, você tem que lembrar que a mensagem está sendo enviada somente para o controle do form, e o memo é um outro controle. Para ser enviada para o memo esta procedure tem que estar declarada no memo, para isso é preciso derivar um novo componente da classe TMemo -> THMemo = class(tmemo) protected procedure WMNCHitTest(var Msg: TWMNCHitTest); message WM_NCHitTest; end; só que nesse caso ocorrerá um novo problema: Ao se arrastar clicando no memo, somente o memo se move dentro do form, o form mesmo continua parado. Nesse caso acho melhor você fazer a movimentação do form combinando o evento OnMouseDown do memo com a alteração das propriedades Top e Left do form. O caso do redimensionamento também pode ser resolvido da mesma forma, combinando-se os eventos OnMouseDown de algum componente colocado na borda do form com a alteração das propriedades Width e Height do form. Se tiver alguma dificuldade avisa aí que mandarei alguns códigos de exemplo.

As variáveis AllocMemCount e AllocMemSize no Delphi 2006 sempre contém 0. Estão unsuported. Mas então é errado escrever alguma coisa depois de free ou até mesmo chamar free dentro do código do próprio objeto que se destrói? Porque se for um método dinamico quer dizer que o endereço do próprio código que está em execução já foi desalocado?! O mais correto então seria colocar Action:=caFree; no evento OnClose do form?