RichMemo Not Loading Images

[rvk]

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

That's also how Delphi with TRichEdit does it. The Lines.LoadFromFile() is overridden and rtf can be loaded that way. (But in that case maybe PlainText-property should be added too)

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.

Ok. So why does TStrings.LoadFromFile use fmShareDenyWrite ??
But isn't it better to deny other clients/programs to write to the file while you are reading it? (which is what fmShareDenyWrite does, I assume). Or does that not matter?

[skalogryz]

But in that case maybe PlainText-property should be added too)

That's definitely not needed. If one needs to load RTF in RichMemo, he/she could use LoadFromStream.
If one needs to load RTF in RichMemo, he/she could use Lines.LoadFromStream or Lines.LoadFromFile.
No extra coding necessary

Ok. So why does TStrings.LoadFromFile use fmShareDenyWrite ??
But isn't it better to deny other clients/programs to write to the file while you are reading it? (which is what fmShareDenyWrite does, I assume). Or does that not matter?

I don't know why it's using fmShareDenyWrite, but in my day-to-day life, I have to review log files really often.
To say even more, these are active logs, meaning that an application that writes the log is currently active.
Thus I find fmShareDenyNone a better and a safer option.

[rvk]

But in that case maybe PlainText-property should be added too)

That's definitely not needed. If one needs to load RTF in RichMemo, he/she could use LoadFromStream.
If one needs to load RTF in RichMemo, he/she could use Lines.LoadFromStream or Lines.LoadFromFile.
No extra coding necessary

Uh, that seems a tad illogical...
So you propose:

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

1. TRichMemo.Lines.LoadFromFile();   // load rtf text -> new functionality - read only rtf
2. TRichMemo.Lines.LoadFromStream(); // load plain text (which is what it is now, isn't it)
3. TRichMemo.LoadFromStream();       // load rtf (also what it is now)

(how would you load plain text from a file?)

First of all... that's not how Delphi does it. So I suspect you don't mind compatibility in this. In that case I think it would be more logical to create an extra TRichMemo.LoadFromFile(). You get:

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

1. TRichMemo.Lines.LoadFromFile();   // load plain text (as it is now and in TStrings)
2. TRichMemo.Lines.LoadFromStream(); // load plain text (as it is now and in TStrings)
3. TRichMemo.LoadFromFile();         // load rtf - new functionality
4. TRichMemo.LoadFromStream();       // load rtf (as it is now)

The .Lines will hold their original functionality to load text files (as it is the same with TString(List)) and the direct .LoadFromxxx loads rtf.

Otherwise, if you want compatibility with Delphi, loose the TRichMemo.LoadFromStream and make the Lines.LoadFromStream/File intelligent enough to distinguish between rtf and text. But having TRichMemo.LoadFromStream and TRichMemo.Lines.LoadFromFile load rtf is just confusing.

I don't know why it's using fmShareDenyWrite, but in my day-to-day life, I have to review log files really often.
To say even more, these are active logs, meaning that an application that writes the log is currently active.
Thus I find fmShareDenyNone a better and a safer option.

Ah, Ok, clear.

[skalogryz]

Let me start from the back.

Otherwise, if you want compatibility with Delphi, loose the TRichMemo.LoadFromStream and make the Lines.LoadFromStream/File intelligent enough to distinguish between rtf and text. But having TRichMemo.LoadFromStream and TRichMemo.Lines.LoadFromFile load rtf is just confusing.

TRichMemo was originally intended to be used as an alternative to Delphi's TRichEdit. But was never intended to be compatible with it.
One might definitely benefit from Delphi compatibility, but it's not RichMemo's goal in the first place.

If 100% compatibility is required, one could declare a child class TRichEdit class based of TCustomRichMemo, overriding and introducing new Delphi compatible methods and properties, if desired. (I would be fine, with declaring some methods as virtual).

The reason why TRichMemo was not thought to be Delphi compatible is the need of being cross-platform. It would be very likely that anyone who'd like to port their existing Delphi apps to Linux or OSX would be asking for the exact functionality cross all platforms.
Since Delphi's TRichEdit is quite limited in its functionality (even on Win32), it's very likely the code is written using WinAPI functions (i.e. SendMessage( ..., EM_SOMEFANCYCODE ...). ... Supporting all that cross-platform - is not something I'd like to do.

Thus, TRichMemo is a rich-text editing component, without TRichEdit compatibility.

Uh, that seems a tad illogical...
... snip...
The .Lines will hold their original functionality to load text files (as it is the same with TString(List)) and the direct .LoadFromxxx loads rtf.

Perfect. This is how TRichMemo works right now (except for LoadFromFile() method).
No extra coding necessary

Otherwise, if you want compatibility with Delphi, loose the TRichMemo.LoadFromStream and make the Lines.LoadFromStream/File intelligent enough to distinguish between rtf and text. But having TRichMemo.LoadFromStream and TRichMemo.Lines.LoadFromFile load rtf is just confusing.

This conversation brings back some memories for RichMemo API design.

Please note there are no LoadFromStream or SaveToStream methods in RichMemo. I'd like to stress the methods names. "LoadFromStream" or "SaveToStream" are pretty generic names. They don't really specify what exactly being saved into a stream.
In case of RichMemo it introduces an ambiguity, since the text could be either a rich text or a plain text.

To avoid such naming ambiguity, RichMemo has two methods LoadRichText and SaveRichText. While names do not explicitly point to RTF, at least they suggest that the result is not expected to be a plain text. (These methods are not available in RichMemo's Lines property). Btw, I was in doubt of adding these methods, since they're actually Windows specific. But since OSX also allowed to load RTFs, I did add them.

It was also expected that additional utility functions (not methods) would be introduced in future (i.e. RichMemoLoadHTML/RichMemoSaveHTML) where an advantage of an underlying widgetset could be used (i.e. Qt, OSX could load/save html natively)

Ultimately, editing rich-formatting text has nothing to do with its storage format. Thus LoadFromXXX should never be a part of component itself and should be implemented outside of a component. BUT due to APIs limitations and the need if efficiency it's a part of it.