s3c

Se for em relação ao(s) arquivo(s) temporário(s) que o QuickRep cria, já tive esse problema. Já faz algum tempo e não me lembro, mas me parece que é a extensão .qrp O que fiz: deletei todos os arquivos existentes em GetTempPath no onCreate e o problema sumiu. Aproveitando a citação de D3/D7, para quem não souber, já estão liberados os novos Turbos(free): Turbo Delphi e Turbo Delphi for .NET em http://www.borland.com/downloads/download_turbo.html

É uma idéia, tente fazer e poste o resultado. Já mexí em units do Delphi e funcionou. Delete o .dcu, coloque o .pas no path do projeto que será recriado um novo .dcu

Sim, ele faz uma cópia e aloca recursos de GDI; por isso é sempre bom liberá-los pelo DeleteObject. Acho que no Bitmap original, só se tem acesso pelas funções do ImageList ou por APIs.

Pelo que pesquisei, parece que o ImageList mantém o Bitmap num DC próprio e como um Bitmap não pode estar em 2 DCs ao mesmo tempo (essa eu não sabia), você não consegue fazer nada em termos de desenho com o Handle retornado. Uma solução seria criar um novo HBitmap para o seu DC: Image1.Picture.Bitmap.Handle := CopyImage(ImageList1.GetImageBitmap, Image_Bitmap, 0, 0, LR_CopyReturnOrg);

Não mexo muito com desenho de imagens, mas ao que parece o Canvas desse Bitmap fica lockado para leitura e escrita, é como se fosse uma proteção.

Bom, nunca cheguei a verificar leaks de memória tão detalhadamente como o Thales que se encasqueta com leaks de KBs. Verifico a grosso modo pelo task manager do Windows e em leaks acima de 2MB, aí sim vou dar uma escovada de bits para ver o que está ocorrendo. Como boa prática de programação, todo objeto criado em run-time deve se ter a preocupação de liberá-lo; mas por outro lado, teoricamente você pode criar o que quiser sem liberar nada e quando você fechar sua aplicação o Windows se encarrega de liberar toda a memória utilizada. No meu caso só tenho 2 .exe; um programa servidor de Banco de Dados ± 20MB e o outro é a aplicação cliente gerenciadora de menus ± 10MB; todo o resto do sistema é baseado em dlls; ou seja; quando o usuário chamar uma opção de menú, a aplicação cliente carrega a dll responsável por aquilo, executa e quando terminar a dll é descarregada da memória. Com esta prática vim obtendo excelentes resultados de otimização de memória.

Pessoal, vim acompanhando este tópico e queria postar minha opinião: Vou me referir a Objetos para uma abrangência geral. 1-Objetos criados com Owner --> nunca executo Free 2-Objetos criados sem Owner --> sempre executo Free com uma ressalva (se possuir Parent, executo Objeto.Parent := nil; antes do Free). Posso estar errado, mas comigo nunca me deu erro e nunca percebí memory-leaks.

Debugue o programa. Clique F9, no ShowModal clique F7, depois vá clicando F8 e veja em qual linha ocorre o erro.

Quando ocorre o erro ? No .Create ou no Showmodal ?

Order By Cpo1, Cpo2, Cpo3

Coloque & antes da letra.

Não vejo problemas em criar o Form com Owner sendo que o pai não é o Owner e sim o Parent. Provavelmente ele não fica na frente de todos os Forms por causa do SWP_NOACTIVATE. Tente fazer: SetWindowPos(Form1.Handle, Hwnd_TopMost, 0, 0, 0, 0, Swp_NoSize + Swp_NoMove); E para deixá-lo normal:SetWindowPos(Form1.Handle, Hwnd_NoTopMost, 0, 0, 0, 0, Swp_NoSize + Swp_NoMove);

O Delphi 2006 não conheço, mas pelo que ví elas retornam 0 mesmo. Utilize as funções da FastMM.pas, ela é free, dê uma pesquisada pelo Google. Não acho boa prática de programação você liberar um objeto em seu próprio código. Normalmente se libera um objeto a partir de outro; se for um componente e possuir um Owner, então seu Owner se encarregará disso.O Action := caFree; é o meio mais comum de se liberar um Form da memória; pois após ele terminar toda a execução do evento onClose, será executado Form.Free e se tiver código escrito no evento onDestroy, ele será executado para depois então o Form ser definitavemente liberado.

