[Lazarus] [lazarus] Patch for processing WM_COPYDATA in Win32 / BugID 9210

[Christian U.]

On Sat, 16 Feb 2008 18:33:43 +0100
Marco van de Voort <marcov at stack.nl> wrote:

> On Sat, Feb 16, 2008 at 05:35:13PM +0100, Marco van de Voort wrote:
> 
> Addition to self:
> 
> I've studied intfgraphics some more and my scheme means that maybe
> some lazarus specific tricks need less lazarus specific implementation

Great.
What tricks?
Keep in mind that the goal of TLazIntfImage is to eventually access
directly the widgetset images instead of copies. Of course this can
only work on some widgetsets.

 
> The lazarus fpcustomimage derivative can communicate with the reader
> via the supportbmp the results of bpp for getDescriptionFromDevice(0).
> 
> It seems the description is mainly about
> 
> function BytesPerLine: PtrUInt;
> function BitsPerLine: PtrUInt;
> function MaskBytesPerLine: PtrUInt;
> function MaskBitsPerLine: PtrUInt;
> 
> mask support is not needed in bpp. Bytesperline is probably a similar
> crucial param as bpp, so I propose to pull this into fpimage too.
> (supports (var bpp, var bytesperline));

I still wonder what happen to the other properties, like depth, bit
order, rgb order, alpha depth, etc.

 
> Long term, maybe the lazarus specific part gets a bit thinner then,
> and properly refactored between general usable and not. Maybe a
> precursor of the laz xpm/bmp readers (with custom "tree" pallete)
> could go into fpimage, and keep descendants with the more lazarus
> specific bits in lcl.


Mattias