RichMemo Not Loading Images

[pixelink]

I have a help.rtf that has images.
When I load the external file into RichEdit...

I get all the formatted text, but no images that were saved in the RTF file.

Any help would be nice.

[skalogryz]

...and the widgetset is ...win32?

[pixelink]

...and the widgetset is ...win32?

I'm not sure.
I am on Windows.
I download and packaged the one on the Wiki

[skalogryz]

can i see the help .rtf file?

[pixelink]

can i see the help .rtf file?

Here you go.

[skalogryz]

hmm... can you open the file in Wordpad? Can you see images there?

[pixelink]

Yes, it does.

Even the examples don't work as far as loading external RTF files.

I did find an example that inserted the Leopard GIF using a button (programatically)
But, open and loading an external file... nope.

And I found someone else sample code that doesn't work either.

So, I am wondering if it is even supported.... external files with images I mean.

[skalogryz]

It should be possible to support it, I'll need to update "manual" rtf file loading though.

It seems like system provided RTF loading function would not support images for Windows 7. Which is odd, since Wordpad system to be working.

In Windows 10 RichMemo loads images just fine.

[rvk]

It seems like system provided RTF loading function would not support images for Windows 7. Which is odd, since Wordpad system to be working.
In Windows 10 RichMemo loads images just fine.

Uh, couldn't this be caused by different RICHED20.DLL on the system?

I have had a lot (and I really mean a LOT) of trouble (in Delphi) with all the different RICHED20.DLLs out there (I've tested a lot of versions of 3.0, 3.1, 4.0, 5.0, 6.0 and 8.0, and all subnumbers, which is a lot). All (and I mean ALL) have bugs in them. And if one bug is fixed, another pops up in another version. It's really getting me crazy. In one version tables work fine but left aligned tabs get screwed up after a right aligned tab. In the next version the tab-issue is solved but the tables-bug is back. And there are more of these bugs in the versions. There are also a lot of different RICHED20 versions. Default clean Windows 10 uses v3.1 (version 5.31.23.1231). Windows 7 uses (v3.1) 5.31.23.1229. And yes... even with these small sub-numbering difference there are incompatibilities and bugs. Or there couldbe a different RICHED20.DLL installed with Office (v5.0 through v8.0). If you rely on the RICHED20 dll you should be prepared to deal with all these issues with all different versions or supply a standard RICHED20.DLL in your exe directory of which you know all the bug so you can work around them (but that's not strictly allowed).

[skalogryz]

Uh, couldn't this be caused by different RICHED20.DLL on the system?

It sounds so.
RichMemo tries to load Msftedit.dll first, if it's not available then it rolls back to RICHED20.dll (and even to richedit32.dll for Win9x )

Loading of an image has to be implemented anyway at least for Linux version.

Versions of Rich Edit

[skalogryz]

try r5159, it should now loading images now.

[rvk]

Yep, images load now in Windows 7 64bit with r5159.

I noticed there was no LoadFromFile for RichMemo like there is for lzRichEdit
(Also in Delphi you can do RichEdit.Lines.LoadFromFile and it will detect rtf or plaintext)

But this will do too:

Code: Pascal  [Select][+][-]

1. type
2.   myRichMemoHelper = class helper for TRichMemo
3.   public
4.     procedure LoadFromFile(const FileName: string);
5.   end;
6.  
7. procedure myRichMemoHelper.LoadFromFile(const FileName: string);
8. var
9.   Stream: TStream;
10. begin
11.   Stream := TFileStream.Create(FileName, fmOpenRead or fmShareDenyWrite);
12.   try
13.     Self.LoadRichText(Stream);
14.   finally
15.     Stream.Free;
16.   end;
17. end;
18.  
19.  
20. procedure TForm1.Button1Click(Sender: TObject);
21. begin
22.   RichMemo1.LoadFromFile('help.rtf');
23. end;

[skalogryz]

I noticed there was no LoadFromFile for RichMemo like there is for lzRichEdit
...
But this will do too:

Code: Pascal  [Select][+][-]

1. type
2. procedure myRichMemoHelper.LoadFromFile(const FileName: string);
3. ...
4.   Stream := TFileStream.Create(FileName, fmOpenRead or fmShareDenyWrite);
5.  

Your sample provides the exact reason on why LoadFromFile is not part of RichMemo interface.

Here's a question - why fmShareDenyWrite and not fmShareDenyNone? (one might have a file with write access but would not actually do any writing).

[rvk]

Here's a question - why fmShareDenyWrite and not fmShareDenyNone? (one might have a file with write access but would not actually do any writing).

Because this is the exact same code from TStrings.LoadFromFile.
I take it you have the same question for that piece of code?

B.T.W. Isn't fmShareDenyWrite the safest option? If you use fmShareDenyNone and don't have write access, will that work ??
And you don't need writing in the LoadFromFile.

Code: Pascal  [Select][+][-]

1. Procedure TStrings.LoadFromFile(const FileName: string);
2. Var
3.         TheStream : TFileStream;
4. begin
5.   TheStream:=TFileStream.Create(FileName,fmOpenRead or fmShareDenyWrite);
6.   try
7.     LoadFromStream(TheStream);
8.   finally
9.     TheStream.Free;
10.   end;
11. end;

[skalogryz]

Here's a question - why fmShareDenyWrite and not fmShareDenyNone? (one might have a file with write access but would not actually do any writing).

Because this is the exact same code from TStrings.LoadFromFile.
I take it you have the same question for that piece of code?

Hmmm.... overriding  TStrings.LoadFromFile could deliver more efficient code for Cocoa widgetset.

B.T.W. Isn't fmShareDenyWrite the safest option? If you use fmShareDenyNone and don't have write access, will that work ??
And you don't need writing in the LoadFromFile.

DenyNone - is a sharing key, it doesn't specify if you need write access or not. Write access is requested by fmOpenWrite flag, but "LoadFromFile" methods usually don't need write access to a file.