<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 30.06.2022 18:20, Werner Pamler via
lazarus wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b570cc84-c396-d0c5-41b2-e5d85e123ec7@freenet.de">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">Am 30.06.2022 um 17:03 schrieb Ondrej
Pokorny via lazarus:<br>
</div>
<blockquote type="cite"
cite="mid:9a639b1c-173c-079b-97ca-5380d85bf51d@kluug.net">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">On 30.06.2022 16:54, Werner Pamler
via lazarus wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b92bacbc-a877-c92e-7417-1d5eaa8595be@freenet.de">Am
30.06.2022 um 15:11 schrieb Mattias Gaertner via lazarus: <br>
<blockquote type="cite">Maybe instead of the
GraphicClass.ClassName the first extension can be <br>
written. <br>
That means, that an old IDE cannot read the graphic. <br>
</blockquote>
This will break Delphi compatibility, i.e. forms with an image
in which the Picture has been loaded by Delphi will not be
readable by Lazarus any more, and vice versa. Just checked
again the signature that Delphi writes to the begin of the
Picture.Data: it's the class name, not the extension. <br>
</blockquote>
<p>And what about writing the extension to the data end?</p>
<p><font face="monospace"> Picture.Data = {<br>
0B 54 49 6D 61 67 69 6E 67 50 4E 47 89 50 4E 47 0D 0A
1A 0A 00 00 00 0D 49 48 44 52 00 00 01 C6<br>
11 T I m a g i n g P N G //
11 is the length byte<br>
03 p n g</font><br>
</p>
<p>That should be both Delphi and legacy Lazarus compatible if
the reader reads only the defined count of bytes for the
classname?</p>
</blockquote>
<p>But isn't this the same problem? When Vampyre is not installed,
and the streamer sees the TImageingPNG classname there is no way
how to find the end of the Picture.Data block.<br>
</p>
</blockquote>
<p>Oh yes, you are right. The ClassName is written in the beginning
of the stream. From the sample I assumed it is written in the end
but that doesn't make sense. My bad.</p>
<p>---<br>
</p>
<p>Well there is an easier solution. I just remembered that I added
an image handler resolver TFPCustomImage.FindHandlerFromStream()
to FPC three years ago:
<a class="moz-txt-link-freetext" href="https://gitlab.com/freepascal.org/fpc/source/-/issues/33955">https://gitlab.com/freepascal.org/fpc/source/-/issues/33955</a></p>
<p>So if the ClassName is not found, the FP image handler can be
found from the actual image stream. Every image format can be
detected directly from the stream, so the ClassName is actually
redundant. When we have the TIHData for the stream, then we have
everything - the extension and the FP reader/writer. From this
information we can find the LCL image handler from the registered
list - of course only if at least /some/ handler is registered for
the extension.</p>
<p>Of course, we are limited to the FPC version - I don't know if
the feature is already in a released version. But we can add the
support for the FPC versions with this feature.<br>
</p>
<p>Ondrej<br>
</p>
</body>
</html>