Normalmente deprecated significa que a função foi substituída por outra melhor ou mais completa, mas não significa que você não possa utilizá-la, simplesmente ela é mantida para efeito de compatibilidade. Quanto à variável _TForm, pela sua declaração ela é simplesmente um ponteiro(4bytes) dentro de Form2 que aponta para um objeto. Se _TForm foi criado com Owner de Form2, então quando você der Form2.Free, _TForm é destruído também. Se o Owner de _TForm for outro (TApplication) por exemplo, então ele será destruído quando seu Owner for destruído. Agora se você tem acesso à _TForm após você dar Form2.Free, é simplesmente sorte da memória ainda estar com aquela informação, porque ela está assinalada como liberada e a qualquer momento poderá ocorrer um access violation.

Acho que esse link pode ser útil.

É uma única query. Coloque todos os campos que você quer que saia no relatório; tanto da tabela de compras, quanto da tabela de empresas.

Se você tiver o código da empresa na tabela de compras, você pode fazer: Select C.cpo1, C.cpo2,...,E.cpo1,E.cpo2... From Compras C Left Join Empresas E on (E.Cod = C.Cod_Empresa)

Acho que fazendo Pointer(String) não deverá funcionar porque o parâmetro requer um PWideChar(2 bytes p/ cada caracter) e não um PChar. Acho melhor converter: var p:PWideChar; p := AllocMem(Length(OpenPictureDialog1.filename) * 2 + 2); OleLoadPicturePath(StringToWideChar(OpenPictureDialog1.filename, p, Length(OpenPictureDialog1.filename) + 1), nil, 0, 0, IID_IPicture, @Pic); . . . FreeMem(p);

Por exemplo, numa imagem 800x600, PixelsX retorna 800 e PixelsY retorna 600.

Existem também uma função na Api Oleaut32: uses Activex; function OleLoadPicturePath(szURLorPath: POleStr; unkCaller: IUnknown; dwReserved: Longint; clrReserved: TOleColor; const iid: TIID; ppvRet: Pointer): HResult; stdcall; external 'oleaut32.dll'; var Pic:IPicture; Pix,PiY,PixelsX,PixelsY:Integer; H:HDC; const IID_IPicture: TGUID = (D1:$7BF80980;D2:$BF32;D3:$101A;D4:($8B,$BB,$00,$AA,$00,$30,$0C,$AB)); begin H := CreateCompatibleDC(0); PiX := GetDeviceCaps(H, LOGPIXELSX); PiY := GetDeviceCaps(H, LOGPIXELSY); ReleaseDC(Handle, H); OleLoadPicturePath('Caminho e nome da img', nil, 0, 0, IID_IPicture, @Pic); Pic.get_Width(PixelsX); Pic.get_Height(PixelsY); PixelsX := Round(PixelsX * Pix / 2540); PixelsY := Round(PixelsY * PiY / 2540); end;

Essa query é um TQuery ?

Desculpe, coloquei a comparação que utilizo em Whiles; no seu caso seria: if (GetTickCount < Tempo_Inicial) or ((GetTickCount - Tempo_Inicial) >= 1000*60*5) then . . .

É bastante comum em máquinas servidoras que precisam ficar sempre no ar e muito facilmente chega-se ao limite de 4GB de milissegundos que resulta em 49.7 dias sem que a máquina seja reiniciada. Mesmo no caso de 5 minutos você deve estar comparando o Tempo_Inicial com o GetTickCount. Suponha que a máquina estivesse ligada até o limite; seu Tempo_Inicial seria de 4GB de ms e o GetTickCount retornará apenas alguns milissegundos; ou seja; a comparação retornará true após você reiniciar o computador. Eu sempre comparo: if (GetTickCount >= Tempo_Inicial) and . . .

Pois é, estava meio sumido por excesso de trabalho. Vale uma dica que é sempre bom comparar GetTickCount >= ao último GetTickCount retornado porque a função volta a zero após 49.7 dias seguidos que o Windows está no ar.

Acho que esses links podem ser úteis: link1 link2